From p2pi-bounces@ietf.org Sun Jun 1 13:37:39 2008 Return-Path: X-Original-To: p2pi-archive@ietf.org Delivered-To: ietfarch-p2pi-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AAE9D3A6E91; Sun, 1 Jun 2008 13:37:39 -0700 (PDT) X-Original-To: p2pi@core3.amsl.com Delivered-To: p2pi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D7E333A6D3A for ; Sun, 1 Jun 2008 13:33:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.976 X-Spam-Level: X-Spam-Status: No, score=-1.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EyVINczPDjdv for ; Sun, 1 Jun 2008 13:33:11 -0700 (PDT) Received: from wf-out-1314.google.com (wf-out-1314.google.com [209.85.200.172]) by core3.amsl.com (Postfix) with ESMTP id 3AC4C28C6D3 for ; Sun, 1 Jun 2008 08:51:06 -0700 (PDT) Received: by wf-out-1314.google.com with SMTP id 27so572604wfd.31 for ; Sun, 01 Jun 2008 08:51:06 -0700 (PDT) Received: by 10.143.1.12 with SMTP id d12mr3119740wfi.297.1212335465760; Sun, 01 Jun 2008 08:51:05 -0700 (PDT) Received: by 10.142.186.7 with HTTP; Sun, 1 Jun 2008 08:51:05 -0700 (PDT) Message-ID: <3efc39a60806010851n44d26110i39e09a9b5a1bcdf1@mail.gmail.com> Date: Sun, 1 Jun 2008 08:51:05 -0700 From: "Robb Topolski" To: "Nicholas Weaver" In-Reply-To: <3603DD00-748E-48EF-9E9B-CBBDB39D7C1C@icsi.berkeley.edu> MIME-Version: 1.0 References: <90D8CEF754D7D9448BA11172BB5044320896CDE8@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> Cc: 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: multipart/mixed; boundary="===============0043951709==" Sender: p2pi-bounces@ietf.org Errors-To: p2pi-bounces@ietf.org --===============0043951709== Content-Type: multipart/alternative; boundary="----=_Part_12427_33289094.1212335465753" ------=_Part_12427_33289094.1212335465753 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline I think you're right -- MD was tracking those who were exploiting Revision3's open tracker -- and/or they were putting their own fake torrents there. However, the behavior of several torrent clients I've used do not respond the way that MD did when the tracker throws an error (e.g. "Not Registered"). They will either to stop the task and wait for the user to start it again, or, wait for a minimal interval (which doubles on each attempt) and then ask the tracker again. This is not by specification, but by common programming practices with networking applications experiencing an error. With the above in mind, if they were tracking a number of different hashes, most clients I've used would attempt at least once per hash. The error response thrown for a single infohash query attempt would not apply to different infohash queries using the same tracker. Individual clients don't do enough simultaneous tasks to matter. But if MD tracks thousands upon thousands of hashids on a single tracker, they would be well advised to add some anti-hammer code to prevent hammering even though the infohashes differ. Robb Topolski On Fri, May 30, 2008 at 3:17 PM, Nicholas Weaver wrote: > 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. > > -- Robb Topolski (robb@funchords.com) Hillsboro, Oregon USA http://www.funchords.com/ ------=_Part_12427_33289094.1212335465753 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline I think you're right -- MD was tracking those who were exploiting Revision3's open tracker -- and/or they were putting their own fake torrents there.

However, the behavior of several torrent clients I've used do not respond the way that MD did when the tracker throws an error (e.g. "Not Registered").  They will either to stop the task and wait for the user to start it again, or, wait for a minimal interval (which doubles on each attempt) and then ask the tracker again.  This is not by specification, but by common programming practices with networking applications experiencing an error. 

With the above in mind, if they were tracking a number of different hashes, most clients I've used would attempt at least once per hash.  The error response thrown for a single infohash query attempt would not apply to different infohash queries using the same tracker.  Individual clients don't do enough simultaneous tasks to matter.  But if MD tracks thousands upon thousands of hashids on a single tracker, they would be well advised to add some anti-hammer code to prevent hammering even though the infohashes differ.

Robb Topolski

On Fri, May 30, 2008 at 3:17 PM, Nicholas Weaver <nweaver@icsi.berkeley.edu> wrote:
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.




--
Robb Topolski (robb@funchords.com)
Hillsboro, Oregon USA
http://www.funchords.com/ ------=_Part_12427_33289094.1212335465753-- --===============0043951709== 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 --===============0043951709==-- From p2pi-bounces@ietf.org Mon Jun 2 08:02: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 3084828C111; Mon, 2 Jun 2008 08:02: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 C3E443A6AD6 for ; Mon, 2 Jun 2008 08:02:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.264 X-Spam-Level: X-Spam-Status: No, score=-10.264 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HABEAS_ACCREDITED_COI=-8, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nfQDFd0z05lH for ; Mon, 2 Jun 2008 08:02:40 -0700 (PDT) Received: from dkny.pando.com (dkny.pando.com [67.99.55.163]) by core3.amsl.com (Postfix) with ESMTP id 3E2CA28C1E4 for ; Mon, 2 Jun 2008 08:00:15 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by dkny.pando.com (Postfix) with ESMTP id 2FC23E10C3C; Mon, 2 Jun 2008 11:00:17 -0400 (EDT) X-Virus-Scanned: amavisd-new at Received: from dkny.pando.com ([127.0.0.1]) by localhost (dkny.pando.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XiZ5BsEwCAmX; Mon, 2 Jun 2008 10:59:58 -0400 (EDT) Received: from dkny.pando.com (dkny.pando.com [10.10.60.11]) by dkny.pando.com (Postfix) with ESMTP id ACAFDE10C23; Mon, 2 Jun 2008 10:59:58 -0400 (EDT) Date: Mon, 2 Jun 2008 10:59:58 -0400 (EDT) From: Laird Popkin To: Robb Topolski Message-ID: <106407209.306131212418798667.JavaMail.root@dkny.pando.com> In-Reply-To: <490640525.306111212418692013.JavaMail.root@dkny.pando.com> MIME-Version: 1.0 X-Originating-IP: [10.10.20.73] Cc: 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: multipart/mixed; boundary="===============1836085537==" Sender: p2pi-bounces@ietf.org Errors-To: p2pi-bounces@ietf.org --===============1836085537== Content-Type: multipart/alternative; boundary="----=_Part_12203_660210294.1212418798666" ------=_Part_12203_660210294.1212418798666 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit According to Media Defender, they were monitoring 260K torrents in Revision3's open Tracker, which Revision3 has said could well be true. Revision3's claim is that their Tracker was open from when they launched until a year ago, then was closed, then when it started crashing they opened it again (5 weeks ago), and was closed last weekend. Revision3's theory is that torrents are packaged with a long list of trackers, including theirs (because it was open a year ago), so when it was reopened the torrents all announced to them, instantly making them a very popular pirate Tracker. I don't see a lot of multi-tracker torrents, much less torrents with trackers that have been down for a year, but it's possible... The alternative is that in five weeks 260K new torrents were packaged with their newly open Tracker, which would be stunning. In either case, tracking 260K pirate torrents would have generated tons of traffic that Revision3 should have noticed, since it would dwarf whatever level of traffic they saw on their (hundreds?) videos that they were delivering using BitTorrent. Two things that's not clear to me from the coverage - perhaps someone else here knows more: 1) Did Revision3 really see a SYN flood attack, or were they just getting so many TCP connection attempts (from broken retry logic) that they couldn't handle it? 2) Was MediaDefender using Revision3's open tracker to host their own torrents (which is what Revision3 claimed) or were they running BitTorrent clients that joined pirate torrents running on Revision3's open tracker? - Laird Popkin, CTO, Pando Networks mobile: 646/465-0570 ----- Original Message ----- From: "Robb Topolski" To: "Nicholas Weaver" Cc: p2pi@ietf.org Sent: Sunday, June 1, 2008 11:51:05 AM (GMT-0500) America/New_York Subject: Re: [p2pi] FYI - "Inside the Attack that Crippled Revision3" I think you're right -- MD was tracking those who were exploiting Revision3's open tracker -- and/or they were putting their own fake torrents there. However, the behavior of several torrent clients I've used do not respond the way that MD did when the tracker throws an error (e.g. "Not Registered"). They will either to stop the task and wait for the user to start it again, or, wait for a minimal interval (which doubles on each attempt) and then ask the tracker again. This is not by specification, but by common programming practices with networking applications experiencing an error. With the above in mind, if they were tracking a number of different hashes, most clients I've used would attempt at least once per hash. The error response thrown for a single infohash query attempt would not apply to different infohash queries using the same tracker. Individual clients don't do enough simultaneous tasks to matter. But if MD tracks thousands upon thousands of hashids on a single tracker, they would be well advised to add some anti-hammer code to prevent hammering even though the infohashes differ. Robb Topolski On Fri, May 30, 2008 at 3:17 PM, Nicholas Weaver < nweaver@icsi.berkeley.edu > wrote: 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. -- Robb Topolski ( robb@funchords.com ) Hillsboro, Oregon USA http://www.funchords.com/ _______________________________________________ p2pi mailing list p2pi@ietf.org https://www.ietf.org/mailman/listinfo/p2pi ------=_Part_12203_660210294.1212418798666 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable According to Media Defender, they were monitori= ng 260K torrents in Revision3's open Tracker, which Revision3 has said coul= d well be true. Revision3's claim is that their Tracker was open from when = they launched until a year ago, then was closed, then when it started crash= ing they opened it again (5 weeks ago), and was closed last weekend. Revisi= on3's theory is that torrents are packaged with a long list of trackers, in= cluding theirs (because it was open a year ago), so when it was reopened th= e torrents all announced to them, instantly making them a very popular pira= te Tracker. I don't see a lot of multi-tracker torrents, much less torrents= with trackers that have been down for a year, but it's possible...

= The alternative is that in five weeks 260K new torrents were packaged with = their newly open Tracker, which would be stunning.

In either case, t= racking 260K pirate torrents would have generated tons of traffic that Revi= sion3 should have noticed, since it would dwarf whatever level of traffic t= hey saw on their (hundreds?) videos that they were delivering using BitTorr= ent.

Two things that's not clear to me from the coverage - perhaps s= omeone else here knows more:

1) Did Revision3 really see a SYN flood= attack, or were they just getting so many TCP connection attempts (from br= oken retry logic) that they couldn't handle it?
2) Was MediaDefender usi= ng Revision3's open tracker to host their own torrents (which is what Revis= ion3 claimed) or were they running BitTorrent clients that joined pirate to= rrents running on Revision3's open tracker?

- Laird Popkin= , CTO, Pando Networks
  mobile: 646/465-05= 70

----- Original Message -----
From: "Robb Topolski" <robb@fu= nchords.com>
To: "Nicholas Weaver" <nweaver@icsi.berkeley.edu><= br>Cc: p2pi@ietf.org
Sent: Sunday, June 1, 2008 11:51:05 AM (GMT-0500) A= merica/New_York
Subject: Re: [p2pi] FYI - "Inside the Attack that Crippl= ed Revision3"

I think you're right -- MD was tracking those who were= exploiting Revision3's open tracker -- and/or they were putting their own = fake torrents there.

However, the behavior of several torrent client= s I've used do not respond the way that MD did when the tracker throws an e= rror (e.g. "Not Registered").  They will either to stop the task and w= ait for the user to start it again, or, wait for a minimal interval (which = doubles on each attempt) and then ask the tracker again.  This is not = by specification, but by common programming practices with networking appli= cations experiencing an error. 

With the above in mind, if they were tracking a number of different has= hes, most clients I've used would attempt at least once per hash.  The= error response thrown for a single infohash query attempt would not apply = to different infohash queries using the same tracker.  Individual clie= nts don't do enough simultaneous tasks to matter.  But if MD tracks th= ousands upon thousands of hashids on a single tracker, they would be well a= dvised to add some anti-hammer code to prevent hammering even though the in= fohashes differ.

Robb Topolski

On Fri, May 30, 2008 at= 3:17 PM, Nicholas Weaver <nweaver@icsi.berkeley.edu> wrote:
Actually, it sounds like MD was tracking those who were exploiting Revision= 3'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, thei= r monitor went bonkers as it tried to reconnect to every single hash all at= once.

At least, thats what I'd be doing.




--
Robb Topolski (robb@funchords.com)Hillsboro, Oregon USA
http://www.funchords.com/
_______________________________________________ p2pi mailing list p2pi@ietf.org https://www.ietf.org/mailman/listinfo/p2pi ------=_Part_12203_660210294.1212418798666-- --===============1836085537== 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 --===============1836085537==-- From p2pi-bounces@ietf.org Mon Jun 2 08:33:56 2008 Return-Path: X-Original-To: p2pi-archive@ietf.org Delivered-To: ietfarch-p2pi-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BA2333A6C22; Mon, 2 Jun 2008 08:33: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 C836D3A691B for ; Mon, 2 Jun 2008 08:33:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.829 X-Spam-Level: X-Spam-Status: No, score=-5.829 tagged_above=-999 required=5 tests=[AWL=0.770, 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 ab99yt5skrGT for ; Mon, 2 Jun 2008 08:33:55 -0700 (PDT) Received: from fruitcake.ICSI.Berkeley.EDU (fruitcake.ICSI.Berkeley.EDU [192.150.186.11]) by core3.amsl.com (Postfix) with ESMTP id 9031628C1D3 for ; Mon, 2 Jun 2008 08:31:45 -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 m52FVUjt020351; Mon, 2 Jun 2008 08:31:46 -0700 (PDT) Message-Id: <06B2829F-96D5-4292-B18C-E1EBEF8A4C64@icsi.berkeley.edu> From: Nicholas Weaver To: p2pi@ietf.org Mime-Version: 1.0 (Apple Message framework v924) Date: Mon, 2 Jun 2008 08:31:30 -0700 X-Mailer: Apple Mail (2.924) Cc: Nicholas Weaver Subject: [p2pi] One thought on "leech killing" X-BeenThere: p2pi@ietf.org X-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 Comcast's traffic management of bulk-data P2P was reportedly just "leech/seed" killing. And this appears to be correct based on our study of injected RSTs (in submission) [1] The interesting question is as follows: 1: For leech killing, it can be strongly argued that this benefits the customer while hurting BitTorrent. You would do better if your client only talks to people who have blocks you don't have. 2: For seed killing, if the user was just a participant and did not deliberately leave the client open, this benefits the customer. 3: For seed killing, if the user is deliberately acting as a seed, this penalizes the customer. And they should have been provided notice and a workaround. But the first two cases are part of the classic conflict in BitTorrent: the rest of the swarm benefits from allowing leeching and seeding, but the user doesn't (as well as any other flows sharing a bottleneck with the user). This brings up two interesting questions: a) Is it ok for ISP traffic management be limited to solely benefitting their customers or must it ignore behavior that benefits the rest of the aggregate that have the effect of penalizing ALL their customers? b) How do bulk-data P2P systems evolve if participants are FORCED to eliminate "altruistic" behavior (allowing leeches), but limited to "reciprical" and "greedy" behaviors? [1] The comcast RST injector, on P2P traffic showed that it was almost completely killing what look by simple traffic analysis to be leeching/ seeds: it ONLY killed flows where there were a lot more bytes (10 kB-1MB) from the comcast peer, and only a few (less than 1 kB) from the ICSI peer. This looks to be like "I'm only sending the first block, not asking for a block". The only exception are 7% of the flows where only a couple hundred bytes are exchanged, although the Sandvine CTO reports that their system at least supports recognizing "this peer says it has ALL the blocks, so it must be seeding". I hope to verify this by examining the archived packet traces. _______________________________________________ p2pi mailing list p2pi@ietf.org https://www.ietf.org/mailman/listinfo/p2pi From p2pi-bounces@ietf.org Mon Jun 2 08:47: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 650A028C1B4; Mon, 2 Jun 2008 08:47: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 E79013A6C79 for ; Mon, 2 Jun 2008 08:47:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.676 X-Spam-Level: X-Spam-Status: No, score=-1.676 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_24=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AI99HR39Eo7r for ; Mon, 2 Jun 2008 08:47:22 -0700 (PDT) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.231]) by core3.amsl.com (Postfix) with ESMTP id EF2323A6C90 for ; Mon, 2 Jun 2008 08:45:52 -0700 (PDT) Received: by rv-out-0506.google.com with SMTP id b25so889583rvf.49 for ; Mon, 02 Jun 2008 08:45:52 -0700 (PDT) Received: by 10.141.154.5 with SMTP id g5mr5032498rvo.290.1212421550197; Mon, 02 Jun 2008 08:45:50 -0700 (PDT) Received: by 10.140.163.8 with HTTP; Mon, 2 Jun 2008 08:45:50 -0700 (PDT) Message-ID: <3efc39a60806020845x641dcfcet7c9f0c8e3753ba2a@mail.gmail.com> Date: Mon, 2 Jun 2008 08:45:50 -0700 From: "Robb Topolski" To: p2pi@ietf.org In-Reply-To: <106407209.306131212418798667.JavaMail.root@dkny.pando.com> MIME-Version: 1.0 References: <490640525.306111212418692013.JavaMail.root@dkny.pando.com> <106407209.306131212418798667.JavaMail.root@dkny.pando.com> 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: multipart/mixed; boundary="===============0669103197==" Sender: p2pi-bounces@ietf.org Errors-To: p2pi-bounces@ietf.org --===============0669103197== Content-Type: multipart/alternative; boundary="----=_Part_3027_12323608.1212421550192" ------=_Part_3027_12323608.1212421550192 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline On Mon, Jun 2, 2008 at 7:59 AM, Laird Popkin wrote: > 1) Did Revision3 really see a SYN flood attack, or were they just getting > so many TCP connection attempts (from broken retry logic) that they couldn't > handle it? > I don't believe the attack was anything but a side-effect of broken retry logic. I don't see anything in the history of MediaDefender that suggests a denial-of-service attack is in their M.O.. > 2) Was MediaDefender using Revision3's open tracker to host their own > torrents (which is what Revision3 claimed) > Laird, since this is you asking, I'm confused as to what exactly you're asking (because you definitely know that trackers don't 'host' torrents, they simply store IP:port combinations attached to infohashes). The torrent file has to be obtained elsewhere (sometimes on an affiliated website). Perhaps you're asking if MediaDefender uploaded the *.torrent files to Revision3's website? (And I don't know the answer to that. I never heard of them before now.) I think I can explain why MediaDefender would use their tracker, though. MediaDefender owns several of *their own* trackers that they use for data collection. They release their own *.torrent files, masquerading as some popular album or movie the rights of which are owned by their customer. Encoded into the *.torrent files is a list of trackers. To hide their "fake" trackers, MediaDefender embed their "fake" trackers URLs in a long list of open trackers that prominently include popular systems. Perhaps including the revision3 tracker was chaff to hide the fakes. Here is an interesting link: http://www.btmon.com/tracker/http_tracker.revision3.com_20000_announce/ As I look at some of the items on that link, I see one that has 63 different tracker URLs listed. This is one hint of a fake torrent, but it's not definitive. On Mon, Jun 2, 2008 at 7:59 AM, Laird Popkin wrote: > According to Media Defender, they were monitoring 260K torrents in > Revision3's open Tracker, which Revision3 has said could well be true. > Revision3's claim is that their Tracker was open from when they launched > until a year ago, then was closed, then when it started crashing they opened > it again (5 weeks ago), and was closed last weekend. Revision3's theory is > that torrents are packaged with a long list of trackers, including theirs > (because it was open a year ago), so when it was reopened the torrents all > announced to them, instantly making them a very popular pirate Tracker. I > don't see a lot of multi-tracker torrents, much less torrents with trackers > that have been down for a year, but it's possible... > > The alternative is that in five weeks 260K new torrents were packaged with > their newly open Tracker, which would be stunning. > > In either case, tracking 260K pirate torrents would have generated tons of > traffic that Revision3 should have noticed, since it would dwarf whatever > level of traffic they saw on their (hundreds?) videos that they were > delivering using BitTorrent. > > Two things that's not clear to me from the coverage - perhaps someone else > here knows more: > > 1) Did Revision3 really see a SYN flood attack, or were they just getting > so many TCP connection attempts (from broken retry logic) that they couldn't > handle it? > 2) Was MediaDefender using Revision3's open tracker to host their own > torrents (which is what Revision3 claimed) or were they running BitTorrent > clients that joined pirate torrents running on Revision3's open tracker? > > - Laird Popkin, CTO, Pando Networks > mobile: 646/465-0570 > > ----- Original Message ----- > From: "Robb Topolski" > To: "Nicholas Weaver" > Cc: p2pi@ietf.org > Sent: Sunday, June 1, 2008 11:51:05 AM (GMT-0500) America/New_York > Subject: Re: [p2pi] FYI - "Inside the Attack that Crippled Revision3" > > I think you're right -- MD was tracking those who were exploiting > Revision3's open tracker -- and/or they were putting their own fake torrents > there. > > However, the behavior of several torrent clients I've used do not respond > the way that MD did when the tracker throws an error (e.g. "Not > Registered"). They will either to stop the task and wait for the user to > start it again, or, wait for a minimal interval (which doubles on each > attempt) and then ask the tracker again. This is not by specification, but > by common programming practices with networking applications experiencing an > error. > > With the above in mind, if they were tracking a number of different hashes, > most clients I've used would attempt at least once per hash. The error > response thrown for a single infohash query attempt would not apply to > different infohash queries using the same tracker. Individual clients don't > do enough simultaneous tasks to matter. But if MD tracks thousands upon > thousands of hashids on a single tracker, they would be well advised to add > some anti-hammer code to prevent hammering even though the infohashes > differ. > > Robb Topolski > > On Fri, May 30, 2008 at 3:17 PM, Nicholas Weaver < > nweaver@icsi.berkeley.edu> wrote: > >> 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. >> >> > > > -- > Robb Topolski (robb@funchords.com) > Hillsboro, Oregon USA > http://www.funchords.com/ > _______________________________________________ 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_3027_12323608.1212421550192 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline On Mon, Jun 2, 2008 at 7:59 AM, Laird Popkin <laird@pando.com> wrote:
1) Did Revision3 really see a SYN flood attack, or were they just getting so many TCP connection attempts (from broken retry logic) that they couldn't handle it?

I don't believe the attack was anything but a side-effect of broken retry logic.  I don't see anything in the history of MediaDefender that suggests a denial-of-service attack is in their M.O..
 
2) Was MediaDefender using Revision3's open tracker to host their own torrents (which is what Revision3 claimed)

Laird, since this is you asking, I'm confused as to what exactly you're asking  (because you definitely know that trackers don't 'host' torrents, they simply store IP:port combinations attached to infohashes).  The torrent file has to be obtained elsewhere (sometimes on an affiliated website).  Perhaps you're asking if MediaDefender uploaded the *.torrent files to Revision3's website?  (And I don't know the answer to that. I never heard of them before now.) 

I think I can explain why MediaDefender would use their tracker, though.   MediaDefender owns several of their own trackers that they use for data collection.  They release their own *.torrent files, masquerading as some popular album or movie the rights of which are owned by their customer.  Encoded into the *.torrent files is a list of trackers.   To hide their "fake" trackers, MediaDefender embed their "fake" trackers URLs in a long list of open trackers that prominently include popular systems.  Perhaps including the revision3 tracker was chaff to hide the fakes. 

Here is an interesting link:  http://www.btmon.com/tracker/http_tracker.revision3.com_20000_announce/

As I look at some of the items on that link, I see one that has 63 different tracker URLs listed.  This is one hint of a fake torrent, but it's not definitive.


On Mon, Jun 2, 2008 at 7:59 AM, Laird Popkin <laird@pando.com> wrote:
According to Media Defender, they were monitoring 260K torrents in Revision3's open Tracker, which Revision3 has said could well be true. Revision3's claim is that their Tracker was open from when they launched until a year ago, then was closed, then when it started crashing they opened it again (5 weeks ago), and was closed last weekend. Revision3's theory is that torrents are packaged with a long list of trackers, including theirs (because it was open a year ago), so when it was reopened the torrents all announced to them, instantly making them a very popular pirate Tracker. I don't see a lot of multi-tracker torrents, much less torrents with trackers that have been down for a year, but it's possible...

The alternative is that in five weeks 260K new torrents were packaged with their newly open Tracker, which would be stunning.

In either case, tracking 260K pirate torrents would have generated tons of traffic that Revision3 should have noticed, since it would dwarf whatever level of traffic they saw on their (hundreds?) videos that they were delivering using BitTorrent.

Two things that's not clear to me from the coverage - perhaps someone else here knows more:

1) Did Revision3 really see a SYN flood attack, or were they just getting so many TCP connection attempts (from broken retry logic) that they couldn't handle it?
2) Was MediaDefender using Revision3's open tracker to host their own torrents (which is what Revision3 claimed) or were they running BitTorrent clients that joined pirate torrents running on Revision3's open tracker?

- Laird Popkin, CTO, Pando Networks
  mobile: 646/465-0570


----- Original Message -----
From: "Robb Topolski" <robb@funchords.com>
To: "Nicholas Weaver" <nweaver@icsi.berkeley.edu>
Cc: p2pi@ietf.org
Sent: Sunday, June 1, 2008 11:51:05 AM (GMT-0500) America/New_York
Subject: Re: [p2pi] FYI - "Inside the Attack that Crippled Revision3"

I think you're right -- MD was tracking those who were exploiting Revision3's open tracker -- and/or they were putting their own fake torrents there.

However, the behavior of several torrent clients I've used do not respond the way that MD did when the tracker throws an error (e.g. "Not Registered").  They will either to stop the task and wait for the user to start it again, or, wait for a minimal interval (which doubles on each attempt) and then ask the tracker again.  This is not by specification, but by common programming practices with networking applications experiencing an error. 

With the above in mind, if they were tracking a number of different hashes, most clients I've used would attempt at least once per hash.  The error response thrown for a single infohash query attempt would not apply to different infohash queries using the same tracker.  Individual clients don't do enough simultaneous tasks to matter.  But if MD tracks thousands upon thousands of hashids on a single tracker, they would be well advised to add some anti-hammer code to prevent hammering even though the infohashes differ.

Robb Topolski

On Fri, May 30, 2008 at 3:17 PM, Nicholas Weaver <nweaver@icsi.berkeley.edu> wrote:
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.




--
Robb Topolski (robb@funchords.com)
Hillsboro, Oregon USA
http://www.funchords.com/
_______________________________________________ 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_3027_12323608.1212421550192-- --===============0669103197== 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 --===============0669103197==-- From p2pi-bounces@ietf.org Mon Jun 2 09:08:45 2008 Return-Path: X-Original-To: p2pi-archive@ietf.org Delivered-To: ietfarch-p2pi-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9D8613A6CA3; Mon, 2 Jun 2008 09:08:45 -0700 (PDT) X-Original-To: p2pi@core3.amsl.com Delivered-To: p2pi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ED6CA3A69D9 for ; Mon, 2 Jun 2008 09:08:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.965 X-Spam-Level: X-Spam-Status: No, score=-9.965 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, HABEAS_ACCREDITED_COI=-8, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_13=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pzn6sK6IegtS for ; Mon, 2 Jun 2008 09:08:43 -0700 (PDT) Received: from dkny.pando.com (dkny.pando.com [67.99.55.163]) by core3.amsl.com (Postfix) with ESMTP id 58A763A6CAA for ; Mon, 2 Jun 2008 09:06:10 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by dkny.pando.com (Postfix) with ESMTP id 87DD2E10C51; Mon, 2 Jun 2008 12:06:07 -0400 (EDT) X-Virus-Scanned: amavisd-new at Received: from dkny.pando.com ([127.0.0.1]) by localhost (dkny.pando.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w9hsmfiNlFFJ; Mon, 2 Jun 2008 12:06:06 -0400 (EDT) Received: from dkny.pando.com (dkny.pando.com [10.10.60.11]) by dkny.pando.com (Postfix) with ESMTP id EC91AE10C50; Mon, 2 Jun 2008 12:06:06 -0400 (EDT) Date: Mon, 2 Jun 2008 12:06:06 -0400 (EDT) From: Laird Popkin To: p2pi@ietf.org, p4pwg@yahoogroups.com Message-ID: <1865369468.307061212422766942.JavaMail.root@dkny.pando.com> In-Reply-To: <443690410.306941212422172782.JavaMail.root@dkny.pando.com> MIME-Version: 1.0 X-Originating-IP: [10.10.20.73] Cc: ramit@pando.com Subject: [p2pi] Thoughts on how IETF standards can help P2P/ISPs X-BeenThere: p2pi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: P2P Infrastructure Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: p2pi-bounces@ietf.org Errors-To: p2pi-bounces@ietf.org As we discussed last week at the IETF P2Pi Workshop, here are a list of some of the ways that IETF standards can potentially help P2P applications make better network decisions, and thus help ISPs. This isn't a complete list, but I hope that it's at least a useful starting point for a discussion. - Expose more information about TCP streams. For example, expose whether the stream is congested. Currently some p2p applications use a variety of techniques to attempt to guess whether a user's internet connection is congested (e.g. monitoring ping times), and measures stream throughput which could be viewed as a very rough measure of congestion, but it would be more accurate and efficient if TCP told the application when a stream was congested. Even better would be to get some indication of where the congestion occurred. For example, if the congestion is in the 'last mile', or the other peer's 'last mile', or somewhere in between, different responses would be appropriate. For example, if my internet connection is fine, but the peer's connection is congested, I should slow down transfers from that peer, and pull more from other peers. This is, of course, easier said than done. - Expose some measure of 'communications cost' so that p2p apps could select the lowest cost available data sources. (This is what the P4P protocol does, for example). If using this guidance benefits both P2Ps and ISPs, it is a win-win. This is a fairly broad area that might include a number of steps/messages/protocols in order to address service location, mapping IPs to location, and "cost". The P4PWG is researching this area, and while it feels a little early to propose a standard, it's certainly an area (IMO) that could benefit from attention. - ISP's could expose usage metrics. For example, if a user has a link that is capable of 1 Mbps, has a monthly transfer capacity of 500 GB, and has used 350 GB so far, then the application can make better choices, and application users could make informed choices. If the ISP could tell applications when the user's internet connection is congested, that would be extremely helpful. - Allow applications to tag some traffic as 'not time sensitive' so that ISPs can manage bulk traffic as lower priority than time-sensitive traffic. There would need to be a benefit to the application for doing so, such as excluding such traffic from ISP capacity limits. - Laird Popkin, CTO, Pando Networks mobile: 646/465-0570 _______________________________________________ p2pi mailing list p2pi@ietf.org https://www.ietf.org/mailman/listinfo/p2pi From p2pi-bounces@ietf.org Mon Jun 2 09: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 70DC33A6BEB; Mon, 2 Jun 2008 09: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 76ED028C180 for ; Mon, 2 Jun 2008 09:38:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.786 X-Spam-Level: X-Spam-Status: No, score=-5.786 tagged_above=-999 required=5 tests=[AWL=0.213, BAYES_00=-2.599, J_CHICKENPOX_12=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3C6nt+8c-rST for ; Mon, 2 Jun 2008 09:38:42 -0700 (PDT) Received: from fruitcake.ICSI.Berkeley.EDU (fruitcake.ICSI.Berkeley.EDU [192.150.186.11]) by core3.amsl.com (Postfix) with ESMTP id 13F8228C17B for ; Mon, 2 Jun 2008 09:38:42 -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 m52GcQt2003570; Mon, 2 Jun 2008 09:38:27 -0700 (PDT) Message-Id: <94BE4178-F5C8-43F3-882C-8B1E9CB52190@icsi.berkeley.edu> From: Nicholas Weaver To: Laird Popkin In-Reply-To: <1865369468.307061212422766942.JavaMail.root@dkny.pando.com> Mime-Version: 1.0 (Apple Message framework v924) Date: Mon, 2 Jun 2008 09:38:26 -0700 References: <1865369468.307061212422766942.JavaMail.root@dkny.pando.com> X-Mailer: Apple Mail (2.924) Cc: p2pi@ietf.org, ramit@pando.com, Nicholas Weaver , p4pwg@yahoogroups.com Subject: Re: [p2pi] Thoughts on how IETF standards can help P2P/ISPs X-BeenThere: p2pi@ietf.org X-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 Jun 2, 2008, at 9:06 AM, Laird Popkin wrote: > > > - Allow applications to tag some traffic as 'not time sensitive' so > that ISPs can manage bulk traffic as lower priority than time- > sensitive traffic. There would need to be a benefit to the > application for doing so, such as excluding such traffic from ISP > capacity limits. I actually think the opposite ("tag as priority") is better, because its easy to do "tag & cap" and the incentives match up better. Here's why... There is no benefit to saying "I'm worse than best effort", because any application who's worse-than-best effort can always use a friendlier than TCP congestion control ( http://www.icir.org/floyd/tcp_small.html has a list), have the same effect on the network, and suddenly go unnoticed in moments of congestion without requiring network support for QoS to be enabled. Given the problems users are experiencing with BitTorrent just on their own network ( http://www.formortals.com/Home/tabid/36/EntryID/57/Default.aspx , http://tech.slashdot.org/article.pl?sid=08/05/24/1859218 ), there actually seems to be some incentive in place for the bulk-data P2P developers to use one of the existing off-the-shelf solutions for friendlier-than-TCP behavior (note, this is something I was WRONG on earlier, as I thought there was no incentive), and if they don't have incentive to use friendlier-than-TCP, why would they have incentive to mark as 'not time sensitive', as they would accomplish the same thing. [1] However there is a benefit to saying "I'm better than best effort", for applications like VoIP or online games, or even the non-image portions of your HTTP requests. ISPs can spend a lot of effort using packet analysis to determine these flows, or just rely on the endpoints to get it right. There is no benefit to cheating, IF the network enforces a cap on the number of (packets/bytes) sent with priority per (ms/sec/minute/hour), as the measurement is relatively easy to enforce (1 memory lookup/ update per packet, and because its only high-volume users which have an incentive to cheat, you can easily use a small LRU cache for addresses). [1] It might be the role of the OS to implement some of this. EG, coupling AIMD across all flows of an application, combined with some more detailed RTT-based congestion control a'la TCP Vegas, again correlating across multiple flows) _______________________________________________ p2pi mailing list p2pi@ietf.org https://www.ietf.org/mailman/listinfo/p2pi From p2pi-bounces@ietf.org Mon Jun 2 09:46: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 57B1428C1AF; Mon, 2 Jun 2008 09:46: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 012F73A69AA for ; Mon, 2 Jun 2008 09:46:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.814 X-Spam-Level: X-Spam-Status: No, score=-9.814 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, HABEAS_ACCREDITED_COI=-8, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_24=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oBj4jGlO1x7f for ; Mon, 2 Jun 2008 09:46:18 -0700 (PDT) Received: from dkny.pando.com (dkny.pando.com [67.99.55.163]) by core3.amsl.com (Postfix) with ESMTP id E499428C1D5 for ; Mon, 2 Jun 2008 09:41:15 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by dkny.pando.com (Postfix) with ESMTP id 04E86E10C3C; Mon, 2 Jun 2008 12:41:15 -0400 (EDT) X-Virus-Scanned: amavisd-new at Received: from dkny.pando.com ([127.0.0.1]) by localhost (dkny.pando.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZVSUEtVw506u; Mon, 2 Jun 2008 12:40:58 -0400 (EDT) Received: from dkny.pando.com (dkny.pando.com [10.10.60.11]) by dkny.pando.com (Postfix) with ESMTP id 29935E10C48; Mon, 2 Jun 2008 12:40:58 -0400 (EDT) Date: Mon, 2 Jun 2008 12:40:58 -0400 (EDT) From: Laird Popkin To: Robb Topolski Message-ID: <453197743.307691212424858006.JavaMail.root@dkny.pando.com> In-Reply-To: <2025055099.307671212424833653.JavaMail.root@dkny.pando.com> MIME-Version: 1.0 X-Originating-IP: [10.10.20.73] Cc: 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: multipart/mixed; boundary="===============0585483597==" Sender: p2pi-bounces@ietf.org Errors-To: p2pi-bounces@ietf.org --===============0585483597== Content-Type: multipart/alternative; boundary="----=_Part_12259_1357105790.1212424858005" ------=_Part_12259_1357105790.1212424858005 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Comments below. - Laird Popkin, CTO, Pando Networks mobile: 646/465-0570 ----- Original Message ----- From: "Robb Topolski" To: p2pi@ietf.org Sent: Monday, June 2, 2008 11:45:50 AM (GMT-0500) America/New_York Subject: Re: [p2pi] FYI - "Inside the Attack that Crippled Revision3" On Mon, Jun 2, 2008 at 7:59 AM, Laird Popkin < laird@pando.com > wrote: 1) Did Revision3 really see a SYN flood attack, or were they just getting so many TCP connection attempts (from broken retry logic) that they couldn't handle it? I don't believe the attack was anything but a side-effect of broken retry logic. I don't see anything in the history of MediaDefender that suggests a denial-of-service attack is in their M.O.. 2) Was MediaDefender using Revision3's open tracker to host their own torrents (which is what Revision3 claimed) Laird, since this is you asking, I'm confused as to what exactly you're asking (because you definitely know that trackers don't 'host' torrents, they simply store IP:port combinations attached to infohashes). The torrent file has to be obtained elsewhere (sometimes on an affiliated website). Perhaps you're asking if MediaDefender uploaded the *.torrent files to Revision3's website? (And I don't know the answer to that. I never heard of them before now.) Sorry my question was ambiguous. So let me try rephrasing: The question was whether they were: 1) Detecting that Revision3's tracker was providing Tracking for pirate torrents and joining those torrents as a peer in order to do whatever MD does to BitTorrent torrents (scraping, serving, etc.). This seems like a reasonable way for them to know what's going on in the swarm, etc. 2) Publishing new torrents, and running them on Revision3's open tracker. This seems questionable, because if they want to use a Tracker they should run one. I think I can explain why MediaDefender would use their tracker, though. MediaDefender owns several of their own trackers that they use for data collection. They release their own *.torrent files, masquerading as some popular album or movie the rights of which are owned by their customer. Encoded into the *.torrent files is a list of trackers. To hide their "fake" trackers, MediaDefender embed their "fake" trackers URLs in a long list of open trackers that prominently include popular systems. Perhaps including the revision3 tracker was chaff to hide the fakes. Here is an interesting link: http://www.btmon.com/tracker/http_tracker.revision3.com_20000_announce/ As I look at some of the items on that link, I see one that has 63 different tracker URLs listed. This is one hint of a fake torrent, but it's not definitive. Very interesting stuff. Nice ads on the page, too. :-) This would generate tons of client connections to Revision3's Trackers, though, which MediaDefender can't control. According to Revision3, once they contacted MediaDefender, MD stopped the DOS attack quite quickly, which tells me that it was coming from MD's servers, not clients. On Mon, Jun 2, 2008 at 7:59 AM, Laird Popkin < laird@pando.com > wrote: According to Media Defender, they were monitoring 260K torrents in Revision3's open Tracker, which Revision3 has said could well be true. Revision3's claim is that their Tracker was open from when they launched until a year ago, then was closed, then when it started crashing they opened it again (5 weeks ago), and was closed last weekend. Revision3's theory is that torrents are packaged with a long list of trackers, including theirs (because it was open a year ago), so when it was reopened the torrents all announced to them, instantly making them a very popular pirate Tracker. I don't see a lot of multi-tracker torrents, much less torrents with trackers that have been down for a year, but it's possible... The alternative is that in five weeks 260K new torrents were packaged with their newly open Tracker, which would be stunning. In either case, tracking 260K pirate torrents would have generated tons of traffic that Revision3 should have noticed, since it would dwarf whatever level of traffic they saw on their (hundreds?) videos that they were delivering using BitTorrent. Two things that's not clear to me from the coverage - perhaps someone else here knows more: 1) Did Revision3 really see a SYN flood attack, or were they just getting so many TCP connection attempts (from broken retry logic) that they couldn't handle it? 2) Was MediaDefender using Revision3's open tracker to host their own torrents (which is what Revision3 claimed) or were they running BitTorrent clients that joined pirate torrents running on Revision3's open tracker? - Laird Popkin, CTO, Pando Networks mobile: 646/465-0570 ----- Original Message ----- From: "Robb Topolski" < robb@funchords.com > To: "Nicholas Weaver" < nweaver@icsi.berkeley.edu > Cc: p2pi@ietf.org Sent: Sunday, June 1, 2008 11:51:05 AM (GMT-0500) America/New_York Subject: Re: [p2pi] FYI - "Inside the Attack that Crippled Revision3" I think you're right -- MD was tracking those who were exploiting Revision3's open tracker -- and/or they were putting their own fake torrents there. However, the behavior of several torrent clients I've used do not respond the way that MD did when the tracker throws an error (e.g. "Not Registered"). They will either to stop the task and wait for the user to start it again, or, wait for a minimal interval (which doubles on each attempt) and then ask the tracker again. This is not by specification, but by common programming practices with networking applications experiencing an error. With the above in mind, if they were tracking a number of different hashes, most clients I've used would attempt at least once per hash. The error response thrown for a single infohash query attempt would not apply to different infohash queries using the same tracker. Individual clients don't do enough simultaneous tasks to matter. But if MD tracks thousands upon thousands of hashids on a single tracker, they would be well advised to add some anti-hammer code to prevent hammering even though the infohashes differ. Robb Topolski On Fri, May 30, 2008 at 3:17 PM, Nicholas Weaver < nweaver@icsi.berkeley.edu > wrote: 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. -- Robb Topolski ( robb@funchords.com ) Hillsboro, Oregon USA http://www.funchords.com/ _______________________________________________ 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/ _______________________________________________ p2pi mailing list p2pi@ietf.org https://www.ietf.org/mailman/listinfo/p2pi ------=_Part_12259_1357105790.1212424858005 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit Comments below.

- Laird Popkin, CTO, Pando Networks
  mobile: 646/465-0570

----- Original Message -----
From: "Robb Topolski" <robb@funchords.com>
To: p2pi@ietf.org
Sent: Monday, June 2, 2008 11:45:50 AM (GMT-0500) America/New_York
Subject: Re: [p2pi] FYI - "Inside the Attack that Crippled Revision3"

On Mon, Jun 2, 2008 at 7:59 AM, Laird Popkin <laird@pando.com> wrote:
1) Did Revision3 really see a SYN flood attack, or were they just getting so many TCP connection attempts (from broken retry logic) that they couldn't handle it?

I don't believe the attack was anything but a side-effect of broken retry logic.  I don't see anything in the history of MediaDefender that suggests a denial-of-service attack is in their M.O..
 
2) Was MediaDefender using Revision3's open tracker to host their own torrents (which is what Revision3 claimed)

Laird, since this is you asking, I'm confused as to what exactly you're asking  (because you definitely know that trackers don't 'host' torrents, they simply store IP:port combinations attached to infohashes).  The torrent file has to be obtained elsewhere (sometimes on an affiliated website).  Perhaps you're asking if MediaDefender uploaded the *.torrent files to Revision3's website?  (And I don't know the answer to that. I never heard of them before now.) 

Sorry my question was ambiguous. So let me try rephrasing:

The question was whether they were:

1) Detecting that Revision3's tracker was providing Tracking for pirate torrents and joining those torrents as a peer in order to do whatever MD does to BitTorrent torrents (scraping, serving, etc.). This seems like a reasonable way for them to know what's going on in the swarm, etc.
2) Publishing new torrents, and running them on Revision3's open tracker. This seems questionable, because if they want to use a Tracker they should run one.

I think I can explain why MediaDefender would use their tracker, though.   MediaDefender owns several of their own trackers that they use for data collection.  They release their own *.torrent files, masquerading as some popular album or movie the rights of which are owned by their customer.  Encoded into the *.torrent files is a list of trackers.   To hide their "fake" trackers, MediaDefender embed their "fake" trackers URLs in a long list of open trackers that prominently include popular systems.  Perhaps including the revision3 tracker was chaff to hide the fakes. 

Here is an interesting link:  http://www.btmon.com/tracker/http_tracker.revision3.com_20000_announce/

As I look at some of the items on that link, I see one that has 63 different tracker URLs listed.  This is one hint of a fake torrent, but it's not definitive.

Very interesting stuff. Nice ads on the page, too. :-)

This would generate tons of client connections to Revision3's Trackers, though, which MediaDefender can't control. According to Revision3, once they contacted MediaDefender, MD stopped the DOS attack quite quickly, which tells me that it was coming from MD's servers, not clients.

On Mon, Jun 2, 2008 at 7:59 AM, Laird Popkin <laird@pando.com> wrote:
According to Media Defender, they were monitoring 260K torrents in Revision3's open Tracker, which Revision3 has said could well be true. Revision3's claim is that their Tracker was open from when they launched until a year ago, then was closed, then when it started crashing they opened it again (5 weeks ago), and was closed last weekend. Revision3's theory is that torrents are packaged with a long list of trackers, including theirs (because it was open a year ago), so when it was reopened the torrents all announced to them, instantly making them a very popular pirate Tracker. I don't see a lot of multi-tracker torrents, much less torrents with trackers that have been down for a year, but it's possible...

The alternative is that in five weeks 260K new torrents were packaged with their newly open Tracker, which would be stunning.

In either case, tracking 260K pirate torrents would have generated tons of traffic that Revision3 should have noticed, since it would dwarf whatever level of traffic they saw on their (hundreds?) videos that they were delivering using BitTorrent.

Two things that's not clear to me from the coverage - perhaps someone else here knows more:

1) Did Revision3 really see a SYN flood attack, or were they just getting so many TCP connection attempts (from broken retry logic) that they couldn't handle it?
2) Was MediaDefender using Revision3's open tracker to host their own torrents (which is what Revision3 claimed) or were they running BitTorrent clients that joined pirate torrents running on Revision3's open tracker?

- Laird Popkin, CTO, Pando Networks
  mobile: 646/465-0570


----- Original Message -----
From: "Robb Topolski" <robb@funchords.com>
To: "Nicholas Weaver" <nweaver@icsi.berkeley.edu>
Cc: p2pi@ietf.org
Sent: Sunday, June 1, 2008 11:51:05 AM (GMT-0500) America/New_York
Subject: Re: [p2pi] FYI - "Inside the Attack that Crippled Revision3"

I think you're right -- MD was tracking those who were exploiting Revision3's open tracker -- and/or they were putting their own fake torrents there.

However, the behavior of several torrent clients I've used do not respond the way that MD did when the tracker throws an error (e.g. "Not Registered").  They will either to stop the task and wait for the user to start it again, or, wait for a minimal interval (which doubles on each attempt) and then ask the tracker again.  This is not by specification, but by common programming practices with networking applications experiencing an error. 

With the above in mind, if they were tracking a number of different hashes, most clients I've used would attempt at least once per hash.  The error response thrown for a single infohash query attempt would not apply to different infohash queries using the same tracker.  Individual clients don't do enough simultaneous tasks to matter.  But if MD tracks thousands upon thousands of hashids on a single tracker, they would be well advised to add some anti-hammer code to prevent hammering even though the infohashes differ.

Robb Topolski

On Fri, May 30, 2008 at 3:17 PM, Nicholas Weaver <nweaver@icsi.berkeley.edu> wrote:
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.




--
Robb Topolski (robb@funchords.com)
Hillsboro, Oregon USA
http://www.funchords.com/
_______________________________________________ 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/
_______________________________________________ p2pi mailing list p2pi@ietf.org https://www.ietf.org/mailman/listinfo/p2pi
------=_Part_12259_1357105790.1212424858005-- --===============0585483597== 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 --===============0585483597==-- From p2pi-bounces@ietf.org Mon Jun 2 10:01:33 2008 Return-Path: X-Original-To: p2pi-archive@ietf.org Delivered-To: ietfarch-p2pi-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C995F3A69E4; Mon, 2 Jun 2008 10:01:32 -0700 (PDT) X-Original-To: p2pi@core3.amsl.com Delivered-To: p2pi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A84DB3A69ED for ; Mon, 2 Jun 2008 10:01:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.999 X-Spam-Level: X-Spam-Status: No, score=-2.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_13=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 Qr7PiB5eH613 for ; Mon, 2 Jun 2008 10:01:26 -0700 (PDT) Received: from serrano.cc.columbia.edu (serrano.cc.columbia.edu [128.59.29.6]) by core3.amsl.com (Postfix) with ESMTP id 8C0A828C198 for ; Mon, 2 Jun 2008 09:50:45 -0700 (PDT) Received: from banana.cc.columbia.edu (banana.cc.columbia.edu [128.59.29.54]) by serrano.cc.columbia.edu (8.14.1/8.14.1) with ESMTP id m52Gog63006303; Mon, 2 Jun 2008 12:50:42 -0400 (EDT) Received: from banana.cc.columbia.edu (localhost [127.0.0.1]) by banana.cc.columbia.edu (8.14.1/8.14.1) with ESMTP id m52GogxG025415; Mon, 2 Jun 2008 12:50:42 -0400 (EDT) Received: from localhost (sa2086@localhost) by banana.cc.columbia.edu (8.14.1/8.14.1/Submit) with ESMTP id m52GofYB025407; Mon, 2 Jun 2008 12:50:41 -0400 (EDT) X-Authentication-Warning: banana.cc.columbia.edu: sa2086 owned process doing -bs Date: Mon, 2 Jun 2008 12:50:41 -0400 (EDT) From: Salman Abdul Baset To: Laird Popkin In-Reply-To: <1865369468.307061212422766942.JavaMail.root@dkny.pando.com> Message-ID: References: <1865369468.307061212422766942.JavaMail.root@dkny.pando.com> User-Agent: Alpine 1.00 (SOC 882 2007-12-20) MIME-Version: 1.0 X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.63 on 128.59.29.6 Cc: ramit@pando.com, p2pi@ietf.org, p4pwg@yahoogroups.com Subject: Re: [p2pi] Thoughts on how IETF standards can help P2P/ISPs X-BeenThere: p2pi@ietf.org X-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 > - Expose more information about TCP streams. For example, expose whether > the stream is congested. Currently some p2p applications use a variety > of techniques to attempt to guess whether a user's internet connection > is congested (e.g. monitoring ping times), and measures stream > throughput which could be viewed as a very rough measure of congestion, > but it would be more accurate and efficient if TCP told the application > when a stream was congested. Even better would be to get some indication > of where the congestion occurred. For example, if the congestion is in > the 'last mile', or the other peer's 'last mile', or somewhere in > between, different responses would be appropriate. For example, if my > internet connection is fine, but the peer's connection is congested, I > should slow down transfers from that peer, and pull more from other > peers. This is, of course, easier said than done. It is possible to query the congestion state of a TCP connection in Linux using getsockopt() and tcp_info structure. It gives an indication whether a connection is in timeout, fast retransmit, fast recovery or congestion avoidance. It is also possible to query the TCP transmit and receive queue size (in addition to buffer size). I think Windows Vista implements a similar mechanism but not sure about it. > - Expose some measure of 'communications cost' so that p2p apps could > select the lowest cost available data sources. (This is what the P4P > protocol does, for example). If using this guidance benefits both P2Ps > and ISPs, it is a win-win. This is a fairly broad area that might > include a number of steps/messages/protocols in order to address service > location, mapping IPs to location, and "cost". The P4PWG is researching > this area, and while it feels a little early to propose a standard, it's > certainly an area (IMO) that could benefit from attention. Both short-term and long term solutions may be needed here. Mechanisms for delivering this cost need to be different than the ways in which cost can be specified. Solution spectrum ranges from passing the complete BGP state to end nodes to end-host driven computations for communication costs. > - ISP's could expose usage metrics. For example, if a user has a link > that is capable of 1 Mbps, has a monthly transfer capacity of 500 GB, > and has used 350 GB so far, then the application can make better > choices, and application users could make informed choices. If the ISP > could tell applications when the user's internet connection is > congested, that would be extremely helpful. Definitely. Perhaps, need to borrow ideas from the mobile networks/apps such as 'view my minutes' option or allow a user to see the usage statistics (iPhone). -s _______________________________________________ p2pi mailing list p2pi@ietf.org https://www.ietf.org/mailman/listinfo/p2pi From p2pi-bounces@ietf.org Mon Jun 2 10:44:20 2008 Return-Path: X-Original-To: p2pi-archive@ietf.org Delivered-To: ietfarch-p2pi-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 529123A6D4F; Mon, 2 Jun 2008 10:44:20 -0700 (PDT) X-Original-To: p2pi@core3.amsl.com Delivered-To: p2pi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8AA843A6D3F for ; Mon, 2 Jun 2008 10:44:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ENNZzyjgUNOM for ; Mon, 2 Jun 2008 10:44:18 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by core3.amsl.com (Postfix) with ESMTP id 4A4A33A6D75 for ; Mon, 2 Jun 2008 10:37:46 -0700 (PDT) Received: from [127.0.0.1] (nib.isi.edu [128.9.160.144]) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id m52HbPGS025988 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 2 Jun 2008 10:37:27 -0700 (PDT) Message-ID: <48442FD5.7020407@isi.edu> Date: Mon, 02 Jun 2008 10:37:25 -0700 From: Joe Touch User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: Laird Popkin References: <1865369468.307061212422766942.JavaMail.root@dkny.pando.com> In-Reply-To: <1865369468.307061212422766942.JavaMail.root@dkny.pando.com> X-Enigmail-Version: 0.95.6 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: ramit@pando.com, p2pi@ietf.org, p4pwg@yahoogroups.com Subject: Re: [p2pi] Thoughts on how IETF standards can help P2P/ISPs X-BeenThere: p2pi@ietf.org X-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="===============1243073882==" Sender: p2pi-bounces@ietf.org Errors-To: p2pi-bounces@ietf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============1243073882== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig4C401008938EF910753C32E0" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig4C401008938EF910753C32E0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Laird Popkin wrote: > As we discussed last week at the IETF P2Pi Workshop, here are a list of= some of the ways that IETF standards can potentially help P2P applicatio= ns make better network decisions, and thus help ISPs. This isn't a comple= te list, but I hope that it's at least a useful starting point for a disc= ussion. >=20 > - Expose more information about TCP streams. For example, expose > whether the stream is congested. Currently some p2p applications use a > variety of techniques to attempt to guess whether a user's internet > connection is congested (e.g. monitoring ping times), and measures > stream throughput which could be viewed as a very rough measure of > congestion, but it would be more accurate and efficient if TCP told the= > application when a stream was congested.=20 As others have posted, this information should be accessible. > Even better would be to get > some indication of where the congestion occurred. For example, if the > congestion is in the 'last mile', or the other peer's 'last mile', or > somewhere in between, different responses would be appropriate. For > example, if my internet connection is fine, but the peer's connection i= s > congested, I should slow down transfers from that peer, and pull more > from other peers. This is, of course, easier said than done. This is not feasible for a number of reasons, including the use of=20 tunnels and VPNs. It's possible to know whether the end systems are=20 loaded (applications can tell each other), but path limits are hard to=20 pin down. It's more useful to just try a few peers and see what works=20 than to assume this kind of information is (or ever will be) available. Joe --------------enig4C401008938EF910753C32E0 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFIRC/VE5f5cImnZrsRAnhGAJ4679RwNepPrK9RWO9EI90Dw9Cd1gCdFa07 C7qHY4j4/4fjhPrCFpyg12Q= =S6Hw -----END PGP SIGNATURE----- --------------enig4C401008938EF910753C32E0-- --===============1243073882== 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 --===============1243073882==-- From p2pi-bounces@ietf.org Mon Jun 2 10:55:35 2008 Return-Path: X-Original-To: p2pi-archive@ietf.org Delivered-To: ietfarch-p2pi-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DBB2C3A6B32; Mon, 2 Jun 2008 10:55:35 -0700 (PDT) X-Original-To: p2pi@core3.amsl.com Delivered-To: p2pi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 172543A6B32 for ; Mon, 2 Jun 2008 10:55:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.139 X-Spam-Level: X-Spam-Status: No, score=-6.139 tagged_above=-999 required=5 tests=[AWL=0.460, 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 Vi5QH0vey8BY for ; Mon, 2 Jun 2008 10:55:34 -0700 (PDT) Received: from fruitcake.ICSI.Berkeley.EDU (fruitcake.ICSI.Berkeley.EDU [192.150.186.11]) by core3.amsl.com (Postfix) with ESMTP id 8750228C1D9 for ; Mon, 2 Jun 2008 10:51:17 -0700 (PDT) Received: from [IPv6:::1] (fruitcake [192.150.186.11]) by fruitcake.ICSI.Berkeley.EDU (8.12.11.20060614/8.12.11) with ESMTP id m52HpD6Q017153; Mon, 2 Jun 2008 10:51:13 -0700 (PDT) Message-Id: <2E865AA6-EED7-416F-BB69-16F912197E59@icsi.berkeley.edu> From: Nicholas Weaver To: Joe Touch In-Reply-To: <48442FD5.7020407@isi.edu> Mime-Version: 1.0 (Apple Message framework v924) Date: Mon, 2 Jun 2008 10:51:12 -0700 References: <1865369468.307061212422766942.JavaMail.root@dkny.pando.com> <48442FD5.7020407@isi.edu> X-Mailer: Apple Mail (2.924) Cc: p2pi@ietf.org, ramit@pando.com, Nicholas Weaver , p4pwg@yahoogroups.com Subject: Re: [p2pi] Thoughts on how IETF standards can help P2P/ISPs X-BeenThere: p2pi@ietf.org X-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 Jun 2, 2008, at 10:37 AM, Joe Touch wrote: > > >> Even better would be to get >> some indication of where the congestion occurred. For example, if the >> congestion is in the 'last mile', or the other peer's 'last mile', or >> somewhere in between, different responses would be appropriate. For >> example, if my internet connection is fine, but the peer's >> connection is >> congested, I should slow down transfers from that peer, and pull more >> from other peers. This is, of course, easier said than done. > > This is not feasible for a number of reasons, including the use of > tunnels and VPNs. It's possible to know whether the end systems are > loaded (applications can tell each other), but path limits are hard > to pin down. It's more useful to just try a few peers and see what > works than to assume this kind of information is (or ever will be) > available. Bulk data P2P can actually tell this if the TCP access API is suitable, by looking for correlations. If its just one flow that is seeing congestion, assume it is the other side. If multiple flows are seeing congestion, then the problem probably is at your end. _______________________________________________ p2pi mailing list p2pi@ietf.org https://www.ietf.org/mailman/listinfo/p2pi From p2pi-bounces@ietf.org Mon Jun 2 10:58:36 2008 Return-Path: X-Original-To: p2pi-archive@ietf.org Delivered-To: ietfarch-p2pi-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ED8733A6840; Mon, 2 Jun 2008 10:58: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 E82853A6915 for ; Mon, 2 Jun 2008 10:58:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.065 X-Spam-Level: X-Spam-Status: No, score=-10.065 tagged_above=-999 required=5 tests=[AWL=0.200, BAYES_00=-2.599, HABEAS_ACCREDITED_COI=-8, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v4QqjK5M3De3 for ; Mon, 2 Jun 2008 10:58:34 -0700 (PDT) Received: from dkny.pando.com (dkny.pando.com [67.99.55.163]) by core3.amsl.com (Postfix) with ESMTP id 4BA353A6840 for ; Mon, 2 Jun 2008 10:58:22 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by dkny.pando.com (Postfix) with ESMTP id 994E0E10C4C; Mon, 2 Jun 2008 13:58:23 -0400 (EDT) X-Virus-Scanned: amavisd-new at Received: from dkny.pando.com ([127.0.0.1]) by localhost (dkny.pando.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h0Hlh68WzZrv; Mon, 2 Jun 2008 13:58:23 -0400 (EDT) Received: from dkny.pando.com (dkny.pando.com [10.10.60.11]) by dkny.pando.com (Postfix) with ESMTP id 0B5B2E10C45; Mon, 2 Jun 2008 13:58:23 -0400 (EDT) Date: Mon, 2 Jun 2008 13:58:23 -0400 (EDT) From: Laird Popkin To: Nicholas Weaver Message-ID: <1199216619.309081212429503025.JavaMail.root@dkny.pando.com> In-Reply-To: <2E865AA6-EED7-416F-BB69-16F912197E59@icsi.berkeley.edu> MIME-Version: 1.0 X-Originating-IP: [10.10.20.73] Cc: p2pi@ietf.org, ramit@pando.com, Nicholas Weaver , p4pwg@yahoogroups.com, Joe Touch Subject: Re: [p2pi] Thoughts on how IETF standards can help P2P/ISPs X-BeenThere: p2pi@ietf.org X-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 certainly understand why it's somewhere between hard and impossible to give precise congestion status in all cases, due to VPN's, etc.. That being said, even getting less precise guidance, and only in the more common cases, would help us make better decisions for large numbers of users. For example, being told when we're causing congestion of home consumer internet connections with single-NAT networks would help us "play nicely" for a large number of users. - Laird Popkin, CTO, Pando Networks mobile: 646/465-0570 ----- Original Message ----- From: "Nicholas Weaver" To: "Joe Touch" Cc: "Nicholas Weaver" , "Laird Popkin" , ramit@pando.com, p2pi@ietf.org, p4pwg@yahoogroups.com Sent: Monday, June 2, 2008 1:51:12 PM (GMT-0500) America/New_York Subject: Re: [p2pi] Thoughts on how IETF standards can help P2P/ISPs On Jun 2, 2008, at 10:37 AM, Joe Touch wrote: > > >> Even better would be to get >> some indication of where the congestion occurred. For example, if the >> congestion is in the 'last mile', or the other peer's 'last mile', or >> somewhere in between, different responses would be appropriate. For >> example, if my internet connection is fine, but the peer's >> connection is >> congested, I should slow down transfers from that peer, and pull more >> from other peers. This is, of course, easier said than done. > > This is not feasible for a number of reasons, including the use of > tunnels and VPNs. It's possible to know whether the end systems are > loaded (applications can tell each other), but path limits are hard > to pin down. It's more useful to just try a few peers and see what > works than to assume this kind of information is (or ever will be) > available. Bulk data P2P can actually tell this if the TCP access API is suitable, by looking for correlations. If its just one flow that is seeing congestion, assume it is the other side. If multiple flows are seeing congestion, then the problem probably is at your end. _______________________________________________ p2pi mailing list p2pi@ietf.org https://www.ietf.org/mailman/listinfo/p2pi From p2pi-bounces@ietf.org Mon Jun 2 11:52:49 2008 Return-Path: X-Original-To: p2pi-archive@ietf.org Delivered-To: ietfarch-p2pi-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8631428C171; Mon, 2 Jun 2008 11:52:49 -0700 (PDT) X-Original-To: p2pi@core3.amsl.com Delivered-To: p2pi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 54B3028C137 for ; Mon, 2 Jun 2008 11:52:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.976 X-Spam-Level: X-Spam-Status: No, score=-1.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x3FPSSBhXjQR for ; Mon, 2 Jun 2008 11:52:47 -0700 (PDT) Received: from yx-out-2324.google.com (yx-out-2324.google.com [74.125.44.28]) by core3.amsl.com (Postfix) with ESMTP id 8ABE728C184 for ; Mon, 2 Jun 2008 11:51:32 -0700 (PDT) Received: by yx-out-2324.google.com with SMTP id 8so103341yxg.49 for ; Mon, 02 Jun 2008 11:51:31 -0700 (PDT) Received: by 10.142.136.16 with SMTP id j16mr1687554wfd.292.1212432689609; Mon, 02 Jun 2008 11:51:29 -0700 (PDT) Received: by 10.142.186.7 with HTTP; Mon, 2 Jun 2008 11:51:29 -0700 (PDT) Message-ID: <3efc39a60806021151j4b7d97e2p17e7ea9a1bd9be6c@mail.gmail.com> Date: Mon, 2 Jun 2008 11:51:29 -0700 From: "Robb Topolski" To: p2pi@ietf.org In-Reply-To: <453197743.307691212424858006.JavaMail.root@dkny.pando.com> MIME-Version: 1.0 References: <2025055099.307671212424833653.JavaMail.root@dkny.pando.com> <453197743.307691212424858006.JavaMail.root@dkny.pando.com> 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: multipart/mixed; boundary="===============1711403319==" Sender: p2pi-bounces@ietf.org Errors-To: p2pi-bounces@ietf.org --===============1711403319== Content-Type: multipart/alternative; boundary="----=_Part_15737_1267157.1212432689621" ------=_Part_15737_1267157.1212432689621 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline On Mon, Jun 2, 2008 at 9:40 AM, Laird Popkin wrote: > > Very interesting stuff. Nice ads on the page, too. :-) > > > My apologies to all -- I run an ad-blocker and didn't see anything. I apologize if that was not work-safe. -- Robb Topolski (robb@funchords.com) Hillsboro, Oregon USA http://www.funchords.com/ ------=_Part_15737_1267157.1212432689621 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline

On Mon, Jun 2, 2008 at 9:40 AM, Laird Popkin <laird@pando.com> wrote:

Very interesting stuff. Nice ads on the page, too. :-)



My apologies to all -- I run an ad-blocker and didn't see anything.  I apologize if that was not work-safe. 

--
Robb Topolski (robb@funchords.com)
Hillsboro, Oregon USA
http://www.funchords.com/ ------=_Part_15737_1267157.1212432689621-- --===============1711403319== 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 --===============1711403319==-- From p2pi-bounces@ietf.org Mon Jun 2 11: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 BF7323A69DA; Mon, 2 Jun 2008 11: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 5C3BE3A6B24 for ; Mon, 2 Jun 2008 11:53:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.359 X-Spam-Level: X-Spam-Status: No, score=-1.359 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, SARE_LWSHORTT=1.24] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6SasDc4mkjO9 for ; Mon, 2 Jun 2008 11:53:01 -0700 (PDT) Received: from mailhost.jlc.net (mailhost.jlc.net [199.201.159.9]) by core3.amsl.com (Postfix) with ESMTP id 862E03A69B1 for ; Mon, 2 Jun 2008 11:52:18 -0700 (PDT) Received: by mailhost.jlc.net (Postfix, from userid 104) id 7866433C29; Mon, 2 Jun 2008 14:52:20 -0400 (EDT) Date: Mon, 2 Jun 2008 14:52:20 -0400 From: John Leslie To: Nicholas Weaver Message-ID: <20080602185220.GA10817@verdi> References: <06B2829F-96D5-4292-B18C-E1EBEF8A4C64@icsi.berkeley.edu> Mime-Version: 1.0 Content-Disposition: inline In-Reply-To: <06B2829F-96D5-4292-B18C-E1EBEF8A4C64@icsi.berkeley.edu> User-Agent: Mutt/1.4.1i Cc: p2pi@ietf.org Subject: Re: [p2pi] One thought on "leech killing" X-BeenThere: p2pi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: P2P Infrastructure Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: p2pi-bounces@ietf.org Errors-To: p2pi-bounces@ietf.org Nicholas Weaver wrote: > > Comcast's traffic management of bulk-data P2P was reportedly just > "leech/seed" killing. And this appears to be correct based on our > study of injected RSTs (in submission) [1] > > The interesting question is as follows: > > 1: For leech killing, it can be strongly argued that this benefits the > customer while hurting BitTorrent. You would do better if your client > only talks to people who have blocks you don't have. Certainly there are any number of lawyers who would be happy to argue that for $250 per hour. I don't volunteer to pay them... I take issue with your measure of "benefit" to the customer. In general, the customer is considered a better judge of perceived benefit than the supplier. Or did Comcast offer this as a opt-in service to customers? If so, it would be interesting to know what percentage opted in. There are indeed _some_ customers driven by pure greed to take whatever they can and give nothing back. IMHO, those folks will leach off their neighbor's wireless instead of paying Comcast: thus I believe it reasonable to conclude that the _paying_ customers are willing to give something back. Recall that upstream and downstream bandwidths are separate issues: the technology imposes no significant cost on one from using the other. > 2: For seed killing, if the user was just a participant and did not > deliberately leave the client open, this benefits the customer. (I suppose I should thank you for recognizing that some customers intentionally act to give something back.) This particular "benefit" escapes me. If the computer is unattended, I see no possibility of a "cost" to be avoided; if the user is typing or clicking to some other application, the "cost" is too small to measure. > 3: For seed killing, if the user is deliberately acting as a seed, > this penalizes the customer. And they should have been provided > notice and a workaround. There are shades of "deliberately"... They were, of course, provided notice of sorts -- the "no servers" clause in their service agreement. And I don't mean to fault Comcast for putting in such a clause. Nor is it necessarily Comcast's responsibility to provide the workaround. If Comcast is to be faulted here, it must be for "forging" the RSTs. > But the first two cases are part of the classic conflict in > BitTorrent: the rest of the swarm benefits from allowing leeching and > seeding, but the user doesn't (as well as any other flows sharing a > bottleneck with the user). Interestingly, this "classic conflict" was never talked about when BitTorrent was operating between user who all had symmetric upstream and downstream bit-rates. Indeed, I consider it wrong to cast the conflict that way for asymmetric service (cable and most telco DSL). Instead, I would cast the conflict as a failure of P2P programmers to recognize upstream congestion issues and ensure that they don't overload the upstream. > This brings up two interesting questions: > > a) Is it ok for ISP traffic management be limited to solely > benefitting their customers or must it ignore behavior that benefits > the rest of the aggregate that have the effect of penalizing ALL their > customers? Clearly, "must ignore" would be stupid. To say it more nicely, any ISP whose customers experience excessive upstream congestion "must" do something to alleviate it. Ideally, this would include any necessary upgrades to increase upstream bandwidth. In the short term, there are a number of well-established principles for bandwidth limiting. (Google for "dummynet" if you don't know them.) > b) How do bulk-data P2P systems evolve if participants are FORCED to > eliminate "altruistic" behavior (allowing leeches), but limited to > "reciprical" and "greedy" behaviors? I don't understand the question. -- John Leslie _______________________________________________ p2pi mailing list p2pi@ietf.org https://www.ietf.org/mailman/listinfo/p2pi From p2pi-bounces@ietf.org Mon Jun 2 12:12: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 49F0F3A6B17; Mon, 2 Jun 2008 12:12: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 B3B0A3A68F1 for ; Mon, 2 Jun 2008 12:12:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.164 X-Spam-Level: ** X-Spam-Status: No, score=2.164 tagged_above=-999 required=5 tests=[BAYES_50=0.001, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, HTML_MESSAGE=0.001, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rpDibZaqOqPU for ; Mon, 2 Jun 2008 12:11:57 -0700 (PDT) Received: from 1401b.ifpi.org (unknown [195.40.39.2]) by core3.amsl.com (Postfix) with ESMTP id 7868928C212 for ; Mon, 2 Jun 2008 12:05:20 -0700 (PDT) Received: from 1501a.ifpi.org (Not Verified[172.16.100.35]) by 1401b.ifpi.org with MailMarshal (v6, 4, 1, 5038) id ; Mon, 02 Jun 2008 20:05:23 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 2 Jun 2008 20:05:16 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [p2pi] My notes from today's workshop Thread-Index: AcjBBKlWdqnpO7JuRtWTkXI33wmHigD0NTfg References: <033801c8c104$9471e020$6401a8c0@china.huawei.com> From: "Paul Jessop" To: "Spencer Dawkins" , 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="===============2127754305==" Sender: p2pi-bounces@ietf.org Errors-To: p2pi-bounces@ietf.org This is a multi-part message in MIME format. --===============2127754305== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C8C4E3.9BB56CDD" This is a multi-part message in MIME format. ------_=_NextPart_001_01C8C4E3.9BB56CDD Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Spencer, =20 Thanks for circulating this. Very helpful - it captures several points that I missed in my own notes. =20 I have a comment that I've like to see included after the "Not dealing with illegal traffic" line: =20 Paul Jessop (RIAA) suggested that this restricted focus was not in accordance with the meeting call which was much broader in scope. He suggested that IETF could address technical issues associated with the ability to exclude illegal content which would itself reduce network congestion. =20 This was rejected, principally on the grounds that IETF is an international standards body and it is impossible to determine whether content is illegal or not at any particular place. =20 I think I've captured that exchange accurately. =20 Thanks, =20 Paul =20 Paul Jessop CTO RIAA =20 ________________________________ From: p2pi-bounces@ietf.org [mailto:p2pi-bounces@ietf.org] On Behalf Of Spencer Dawkins Sent: 28 May 2008 21:51 To: p2pi@ietf.org Subject: [p2pi] My notes from today's workshop =20 Here's what I captured... Spencer 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_01C8C4E3.9BB56CDD Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Spencer,

 

Thanks for circulating this. Very = helpful - it captures several points that I missed in my own = notes.

 

I have a comment that I’ve = like to see included after the “Not dealing with illegal traffic” = line:

 

Paul Jessop (RIAA) suggested that this restricted = focus was not in accordance with the meeting call which was much broader in scope. = He suggested that IETF could address technical issues associated with the = ability to exclude illegal content which would itself reduce network = congestion.

 

This was rejected, principally on the grounds that = IETF is an international standards body and it is impossible to determine = whether content is illegal or not at any particular = place.

 

I think I’ve captured that = exchange accurately.

 

Thanks,

=

 

Paul

 

Paul = Jessop

CTO

RIAA

 

From: = p2pi-bounces@ietf.org [mailto:p2pi-bounces@ietf.org] On = Behalf Of Spencer Dawkins
Sent: 28 May 2008 = 21:51
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:

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

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

·        = ; 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.

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”.

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.

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

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.

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. =

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”. =

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. =

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.

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. =

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.

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?

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).

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_01C8C4E3.9BB56CDD-- --===============2127754305== 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 --===============2127754305==-- From p2pi-bounces@ietf.org Mon Jun 2 12:54: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 AED8328C18A; Mon, 2 Jun 2008 12:54: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 44F9C3A6A0F for ; Mon, 2 Jun 2008 12:54:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.676 X-Spam-Level: X-Spam-Status: No, score=-0.676 tagged_above=-999 required=5 tests=[AWL=-1.300, BAYES_50=0.001, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GbOgkDVEZCC7 for ; Mon, 2 Jun 2008 12:54:22 -0700 (PDT) Received: from yx-out-2324.google.com (yx-out-2324.google.com [74.125.44.28]) by core3.amsl.com (Postfix) with ESMTP id B6F0228C1AC for ; Mon, 2 Jun 2008 12:47:46 -0700 (PDT) Received: by yx-out-2324.google.com with SMTP id 8so115303yxg.49 for ; Mon, 02 Jun 2008 12:47:47 -0700 (PDT) Received: by 10.142.147.15 with SMTP id u15mr3728429wfd.149.1212436066375; Mon, 02 Jun 2008 12:47:46 -0700 (PDT) Received: by 10.142.186.7 with HTTP; Mon, 2 Jun 2008 12:47:46 -0700 (PDT) Message-ID: <3efc39a60806021247u87cec37o759cc388d11f21bd@mail.gmail.com> Date: Mon, 2 Jun 2008 12:47:46 -0700 From: "Robb Topolski" To: p2pi@ietf.org MIME-Version: 1.0 Subject: [p2pi] Using Remote Servers, known as Seedboxes, to reduce the uplink strain on last-mile Cable Internet systems X-BeenThere: p2pi@ietf.org X-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="===============2009041217==" Sender: p2pi-bounces@ietf.org Errors-To: p2pi-bounces@ietf.org --===============2009041217== Content-Type: multipart/alternative; boundary="----=_Part_15974_25007632.1212436066365" ------=_Part_15974_25007632.1212436066365 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Back in the dial-up days, many ISPs offered a small amount of space on a server for webhosting. This offer removed the incentive of their users to try and stay online 24/7/365 in order to run webservers over their dialup links. Most P2P users want to download. Only a small percentage offers new or rare content for the sake of doing so. Most downloaders don't mind uploading. Many do enjoy the community culture in file sharing and feel that they're "giving back" by uploading more than 100% of the bytes that they downloaded. Other P2P users "give back" by uploading new or rare content, moderating the various forums or databases, developing software, writing news articles, donating money, and etc.. However, these desires are somewhat secondary. There's this "DOCSIS" zone between "Cable HSI - Internet Side" and "Cable HSI - Customer Side." (Owing its origin to the legacy CableTV system and its bottlenecked configuration to a much older non-symmetric Internet use pattern, DOCSIS equipment enables Internet protocols on the cable system.) With a normal BitTorrent download, (normal meaning one that will finish with a 1 to 1 or 100% upload/download ratio), each byte of that file crosses the "DOCSIS zone" twice. Once down (usually okay), once back up (usually constrained). I propose that Cable HSI providers offer a new free service to encourage better bandwidth behavior that will significantly reduce the number of P2P bytes crossing DOCSIS in the upload direction. The concept is called a "seedbox" and it is described in several searchable P2P articles. Seedboxes are remote servers (or virtual servers) located at a point in the network with lower bandwidth constraints. In a Cable HSI system, these could be installed in each metropolitan point-of-presence and offered much as an ISP's optional "Personal Home Page" service is offered. Each (virtual) box could handle a number of login sessions with enough allocated memory to handle the file-transfer applications (which is not necessarily a lot, since these applications are normally designed to run in the background). For this idea to work, the user and the creative-works community both must trust the ISP as least as much as they do now. Use of a seedbox should offer no less privacy than a subscriber's IP own address, as privacy is a concern among many users who are rebellious against claims of copyright holders. Likewise, it is important that copyright holders maintain their present ability to contact suspected infringers for the purposes of licensing a work or for legal enforcement. To succeed, the solution employed by the ISP must not offer users any less privacy or rightsholders any more disclosure than is the current status quo. If a user is uploading a new creative work, the seedbox does not help the Cable HSI last-mile uplink. However, this scenario is the rare exception (easily less than 5%). In all other cases, use of the seedbox eliminates dragging the bits across DOCSIS in the upload direction. Instead, the entire transaction first takes place on the seedbox. Then, the user downloads the archive from the seedbox to his home computer and may delete the seedbox copy. The ISP can administer the overall bandwidth provided to this service in such a way that promotes the appropriate user behavior. The "burstiness" behavior desired by surfers, game players, and VOIP users is restored to the DOCSIS segments as the seedboxes will now carry that load in a much more containable way. Thoughts, ideas, criticisms welcome... Robb Topolski -- Robb Topolski (robb@funchords.com) Hillsboro, Oregon USA http://www.funchords.com/ ------=_Part_15974_25007632.1212436066365 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Back in the dial-up days, many ISPs offered a small amount of space on a server for webhosting.  This offer removed the incentive of their users to try and stay online 24/7/365 in order to run webservers over their dialup links. 

Most P2P users want to download.  Only a small percentage offers new or rare content for the sake of doing so. 

Most downloaders don't mind uploading.  Many do enjoy the community culture in file sharing and feel that they're "giving back" by uploading more than 100% of the bytes that they downloaded.  Other P2P users "give back" by uploading new or rare content, moderating the various forums or databases, developing software, writing news articles, donating money, and etc.. However, these desires are somewhat secondary. 

There's this "DOCSIS" zone between "Cable HSI - Internet Side" and "Cable HSI - Customer Side." (Owing its origin to the legacy CableTV system and its bottlenecked configuration to a much older non-symmetric Internet use pattern, DOCSIS equipment enables Internet protocols on the cable system.)  With a normal BitTorrent download, (normal meaning one that will finish with a 1 to 1 or 100% upload/download ratio), each byte of that file crosses the "DOCSIS zone" twice. Once down (usually okay), once back up (usually constrained). 

I propose that Cable HSI providers offer a new free service to encourage better bandwidth behavior that will significantly reduce the number of P2P bytes crossing DOCSIS in the upload direction.

The concept is called a "seedbox" and it is described in several searchable P2P articles. Seedboxes are remote servers (or virtual servers) located at a point in the network with lower bandwidth constraints.  In a Cable HSI system, these could be installed in each metropolitan point-of-presence and offered much as an ISP's optional "Personal Home Page" service is offered.  Each (virtual) box could handle a number of login sessions with enough allocated memory to handle the file-transfer applications (which is not necessarily a lot, since these applications are normally designed to run in the background). 

For this idea to work, the user and the creative-works community both must trust the ISP as least as much as they do now.  Use of a seedbox should offer no less privacy than a subscriber's IP own address, as privacy is a concern among many users who are rebellious against claims of copyright holders.  Likewise, it is important that copyright holders maintain their present ability to contact suspected infringers for the purposes of licensing a work or for legal enforcement.   To succeed, the solution employed by the ISP must not offer users any less privacy or rightsholders any more disclosure than is the current status quo.

If a user is uploading a new creative work, the seedbox does not help the Cable HSI last-mile uplink.  However, this scenario is the rare exception (easily less than 5%).  In all other cases, use of the seedbox eliminates dragging the bits across DOCSIS in the upload direction.  Instead, the entire transaction first takes place on the seedbox.  Then, the user downloads the archive from the seedbox to his home computer and may delete the seedbox copy.

The ISP can administer the overall bandwidth provided to this service in such a way that promotes the appropriate user behavior.  The "burstiness" behavior desired by surfers, game players, and VOIP users is restored to the DOCSIS segments as the seedboxes will now carry that load in a much more containable way.

Thoughts, ideas, criticisms welcome...

Robb Topolski

--
Robb Topolski (robb@funchords.com)
Hillsboro, Oregon USA
http://www.funchords.com/ ------=_Part_15974_25007632.1212436066365-- --===============2009041217== 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 --===============2009041217==-- From p2pi-bounces@ietf.org Mon Jun 2 12:56:54 2008 Return-Path: X-Original-To: p2pi-archive@ietf.org Delivered-To: ietfarch-p2pi-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0E7B43A6C22; Mon, 2 Jun 2008 12:56:54 -0700 (PDT) X-Original-To: p2pi@core3.amsl.com Delivered-To: p2pi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5A7183A69B1 for ; Mon, 2 Jun 2008 12:56:53 -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 RzL9SW9-H2fK for ; Mon, 2 Jun 2008 12:56:52 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by core3.amsl.com (Postfix) with ESMTP id CED1828C22E for ; Mon, 2 Jun 2008 12:50:59 -0700 (PDT) Received: from [127.0.0.1] (116.sub-75-217-247.myvzw.com [75.217.247.116]) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id m52Jo2au020150 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 2 Jun 2008 12:50:05 -0700 (PDT) Message-ID: <48444EE9.2030102@isi.edu> Date: Mon, 02 Jun 2008 12:50:01 -0700 From: Joe Touch User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: Nicholas Weaver References: <1865369468.307061212422766942.JavaMail.root@dkny.pando.com> <48442FD5.7020407@isi.edu> <2E865AA6-EED7-416F-BB69-16F912197E59@icsi.berkeley.edu> In-Reply-To: <2E865AA6-EED7-416F-BB69-16F912197E59@icsi.berkeley.edu> X-Enigmail-Version: 0.95.6 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: ramit@pando.com, p2pi@ietf.org, p4pwg@yahoogroups.com Subject: Re: [p2pi] Thoughts on how IETF standards can help P2P/ISPs X-BeenThere: p2pi@ietf.org X-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="===============2132964008==" Sender: p2pi-bounces@ietf.org Errors-To: p2pi-bounces@ietf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============2132964008== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigFF2EF02AAB8CEE2804C5B7B0" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigFF2EF02AAB8CEE2804C5B7B0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Nicholas Weaver wrote: >=20 > On Jun 2, 2008, at 10:37 AM, Joe Touch wrote: >> >> >>> Even better would be to get >>> some indication of where the congestion occurred. For example, if the= >>> congestion is in the 'last mile', or the other peer's 'last mile', or= >>> somewhere in between, different responses would be appropriate. For >>> example, if my internet connection is fine, but the peer's connection= is >>> congested, I should slow down transfers from that peer, and pull more= >>> from other peers. This is, of course, easier said than done. >> >> This is not feasible for a number of reasons, including the use of=20 >> tunnels and VPNs. It's possible to know whether the end systems are=20 >> loaded (applications can tell each other), but path limits are hard to= =20 >> pin down. It's more useful to just try a few peers and see what works = >> than to assume this kind of information is (or ever will be) available= =2E >=20 > Bulk data P2P can actually tell this if the TCP access API is suitable,= =20 > by looking for correlations. If its just one flow that is seeing=20 > congestion, assume it is the other side. If multiple flows are seeing = > congestion, then the problem probably is at your end. It depends on where the multiple flows go; they could as easily all=20 experience congestion over a tunnel/VPN, even if they diverge and go to=20 different destinations. A single connection that experiences congestion=20 (out of multiples) does so where the connections diverge, but again that = could be anywhere. It would be useful not to over-tune P2P based on these sort of=20 assumptions, as a result. The best you can do is split things as follows:= Congestion in the uphill path (you to the core): - all connections more likley to experience similar congestion Congestion on the downhill path (core to the servers): - connections more likely to diverge Other inferences are, AFAICT, assuming too much. Joe --------------enigFF2EF02AAB8CEE2804C5B7B0 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFIRE7pE5f5cImnZrsRAoDvAJ97VCu9WtwQLadGpIbZNi9TiL340wCeLsjw wGRMOR3fsWahjFuJw0k9s/c= =gaOl -----END PGP SIGNATURE----- --------------enigFF2EF02AAB8CEE2804C5B7B0-- --===============2132964008== 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 --===============2132964008==-- From p2pi-bounces@ietf.org Mon Jun 2 13:16:55 2008 Return-Path: X-Original-To: p2pi-archive@ietf.org Delivered-To: ietfarch-p2pi-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 042663A67D2; Mon, 2 Jun 2008 13:16:55 -0700 (PDT) X-Original-To: p2pi@core3.amsl.com Delivered-To: p2pi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 16AE23A67D2 for ; Mon, 2 Jun 2008 13:16:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.864 X-Spam-Level: * X-Spam-Status: No, score=1.864 tagged_above=-999 required=5 tests=[BAYES_50=0.001, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SARE_LWSHORTT=1.24] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kVsecZpFhPT7 for ; Mon, 2 Jun 2008 13:16:52 -0700 (PDT) Received: from rn-out-0910.google.com (rn-out-0910.google.com [64.233.170.190]) by core3.amsl.com (Postfix) with ESMTP id 348753A67A4 for ; Mon, 2 Jun 2008 13:16:51 -0700 (PDT) Received: by rn-out-0910.google.com with SMTP id m36so209161rnd.18 for ; Mon, 02 Jun 2008 13:16:53 -0700 (PDT) Received: by 10.142.179.12 with SMTP id b12mr3728324wff.249.1212437780359; Mon, 02 Jun 2008 13:16:20 -0700 (PDT) Received: by 10.142.186.7 with HTTP; Mon, 2 Jun 2008 13:16:20 -0700 (PDT) Message-ID: <3efc39a60806021316q2a000e98t78a2c51bffa543fc@mail.gmail.com> Date: Mon, 2 Jun 2008 13:16:20 -0700 From: "Robb Topolski" To: p2pi@ietf.org In-Reply-To: <20080602185220.GA10817@verdi> MIME-Version: 1.0 References: <06B2829F-96D5-4292-B18C-E1EBEF8A4C64@icsi.berkeley.edu> <20080602185220.GA10817@verdi> Subject: Re: [p2pi] One thought on "leech killing" X-BeenThere: p2pi@ietf.org X-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="===============1624573267==" Sender: p2pi-bounces@ietf.org Errors-To: p2pi-bounces@ietf.org --===============1624573267== Content-Type: multipart/alternative; boundary="----=_Part_16053_1213817.1212437780343" ------=_Part_16053_1213817.1212437780343 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline To John: I liked your post very much and agreed with much of it. Instead, I would cast the conflict as a failure of P2P programmers > to recognize upstream congestion issues and ensure that they don't > overload the upstream. > With respect, the P2P programmers that I've met are very congestion sensitive. There is no benefit to cramming data down a congested path like HTTP or FTP does. BitTorrent is designed to avoid congestion! If a link begins to slow or stops due to congestion, it stops that one and begins to upload on another one. And the number of slots it will upload on start at 3 or 4 per transfer (given most U.S.A. uplink allocations, but this number is growing as FIOS competition drives our upload speeds higher and I'm a little concerned a little about that). Nicholas Weaver wrote: > a) Is it ok for ISP traffic management be limited to solely > benefitting their customers or must it ignore behavior that benefits > the rest of the aggregate that have the effect of penalizing ALL their > customers? I maintain that prolonged periods of congestion mean that you've already failed to manage the network. Trying to figure out which bucket of water to throw out before another is ignoring the fact that the boat is sinking. > b) How do bulk-data P2P systems evolve if participants are FORCED to > eliminate "altruistic" behavior (allowing leeches), but limited to > "reciprical" and "greedy" behaviors? Indeed. But why should Internet users be forced to do anything? The beauty of the Internet is its wonderful cacophony of interactive uses. I'm not "tuning in" to the limited selection of channels in my area. It's not delivered one-way only. Your question contains the answer -- forcing someone to use the Internet in a certain way is usually incompatible with a free and open Internet. Banning something on the net seems wrong on its face. I remember when spam started to really grow as a problem, many of us were debating whether or not to care. Most of the ads then were legitimate, but they were simply widely broadcast and nearly always unwanted. At first, banning spam outright seemed wrong unless there was another reason (forgery, illegality). We spent a lot of time on the question of under what conditions to block it. It did help that email was blocked at the service level and not at the protocol level -- my server, my rules applied. Network access and transit operators do not have that privilege. Robb Topolski On Mon, Jun 2, 2008 at 11:52 AM, John Leslie wrote: > Nicholas Weaver wrote: > > > > Comcast's traffic management of bulk-data P2P was reportedly just > > "leech/seed" killing. And this appears to be correct based on our > > study of injected RSTs (in submission) [1] > > > > The interesting question is as follows: > > > > 1: For leech killing, it can be strongly argued that this benefits the > > customer while hurting BitTorrent. You would do better if your client > > only talks to people who have blocks you don't have. > > Certainly there are any number of lawyers who would be happy to argue > that for $250 per hour. I don't volunteer to pay them... > > I take issue with your measure of "benefit" to the customer. In general, > the customer is considered a better judge of perceived benefit than the > supplier. Or did Comcast offer this as a opt-in service to customers? If > so, it would be interesting to know what percentage opted in. > > There are indeed _some_ customers driven by pure greed to take whatever > they can and give nothing back. IMHO, those folks will leach off their > neighbor's wireless instead of paying Comcast: thus I believe it reasonable > to conclude that the _paying_ customers are willing to give something back. > > Recall that upstream and downstream bandwidths are separate issues: > the technology imposes no significant cost on one from using the other. > > > 2: For seed killing, if the user was just a participant and did not > > deliberately leave the client open, this benefits the customer. > > (I suppose I should thank you for recognizing that some customers > intentionally act to give something back.) > > This particular "benefit" escapes me. If the computer is unattended, > I see no possibility of a "cost" to be avoided; if the user is typing > or clicking to some other application, the "cost" is too small to measure. > > > 3: For seed killing, if the user is deliberately acting as a seed, > > this penalizes the customer. And they should have been provided > > notice and a workaround. > > There are shades of "deliberately"... > > They were, of course, provided notice of sorts -- the "no servers" > clause in their service agreement. And I don't mean to fault Comcast > for putting in such a clause. Nor is it necessarily Comcast's > responsibility to provide the workaround. > > If Comcast is to be faulted here, it must be for "forging" the RSTs. > > > But the first two cases are part of the classic conflict in > > BitTorrent: the rest of the swarm benefits from allowing leeching and > > seeding, but the user doesn't (as well as any other flows sharing a > > bottleneck with the user). > > Interestingly, this "classic conflict" was never talked about when > BitTorrent was operating between user who all had symmetric upstream > and downstream bit-rates. Indeed, I consider it wrong to cast the > conflict that way for asymmetric service (cable and most telco DSL). > > Instead, I would cast the conflict as a failure of P2P programmers > to recognize upstream congestion issues and ensure that they don't > overload the upstream. > > > This brings up two interesting questions: > > > > a) Is it ok for ISP traffic management be limited to solely > > benefitting their customers or must it ignore behavior that benefits > > the rest of the aggregate that have the effect of penalizing ALL their > > customers? > > Clearly, "must ignore" would be stupid. > > To say it more nicely, any ISP whose customers experience excessive > upstream congestion "must" do something to alleviate it. Ideally, this > would include any necessary upgrades to increase upstream bandwidth. > In the short term, there are a number of well-established principles > for bandwidth limiting. (Google for "dummynet" if you don't know them.) > > > b) How do bulk-data P2P systems evolve if participants are FORCED to > > eliminate "altruistic" behavior (allowing leeches), but limited to > > "reciprical" and "greedy" behaviors? > > I don't understand the question. > > -- > John Leslie > _______________________________________________ > 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_16053_1213817.1212437780343 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline To John:

I liked your post very much and agreed with much of it.

  Instead, I would cast the conflict as a failure of P2P programmers
to recognize upstream congestion issues and ensure that they don't
overload the upstream.

With respect, the P2P programmers that I've met are very congestion sensitive.  There is no benefit to cramming data down a congested path like HTTP or FTP does.  BitTorrent is designed to avoid congestion!  If a link begins to slow or stops due to congestion, it stops that one and begins to upload on another one.  And the number of slots it will upload on start at 3 or 4 per transfer (given most U.S.A. uplink allocations, but this number is growing as FIOS competition drives our upload speeds higher and I'm a little concerned a little about that).

Nicholas Weaver <nweaver@ICSI.Berkeley.EDU> wrote:
> a) Is it ok for ISP traffic management be limited to solely
> benefitting their customers or must it ignore behavior that benefits
> the rest of the aggregate that have the effect of penalizing ALL their
> customers?

I maintain that prolonged periods of congestion mean that you've already failed to manage the network.  Trying to figure out which bucket of water to throw out before another is ignoring the fact that the boat is sinking.

> b)  How do bulk-data P2P systems evolve if participants are FORCED to
> eliminate "altruistic" behavior (allowing leeches), but limited to
> "reciprical" and "greedy" behaviors?

Indeed.  But why should Internet users be forced to do anything?  The beauty of the Internet is its wonderful cacophony of interactive uses.  I'm not "tuning in" to the limited selection of channels in my area.  It's not delivered one-way only.  Your question contains the answer -- forcing someone to use the Internet in a certain way is usually incompatible with a free and open Internet.

Banning something on the net seems wrong on its face.  I remember when spam started to really grow as a problem, many of us were debating whether or not to care.  Most of the ads then were legitimate, but they were simply widely broadcast and nearly always unwanted.  At first, banning spam outright seemed wrong unless there was another reason (forgery, illegality).  We spent a lot of time on the question of under what conditions to block it.   It did help that email was blocked at the service level and not at the protocol level -- my server, my rules applied.  Network access and transit operators do not have that privilege.

Robb Topolski

On Mon, Jun 2, 2008 at 11:52 AM, John Leslie <john@jlc.net> wrote:
Nicholas Weaver <nweaver@ICSI.Berkeley.EDU> wrote:
>
> Comcast's traffic management of bulk-data P2P was reportedly just
> "leech/seed" killing.  And this appears to be correct based on our
> study of injected RSTs (in submission) [1]
>
> The interesting question is as follows:
>
> 1: For leech killing, it can be strongly argued that this benefits the
> customer while hurting BitTorrent.  You would do better if your client
> only talks to people who have blocks you don't have.

  Certainly there are any number of lawyers who would be happy to argue
that for $250 per hour. I don't volunteer to pay them...

  I take issue with your measure of "benefit" to the customer. In general,
the customer is considered a better judge of perceived benefit than the
supplier. Or did Comcast offer this as a opt-in service to customers? If
so, it would be interesting to know what percentage opted in.

  There are indeed _some_ customers driven by pure greed to take whatever
they can and give nothing back. IMHO, those folks will leach off their
neighbor's wireless instead of paying Comcast: thus I believe it reasonable
to conclude that the _paying_ customers are willing to give something back.

  Recall that upstream and downstream bandwidths are separate issues:
the technology imposes no significant cost on one from using the other.

> 2: For seed killing, if the user was just a participant and did not
> deliberately leave the client open, this benefits the customer.

  (I suppose I should thank you for recognizing that some customers
intentionally act to give something back.)

  This particular "benefit" escapes me. If the computer is unattended,
I see no possibility of a "cost" to be avoided; if the user is typing
or clicking to some other application, the "cost" is too small to measure.

> 3: For seed killing, if the user is deliberately acting as a seed,
> this penalizes the customer.  And they should have been provided
> notice and a workaround.

  There are shades of "deliberately"...

  They were, of course, provided notice of sorts -- the "no servers"
clause in their service agreement. And I don't mean to fault Comcast
for putting in such a clause. Nor is it necessarily Comcast's
responsibility to provide the workaround.

  If Comcast is to be faulted here, it must be for "forging" the RSTs.

> But the first two cases are part of the classic conflict in
> BitTorrent:  the rest of the swarm benefits from allowing leeching and
> seeding, but the user doesn't (as well as any other flows sharing a
> bottleneck with the user).

  Interestingly, this "classic conflict" was never talked about when
BitTorrent was operating between user who all had symmetric upstream
and downstream bit-rates. Indeed, I consider it wrong to cast the
conflict that way for asymmetric service (cable and most telco DSL).

  Instead, I would cast the conflict as a failure of P2P programmers
to recognize upstream congestion issues and ensure that they don't
overload the upstream.

> This brings up two interesting questions:
>
> a) Is it ok for ISP traffic management be limited to solely
> benefitting their customers or must it ignore behavior that benefits
> the rest of the aggregate that have the effect of penalizing ALL their
> customers?

  Clearly, "must ignore" would be stupid.

  To say it more nicely, any ISP whose customers experience excessive
upstream congestion "must" do something to alleviate it. Ideally, this
would include any necessary upgrades to increase upstream bandwidth.
In the short term, there are a number of well-established principles
for bandwidth limiting. (Google for "dummynet" if you don't know them.)

> b)  How do bulk-data P2P systems evolve if participants are FORCED to
> eliminate "altruistic" behavior (allowing leeches), but limited to
> "reciprical" and "greedy" behaviors?

  I don't understand the question.

--
John Leslie <john@jlc.net>
_______________________________________________
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_16053_1213817.1212437780343-- --===============1624573267== 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 --===============1624573267==-- From p2pi-bounces@ietf.org Mon Jun 2 14:14:31 2008 Return-Path: X-Original-To: p2pi-archive@ietf.org Delivered-To: ietfarch-p2pi-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 21E393A68D4; Mon, 2 Jun 2008 14:14:31 -0700 (PDT) X-Original-To: p2pi@core3.amsl.com Delivered-To: p2pi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B23973A68D4 for ; Mon, 2 Jun 2008 14:14:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.231 X-Spam-Level: X-Spam-Status: No, score=-6.231 tagged_above=-999 required=5 tests=[AWL=0.368, 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 yrN-VESm9Ri1 for ; Mon, 2 Jun 2008 14:14:28 -0700 (PDT) Received: from fruitcake.ICSI.Berkeley.EDU (fruitcake.ICSI.Berkeley.EDU [192.150.186.11]) by core3.amsl.com (Postfix) with ESMTP id DDF7B3A67A6 for ; Mon, 2 Jun 2008 14:14:28 -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 m52LE1Ef029050; Mon, 2 Jun 2008 14:14:01 -0700 (PDT) Message-Id: From: Nicholas Weaver To: p2pi@ietf.org Mime-Version: 1.0 (Apple Message framework v924) Date: Mon, 2 Jun 2008 14:14:01 -0700 X-Mailer: Apple Mail (2.924) Cc: Nicholas Weaver Subject: [p2pi] Stupid question, why not TCP Vegas? X-BeenThere: p2pi@ietf.org X-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 Pardon me for a stupid question: TCP Vegas is already well understood as being an effective delay-based congestion control protocol with only one problem: TCP Reno outcompetes it in the standard tuning, because Vegas backs off earlier. Yet these are exactly the features that bulk-data P2P would want for scavenger flows: It is more sensitive than TCP Reno, and it doesn't fill up buffers in overbuffered-equipment (no +1 second ping times). It is supported in the Linux kernel, and if there is compelling reason it could either get included into the Windows kernel or there is always the "alternate tcp.sys" hack that was first popularized when Windows added the Williamson-like outbound throttling. So the question is, why aren't the P2P developers pushing TCP Vegas, and using it whenever possible? If all TCP flows related to a program can be set to use delay-based congestion control, this should prevent the buffer occupancy problems they experience on the outbound link and, because it is less aggressive than standard TCP Reno (and variants), the default outbound transfer rate can be uncapped (or at least relaxed) without causing problems, and if the other side is using Vegas as well, the inbound rate can also be uncapped. It seems that what would be needed is 1: Windows support for TCP Vegas, either as a Microsoft updates or the alternate tcp.sys. 2: A way of per-connection or per-app specifying the desired congestion control, so that a P2P program can specify "TCP Vegas". (Linux is a global /proc option rather than a per-app option IIRC). Thoughts? Comments? (If this would work, it also suggests that I was wrong about "no incentive to be a scavenger": I forgot that you can actually be better at using bandwidth (eg, TCP Vegas, because it doesn't sawtooth between full bandwidth and 1/2 bandwidth, especially when its the only flow) while being friendlier than vanilla TCP) _______________________________________________ p2pi mailing list p2pi@ietf.org https://www.ietf.org/mailman/listinfo/p2pi From p2pi-bounces@ietf.org Mon Jun 2 14:43: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 0D76F3A67A4; Mon, 2 Jun 2008 14:43: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 1316528C0D0 for ; Mon, 2 Jun 2008 14:43:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KrnX+-+vP2cB for ; Mon, 2 Jun 2008 14:43:16 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by core3.amsl.com (Postfix) with ESMTP id 8226C3A6A6E for ; Mon, 2 Jun 2008 14:42:49 -0700 (PDT) Received: from [127.0.0.1] (147.sub-75-214-77.myvzw.com [75.214.77.147]) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id m52LgJlC028203 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 2 Jun 2008 14:42:22 -0700 (PDT) Message-ID: <4844693A.1030606@isi.edu> Date: Mon, 02 Jun 2008 14:42:18 -0700 From: Joe Touch User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: Nicholas Weaver References: In-Reply-To: X-Enigmail-Version: 0.95.6 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: p2pi@ietf.org Subject: Re: [p2pi] Stupid question, why not TCP Vegas? X-BeenThere: p2pi@ietf.org X-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="===============0289523809==" Sender: p2pi-bounces@ietf.org Errors-To: p2pi-bounces@ietf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============0289523809== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigAF03F9B363A70FB1F0B21B43" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigAF03F9B363A70FB1F0B21B43 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Nicholas Weaver wrote: > Pardon me for a stupid question: =2E.. > So the question is, why aren't the P2P developers pushing TCP Vegas, =20 > and using it whenever possible? It loses compared to Reno - as you noted. It's also more sensitive to=20 changes in RTT, BW due to dynamic routing. > 2: A way of per-connection or per-app specifying the desired =20 > congestion control, so that a P2P program can specify "TCP Vegas". =20 > (Linux is a global /proc option rather than a per-app option IIRC). >=20 > Thoughts? Comments? AFAICT, that requires a dual stack, one like Marko Zec's Clonable Stacks = (for FreeBSD). Joe --------------enigAF03F9B363A70FB1F0B21B43 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFIRGk6E5f5cImnZrsRAlU1AJ9A89EmZVd1XI0fT09F3iUSU7zxewCgtbFk 2NDjpDEQFPG0H+dH0f5SXZA= =UdJG -----END PGP SIGNATURE----- --------------enigAF03F9B363A70FB1F0B21B43-- --===============0289523809== 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 --===============0289523809==-- From p2pi-bounces@ietf.org Mon Jun 2 14:43: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 3B1C43A6A42; Mon, 2 Jun 2008 14:43: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 648BE3A6A1A for ; Mon, 2 Jun 2008 14:43:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.293 X-Spam-Level: X-Spam-Status: No, score=-6.293 tagged_above=-999 required=5 tests=[AWL=0.307, 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 Qw1XPx1QT+-m for ; Mon, 2 Jun 2008 14:43:16 -0700 (PDT) Received: from fruitcake.ICSI.Berkeley.EDU (fruitcake.ICSI.Berkeley.EDU [192.150.186.11]) by core3.amsl.com (Postfix) with ESMTP id 9F75428C13A for ; Mon, 2 Jun 2008 14:43:00 -0700 (PDT) Received: from [IPv6:::1] (fruitcake [192.150.186.11]) by fruitcake.ICSI.Berkeley.EDU (8.12.11.20060614/8.12.11) with ESMTP id m52LghcR004209; Mon, 2 Jun 2008 14:42:43 -0700 (PDT) Message-Id: From: Nicholas Weaver To: p2pi@ietf.org, Robb Topolski In-Reply-To: <1C57AC59-127F-46B2-AF38-1BB2ED880C3E@icsi.berkeley.edu> Mime-Version: 1.0 (Apple Message framework v924) Date: Mon, 2 Jun 2008 14:42:43 -0700 References: <06B2829F-96D5-4292-B18C-E1EBEF8A4C64@icsi.berkeley.edu> <20080602185220.GA10817@verdi> <3efc39a60806021316q2a000e98t78a2c51bffa543fc@mail.gmail.com> <1C57AC59-127F-46B2-AF38-1BB2ED880C3E@icsi.berkeley.edu> X-Mailer: Apple Mail (2.924) Cc: Nicholas Weaver Subject: Re: [p2pi] One thought on "leech killing" X-BeenThere: p2pi@ietf.org X-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 Jun 2, 2008, at 1:16 PM, Robb Topolski wrote: > > Nicholas Weaver wrote: > > a) Is it ok for ISP traffic management be limited to solely > > benefitting their customers or must it ignore behavior that benefits > > the rest of the aggregate that have the effect of penalizing ALL > their > > customers? > > I maintain that prolonged periods of congestion mean that you've > already failed to manage the network. Trying to figure out which > bucket of water to throw out before another is ignoring the fact > that the boat is sinking. > Or you throw off the suitcases full of lead... Your argument works when the congestion's cause is a large fraction of the user base. But when it is a small fraction of the user base and you maintain flat-rate pricing, it makes far more economic sense to employ traffic management techniques to prevent the heavy users from impacting everyone else. For example, Comcast's problem is very clear: DOCSIS, even DOCSIS 3, is a shared medium across a large group of users. So unless they are willing to pull fiber to the home [1], there is no miracle bandwidth- fairy that can come and solve their congestion problem: they HAVE to allocate that bandwidth between users in a way which maximizes the benefit for the maximum percentage of customers. And DOCSIS 3 is only 4x the bandwidth per channel of DOCSIS 2: the Japanese have shown that even 100 Mbps fiber-to-the-home can get congested with P2P traffic. [1] The only way fiber to the home happens is either government subsidies or when a Telco wants to break into the cable-TV business by pulling fiber and then getting a statewide license (Verizon). _______________________________________________ p2pi mailing list p2pi@ietf.org https://www.ietf.org/mailman/listinfo/p2pi From p2pi-bounces@ietf.org Mon Jun 2 15:23: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 20FCE28C21A; Mon, 2 Jun 2008 15:23: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 A183D28C21A for ; Mon, 2 Jun 2008 15:23:02 -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 OlU2BNcsxAmG for ; Mon, 2 Jun 2008 15:23:01 -0700 (PDT) Received: from maild.telecomitalia.it (maild.telecomitalia.it [156.54.233.30]) by core3.amsl.com (Postfix) with ESMTP id AA23F3A6A71 for ; Mon, 2 Jun 2008 15:15:38 -0700 (PDT) Received: from ptpxch008ba020.idc.cww.telecomitalia.it ([156.54.240.51]) by maild.telecomitalia.it with Microsoft SMTPSVC(6.0.3790.1830); Tue, 3 Jun 2008 00:15:37 +0200 Received: from GRFHUB702BA020.griffon.local ([10.188.101.112]) by ptpxch008ba020.idc.cww.telecomitalia.it with Microsoft SMTPSVC(6.0.3790.1830); Tue, 3 Jun 2008 00:15:37 +0200 Received: from [172.16.82.10] (163.162.180.246) by smtp.telecomitalia.it (10.188.101.115) with Microsoft SMTP Server (TLS) id 8.1.263.0; Tue, 3 Jun 2008 00:15:36 +0200 Message-ID: <484470F1.7000105@telecomitalia.it> Date: Tue, 3 Jun 2008 00:15:13 +0200 From: Enrico Marocco User-Agent: Mozilla-Thunderbird 2.0.0.14 (X11/20080509) MIME-Version: 1.0 To: Laird Popkin References: <1865369468.307061212422766942.JavaMail.root@dkny.pando.com> In-Reply-To: <1865369468.307061212422766942.JavaMail.root@dkny.pando.com> X-Enigmail-Version: 0.95.0 X-OriginalArrivalTime: 02 Jun 2008 22:15:37.0120 (UTC) FILETIME=[2F1C9A00:01C8C4FE] Cc: "ramit@pando.com" , "p2pi@ietf.org" , "p4pwg@yahoogroups.com" Subject: Re: [p2pi] Thoughts on how IETF standards can help P2P/ISPs X-BeenThere: p2pi@ietf.org X-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="===============0740901616==" Sender: p2pi-bounces@ietf.org Errors-To: p2pi-bounces@ietf.org --===============0740901616== Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms010807090200010002020407" --------------ms010807090200010002020407 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Laird Popkin wrote: > As we discussed last week at the IETF P2Pi Workshop, here are a list of > some of the ways that IETF standards can potentially help P2P > applications make better network decisions, and thus help ISPs. This > isn't a complete list, but I hope that it's at least a useful starting > point for a discussion. It seems to me that this turned out to be a two-sided problem. On the one hand, it is clear that applications on the endpoints are in the worst position to make optimal network decisions; a first part of the solution should thus consist of a mechanism to defer such decisions to external entities (not necessarily controlled by ISPs, as e.g. in the case of Ono, where the redirection service is provided by Akamai servers). The need for such a mechanism was claimed by several papers [4,26,28,29] and, AFAIR, received little objection (the one that I recall was the "hot potato" thing, where the external entity providing the peer selection service would be able to place sort of DDOS attacks against specific targets/networks). On the other hand, how to compute best paths is a separate part of the problem; topology/cost/congestion notification, cache identification, usage metrics, and the like all fall in this category and, at this time, are probably more research topics than engineering issues. Right now, I think the IETF should focus on the first part of the problem, the front-end of a generic third-party peer selection service p2p applications can query in order to make better choices; innovation and competition will then happen on the back-end of such a service without requiring standardization in the first place. [*] References at http://www.ietf.org/mail-archive/web/p2pi/current/msg00005.html -- Ciao, Enrico --------------ms010807090200010002020407 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 hkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wODA2MDIyMjE1MTNaMCMG CSqGSIb3DQEJBDEWBBTBWWDWFVo5BhKQKNqaOJaGwIqBjzBfBgkqhkiG9w0BCQ8xUjBQMAsG CWCGSAFlAwQBAjAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAw BwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgYUGCSsGAQQBgjcQBDF4MHYwYjELMAkGA1UEBhMC WkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1Ro YXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAhAeTAANDUMJU97n0e1AWxu4MIGH BgsqhkiG9w0BCRACCzF4oHYwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25z dWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJ c3N1aW5nIENBAhAeTAANDUMJU97n0e1AWxu4MA0GCSqGSIb3DQEBAQUABIIBAK1vP6ZVs2Tu cIfWXz1pzWOw+uKHMN3xrRGYmMnxWFtVccQUvCLitPc3H5UYxp1hzcGrEijR3tO9+jdlDfyn Ume+H83RFvargY8GsalLBS6WOHUBxhUyyq2TCn8Qo+XLBp809hu+uKkr7S1VW1F5nq+WP7pR 1kNdnLEX6SESDQMYTukgjf5EqYQxf7AHkRWg6jEuYM2K6VfxcZFIzdUiFakp9SRUJKxMuQ+j gm8jjwHFcA5wUiF4AJpAuBWJivi2CELclkrWrW+3dPdX9zfjYv36kioorF8pdq6k/k98RVgZ kWPEsoGQrdtXm8/esfAHISPbWkp0843Mdgq/+hpT/PsAAAAAAAA= --------------ms010807090200010002020407-- --===============0740901616== 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 --===============0740901616==-- From p2pi-bounces@ietf.org Mon Jun 2 16: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 863A328C202; Mon, 2 Jun 2008 16: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 AA26828C1FC for ; Mon, 2 Jun 2008 16:09:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.249 X-Spam-Level: X-Spam-Status: No, score=-102.249 tagged_above=-999 required=5 tests=[AWL=-0.250, BAYES_00=-2.599, J_CHICKENPOX_25=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dNfvT6fhTPKU for ; Mon, 2 Jun 2008 16:09:01 -0700 (PDT) Received: from wolverine02.qualcomm.com (wolverine02.qualcomm.com [199.106.114.251]) by core3.amsl.com (Postfix) with ESMTP id C5E8228C210 for ; Mon, 2 Jun 2008 16:06:05 -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=1212447968; x=1243983968; 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<484470F1.7000105@teleco mitalia.it>|References:=20<1865369468.307061212422766942. JavaMail.root@dkny.pando.com>=0D=0A=20<484470F1.7000105@t elecomitalia.it>|Date:=20Mon,=202=20Jun=202008=2016:06:03 =20-0700|To:=20Enrico=20Marocco=20,=0D=0A=20=20=20=20=20=20=20=20Laird=20Popkin =0D=0A=09|From:=20Ted=20Hardie=20|Subject:=20Re:=20[p2pi]=20Thoughts=20on=20 how=20IETF=20standards=20can=20help=20P2P/ISPs|CC:=20"ram it@pando.com"=20,=20"p2pi@ietf.org"=20

,=0D=0A=20=20=20=20=20=20=20=20"p4pwg@yahoog roups.com"=20|Content-Type:=20text /plain=3B=20charset=3D"us-ascii"|X-IronPort-AV:=20E=3DMcA fee=3Bi=3D"5200,2160,5308"=3B=20a=3D"3449316"; bh=d/q84JicNtRvNsHtVouyymM8UHnb7l1iJGwRuF2xiJA=; b=OrhFTvouiCzy5lVzUMaupmYqb8eDuoGNIBRaENasAcBO61yH2eZnuOyv h/BWlVJaxvKcjsAXexH+wThv+59nqHlag0HmmuGJXxvBCDIv72HPBAC+R qCxM89Ar0zM5/EAKAJ0Mbrc+pLA56Jf3TQn/roCSVg01O/DGVl+viP8l4 A=; X-IronPort-AV: E=McAfee;i="5200,2160,5308"; a="3449316" 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; 02 Jun 2008 16:06:07 -0700 Received: from totoro.qualcomm.com (totoro.qualcomm.com [129.46.61.158]) by numenor.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id m52N67jI024286 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 2 Jun 2008 16:06:07 -0700 Received: from nasanexhc03.na.qualcomm.com (nasanexhc03.na.qualcomm.com [172.30.33.34]) by totoro.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id m52N660t025472 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Mon, 2 Jun 2008 16:06:06 -0700 (PDT) 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; Mon, 2 Jun 2008 16:06:05 -0700 MIME-Version: 1.0 Message-ID: In-Reply-To: <484470F1.7000105@telecomitalia.it> References: <1865369468.307061212422766942.JavaMail.root@dkny.pando.com> <484470F1.7000105@telecomitalia.it> Date: Mon, 2 Jun 2008 16:06:03 -0700 To: Enrico Marocco , Laird Popkin From: Ted Hardie Cc: "ramit@pando.com" , "p2pi@ietf.org" , "p4pwg@yahoogroups.com" Subject: Re: [p2pi] Thoughts on how IETF standards can help P2P/ISPs X-BeenThere: p2pi@ietf.org X-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:15 PM -0700 6/2/08, Enrico Marocco wrote: >It seems to me that this turned out to be a two-sided problem. On the >one hand, it is clear that applications on the endpoints are in the >worst position to make optimal network decisions; a first part of the >solution should thus consist of a mechanism to defer such decisions to >external entities Of course you can recast this as "So we should make sure that there are mechanisms that allow them to make more optimal decisions. The facilities which provide this information need not be controlled by the ISPs, but might be third party services which indicate cost/topology/congestion or some profile mix of the three." To my way of thinking, that makes it easier to consider the API design, as it is not so much an API that says "What's the best choice right now?" but "What's the best X (flow pattern, topology, price)". The second set of questions is sufficiently more modular that it is both easier to get right and, at least in my opinion, more interesting. Just my two cents, Ted >(not necessarily controlled by ISPs, as e.g. in the >case of Ono, where the redirection service is provided by Akamai >servers). The need for such a mechanism was claimed by several papers >[4,26,28,29] and, AFAIR, received little objection (the one that I >recall was the "hot potato" thing, where the external entity providing >the peer selection service would be able to place sort of DDOS attacks >against specific targets/networks). > >On the other hand, how to compute best paths is a separate part of the >problem; topology/cost/congestion notification, cache identification, >usage metrics, and the like all fall in this category and, at this time, >are probably more research topics than engineering issues. > >Right now, I think the IETF should focus on the first part of the >problem, the front-end of a generic third-party peer selection service >p2p applications can query in order to make better choices; innovation >and competition will then happen on the back-end of such a service >without requiring standardization in the first place. > >[*] References at >http://www.ietf.org/mail-archive/web/p2pi/current/msg00005.html > >-- >Ciao, >Enrico > >Content-Type: application/x-pkcs7-signature; name="smime.p7s" >Content-Description: S/MIME Cryptographic Signature.p7s >Content-Disposition: attachment; filename="smime.p7s"; size=3504; > creation-date="Mon, 02 Jun 2008 15:26:25 GMT"; > modification-date="Mon, 02 Jun 2008 15:26:25 GMT" > >Attachment converted: Macintosh HD:smime 1480.p7s ( / ) (007B339F) >Content-Type: text/plain; name="ATT00001.txt" >Content-Description: ATT00001.txt >Content-Disposition: attachment; filename="ATT00001.txt"; size=191; > creation-date="Mon, 02 Jun 2008 15:26:25 GMT"; > modification-date="Mon, 02 Jun 2008 15:26:25 GMT" > >Attachment converted: Macintosh HD:ATT00001 1846.txt (TEXT/ttxt) (007B33A0) _______________________________________________ p2pi mailing list p2pi@ietf.org https://www.ietf.org/mailman/listinfo/p2pi From p2pi-bounces@ietf.org Mon Jun 2 23:22: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 6D8383A6B81; Mon, 2 Jun 2008 23:22: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 E31063A6B9D for ; Mon, 2 Jun 2008 23:22:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.495 X-Spam-Level: X-Spam-Status: No, score=-0.495 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4Iwsw0-moP9Y for ; Mon, 2 Jun 2008 23:22:17 -0700 (PDT) Received: from szxga03-in.huawei.com (unknown [61.144.161.55]) by core3.amsl.com (Postfix) with ESMTP id 3F54628C12D for ; Mon, 2 Jun 2008 23:21:38 -0700 (PDT) Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0K1V00AEIIVGTI@szxga03-in.huawei.com> for p2pi@ietf.org; Tue, 03 Jun 2008 14:18:52 +0800 (CST) Received: from huawei.com ([172.24.1.24]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0K1V0036KIVG5Z@szxga03-in.huawei.com> for p2pi@ietf.org; Tue, 03 Jun 2008 14:18:52 +0800 (CST) Received: from s64081 ([10.164.9.76]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0K1V00I26IVF1T@szxml04-in.huawei.com> for p2pi@ietf.org; Tue, 03 Jun 2008 14:18:52 +0800 (CST) Date: Tue, 03 Jun 2008 14:18:51 +0800 From: Song Haibin In-reply-to: To: 'Ted Hardie' , 'Enrico Marocco' , 'Laird Popkin' Message-id: <00d301c8c541$b18cf410$4c09a40a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 X-Mailer: Microsoft Office Outlook 11 Thread-index: AcjFBcdXQmFNW/5dRJ+pc/FlIV/b6AAOSdSg Cc: ramit@pando.com, p2pi@ietf.org, p4pwg@yahoogroups.com Subject: Re: [p2pi] Thoughts on how IETF standards can help P2P/ISPs X-BeenThere: p2pi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: P2P Infrastructure Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: p2pi-bounces@ietf.org Errors-To: p2pi-bounces@ietf.org >-----Original Message----- >From: p2pi-bounces@ietf.org [mailto:p2pi-bounces@ietf.org] On Behalf Of Ted >Hardie >Sent: Tuesday, June 03, 2008 7:06 AM >To: Enrico Marocco; Laird Popkin >Cc: ramit@pando.com; p2pi@ietf.org; p4pwg@yahoogroups.com >Subject: Re: [p2pi] Thoughts on how IETF standards can help P2P/ISPs > >At 3:15 PM -0700 6/2/08, Enrico Marocco wrote: >>It seems to me that this turned out to be a two-sided problem. On the >>one hand, it is clear that applications on the endpoints are in the >>worst position to make optimal network decisions; a first part of the >>solution should thus consist of a mechanism to defer such decisions to >>external entities > >Of course you can recast this as "So we should make sure that >there are mechanisms that allow them to make more optimal decisions. >The facilities which provide this information need not be controlled >by the ISPs, but might be third party services which indicate >cost/topology/congestion or some profile mix of the three." > >To my way of thinking, that makes it easier to consider the API >design, as it is not so much an API that says "What's the best >choice right now?" but "What's the best X (flow pattern, topology, >price)". The second set of questions is sufficiently more modular >that it is both easier to get right and, at least in my opinion, >more interesting. >Just my two cents, >Ted I think it depends on whether the P2P application or the party that provides peer selection information service makes the final choice. IMO, the peer selection information service should provide information to help the p2p application to determine best paths or peers, but not itself makes the final choice. -Song Haibin _______________________________________________ p2pi mailing list p2pi@ietf.org https://www.ietf.org/mailman/listinfo/p2pi From p2pi-bounces@ietf.org Mon Jun 2 23:31:51 2008 Return-Path: X-Original-To: p2pi-archive@ietf.org Delivered-To: ietfarch-p2pi-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A84EC3A695E; Mon, 2 Jun 2008 23:31:51 -0700 (PDT) X-Original-To: p2pi@core3.amsl.com Delivered-To: p2pi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EF5AD3A6B81 for ; Mon, 2 Jun 2008 23:31:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0rXn6jtTe0+w for ; Mon, 2 Jun 2008 23:31:49 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by core3.amsl.com (Postfix) with ESMTP id 008D628C166 for ; Mon, 2 Jun 2008 23:31:21 -0700 (PDT) Received: from [127.0.0.1] (pool-71-106-109-69.lsanca.dsl-w.verizon.net [71.106.109.69]) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id m536Uslu029020 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 2 Jun 2008 23:30:56 -0700 (PDT) Message-ID: <4844E51D.9080705@isi.edu> Date: Mon, 02 Jun 2008 23:30:53 -0700 From: Joe Touch User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: Song Haibin References: <00d301c8c541$b18cf410$4c09a40a@china.huawei.com> In-Reply-To: <00d301c8c541$b18cf410$4c09a40a@china.huawei.com> X-Enigmail-Version: 0.95.6 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: p4pwg@yahoogroups.com, ramit@pando.com, p2pi@ietf.org Subject: Re: [p2pi] Thoughts on how IETF standards can help P2P/ISPs X-BeenThere: p2pi@ietf.org X-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="===============1525707600==" Sender: p2pi-bounces@ietf.org Errors-To: p2pi-bounces@ietf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============1525707600== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig2709742E7FBE628076594BCE" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig2709742E7FBE628076594BCE Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Song Haibin wrote: >> -----Original Message----- >> From: p2pi-bounces@ietf.org [mailto:p2pi-bounces@ietf.org] On Behalf O= f Ted >> Hardie =2E.. >> To my way of thinking, that makes it easier to consider the API >> design, as it is not so much an API that says "What's the best >> choice right now?" but "What's the best X (flow pattern, topology, >> price)". The second set of questions is sufficiently more modular >> that it is both easier to get right and, at least in my opinion, >> more interesting. >> Just my two cents, >> Ted >=20 > I think it depends on whether the P2P application or the party that pro= vides > peer selection information service makes the final choice. IMO, the pee= r > selection information service should provide information to help the p2= p > application to determine best paths or peers, but not itself makes the = final > choice. FWIW, there is a lot of work in peer selection in web cache hierarchies=20 that may be applicable here. Keith Moore's work (SONAR) comes to mind,=20 but there are others. Come to think of it, there are a lot of analogies between P2P - and P4P=20 - and web cache hierarchies. Has this been explored?? Joe --------------enig2709742E7FBE628076594BCE Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFIROUdE5f5cImnZrsRAvqPAJ0ULv6Nn0z1mV1z5BLnxrUm2+0/TQCgnKNa CTWWYR08m3N7ec11aYIsTLw= =/RK7 -----END PGP SIGNATURE----- --------------enig2709742E7FBE628076594BCE-- --===============1525707600== 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 --===============1525707600==-- From p2pi-bounces@ietf.org Tue Jun 3 01:38:33 2008 Return-Path: X-Original-To: p2pi-archive@ietf.org Delivered-To: ietfarch-p2pi-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F3BB13A6BEC; Tue, 3 Jun 2008 01:38:32 -0700 (PDT) X-Original-To: p2pi@core3.amsl.com Delivered-To: p2pi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E4CD23A6BEC for ; Tue, 3 Jun 2008 01:38:31 -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 jCyx9SQ24VEh for ; Tue, 3 Jun 2008 01:38:30 -0700 (PDT) Received: from mailm.telecomitalia.it (mailm.telecomitalia.it [217.169.121.53]) by core3.amsl.com (Postfix) with ESMTP id 517FE3A6B76 for ; Tue, 3 Jun 2008 01:38:30 -0700 (PDT) Received: from ptpxch009rm001.idc.cww.telecomitalia.it ([156.54.205.171]) by mailm.telecomitalia.it with Microsoft SMTPSVC(6.0.3790.1830); Tue, 3 Jun 2008 10:38:30 +0200 Received: from grfhub701rm001.griffon.local ([10.19.3.8]) by ptpxch009rm001.idc.cww.telecomitalia.it with Microsoft SMTPSVC(6.0.3790.1830); Tue, 3 Jun 2008 10:38:30 +0200 Received: from [10.229.8.44] (10.229.8.44) by smtp.telecomitalia.it (10.19.3.40) with Microsoft SMTP Server (TLS) id 8.1.263.0; Tue, 3 Jun 2008 10:38:30 +0200 Message-ID: <484502EF.5030609@telecomitalia.it> Date: Tue, 3 Jun 2008 10:38:07 +0200 From: Enrico Marocco User-Agent: Mozilla-Thunderbird 2.0.0.14 (X11/20080509) MIME-Version: 1.0 To: Ted Hardie References: <1865369468.307061212422766942.JavaMail.root@dkny.pando.com> <484470F1.7000105@telecomitalia.it> In-Reply-To: X-Enigmail-Version: 0.95.0 X-OriginalArrivalTime: 03 Jun 2008 08:38:30.0355 (UTC) FILETIME=[334BB230:01C8C555] Cc: "ramit@pando.com" , "p2pi@ietf.org" , "p4pwg@yahoogroups.com" Subject: Re: [p2pi] Thoughts on how IETF standards can help P2P/ISPs X-BeenThere: p2pi@ietf.org X-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="===============1721104671==" Sender: p2pi-bounces@ietf.org Errors-To: p2pi-bounces@ietf.org --===============1721104671== Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms050502080100050203050409" --------------ms050502080100050203050409 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Ted Hardie wrote: > At 3:15 PM -0700 6/2/08, Enrico Marocco wrote: >> It seems to me that this turned out to be a two-sided problem. On the >> one hand, it is clear that applications on the endpoints are in the >> worst position to make optimal network decisions; a first part of the >> solution should thus consist of a mechanism to defer such decisions to >> external entities > > Of course you can recast this as "So we should make sure that > there are mechanisms that allow them to make more optimal decisions. > The facilities which provide this information need not be controlled > by the ISPs, but might be third party services which indicate > cost/topology/congestion or some profile mix of the three." Existing systems today used (or proposed) for optimizing peer selection use different methods to make their choices. While it would be easy to define a common interface such systems could expose to p2p applications, it would be probably hard to standardize cost/topology/congestion/policy notification mechanisms in order to accommodate all different approaches adopted by existing and foreseeable solutions. Examples of existing systems are Vivaldi and Ono, embedded in 10^5~10^6 Azureus clients out there, P4P, iPlane, PIC and many others, simulated and emulated in friendly environments. > To my way of thinking, that makes it easier to consider the API > design, as it is not so much an API that says "What's the best > choice right now?" but "What's the best X (flow pattern, topology, > price)". The second set of questions is sufficiently more modular > that it is both easier to get right and, at least in my opinion, > more interesting. Well, I'd probably prefer a compromise between the two, something like "What's the best choice for downloading X Mb of delay-sensitive data?". And, just to be clear, available options must be provided by the application which, at the end of the day, will be also in charge of making the final decision (including ignoring the answer if for some reason it doesn't like it). -- Ciao, Enrico --------------ms050502080100050203050409 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 hkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wODA2MDMwODM4MDdaMCMG CSqGSIb3DQEJBDEWBBRgUKcjo7a+gcNOFcdrdYlZTXyFJjBfBgkqhkiG9w0BCQ8xUjBQMAsG CWCGSAFlAwQBAjAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAw BwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgYUGCSsGAQQBgjcQBDF4MHYwYjELMAkGA1UEBhMC WkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1Ro YXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAhAeTAANDUMJU97n0e1AWxu4MIGH BgsqhkiG9w0BCRACCzF4oHYwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25z dWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJ c3N1aW5nIENBAhAeTAANDUMJU97n0e1AWxu4MA0GCSqGSIb3DQEBAQUABIIBAG3pv0Tu4kFy NchMmxNin3u/C2i5p8PE48EJq0ox05t3qtI9ZMkzSjjYCR6JlQdR/0Jsz4er4JjDhwOPTAyv 8jcU37I+nSUcjxOsmJfESzN35PoLtgaj951A73BUzUkxXqWQZ2w/UZU0E879VFX+7hxh6kGs kLzvFb+VVfnkNiZUl96uz3No69kCOD6GeLh/vWVL1odLJVA4HOMlLx3V0x2xXBDY5aTQid5p z5zlo5DRHl4QlYP3HxH3rS7h9D8GmKXbMyVihML3/05rIg4/7Vfwt/EaU5xSms+9zJypMhki 8gELlHKIQKRbkEoK4HmDGXFoyJuiDk/V5vKWYLeqnogAAAAAAAA= --------------ms050502080100050203050409-- --===============1721104671== 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 --===============1721104671==-- From p2pi-bounces@ietf.org Tue Jun 3 11:22: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 030323A6A60; Tue, 3 Jun 2008 11:22: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 4EC8E3A6875 for ; Tue, 3 Jun 2008 11:22:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.492 X-Spam-Level: X-Spam-Status: No, score=-106.492 tagged_above=-999 required=5 tests=[AWL=0.107, 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 INzDlihL4FIj for ; Tue, 3 Jun 2008 11:22:45 -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 0E5233A6BC6 for ; Tue, 3 Jun 2008 11:20:51 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.27,585,1204531200"; d="scan'208";a="75369843" Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-3.cisco.com with ESMTP; 03 Jun 2008 11:20:54 -0700 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id m53IKsJF009588 for ; Tue, 3 Jun 2008 11:20:54 -0700 Received: from [192.168.4.177] (sjc-fluffy-vpn1.cisco.com [10.25.236.82]) by sj-core-5.cisco.com (8.13.8/8.13.8) with SMTP id m53IKsnt024466 for ; Tue, 3 Jun 2008 18:20:54 GMT Message-Id: <10042FFE-A59A-48D5-A74D-1353154C95DB@cisco.com> From: Cullen Jennings To: p2pi@ietf.org Impp: xmpp:cullenfluffyjennings@jabber.org Mime-Version: 1.0 (Apple Message framework v919.2) Date: Tue, 3 Jun 2008 11:20:43 -0700 X-Mailer: Apple Mail (2.919.2) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=262; t=1212517254; x=1213381254; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fluffy@cisco.com; z=From:=20Cullen=20Jennings=20 |Subject:=20Slide=20update |Sender:=20; bh=3yedPOit90VUMs8cvccZqF35NgQ9eUlCc6uxRYw3w/0=; b=W+0DpdU/ztzfVz+cHBOUSqvm99UDVnwV/e3GiMNu/47+lGafSa+4QWhL2k DVEWlt6vroQsQGMJ5y/NYd/yE290sCNs+ooy1mAN99nN8GiEH9zIZkxSsFRm XA7my+2rHLxKs03WnL3NV5i8TBoZtPinAKHWQv0dBMzgh8qXRFMFM=; Authentication-Results: sj-dkim-1; header.From=fluffy@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); Subject: [p2pi] Slide update X-BeenThere: p2pi@ietf.org X-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 just put a new ZIP file with the slides up at http://idisk.mac.com/cullenfluffyjennings-Public?view=web This has some updated slide decks to match what got presented and added the set of "Next Steps" slides Jon and I presented at the end of the day. _______________________________________________ p2pi mailing list p2pi@ietf.org https://www.ietf.org/mailman/listinfo/p2pi From p2pi-bounces@ietf.org Tue Jun 3 22:37:20 2008 Return-Path: X-Original-To: p2pi-archive@ietf.org Delivered-To: ietfarch-p2pi-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E5B543A68FC; Tue, 3 Jun 2008 22:37:20 -0700 (PDT) X-Original-To: p2pi@core3.amsl.com Delivered-To: p2pi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1788D3A68FC for ; Tue, 3 Jun 2008 22:37:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x654hOPL5BSa for ; Tue, 3 Jun 2008 22:37:19 -0700 (PDT) Received: from wa-out-1112.google.com (wa-out-1112.google.com [209.85.146.177]) by core3.amsl.com (Postfix) with ESMTP id 5C34F3A6839 for ; Tue, 3 Jun 2008 22:37:16 -0700 (PDT) Received: by wa-out-1112.google.com with SMTP id k34so1196389wah.25 for ; Tue, 03 Jun 2008 22:37:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; bh=yzbktuPM6c6TnUJmju90+YJLONAo1MV5vUk8XYNmsDU=; b=N8nj9JfKh2tRSS38JfljPAd7NwK/Wj4VqV9mogmxuqeF7rNL3znACnEOrhmcMOq/YE1qoEpoTUsRnjHbgk4cp0sjPrHywbIRqrUaw/p8KpzEjp2S/KUwH0cyOOEZ18re/lEywqMwmuv7wwaivAMvGWZLWUDlI4a2CKL1J6xfn9E= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; b=KcKheurFNjr+vvmpmq8ibvRByvtUYs3h4NcL+i1yIGBJdlKPCojBEppDdez27ZT2dvSIz4GZIaFgbO+GN40dG7Zkt3A7+h5sk8flhGscQsY1PgPwgn/DkspA1+Xu8+IDHETQwUb8QazYzWazWd8XUVPQysTdH9TGGcznbH+y5uo= Received: by 10.115.19.16 with SMTP id w16mr1720385wai.102.1212557840081; Tue, 03 Jun 2008 22:37:20 -0700 (PDT) Received: by 10.114.47.9 with HTTP; Tue, 3 Jun 2008 22:37:20 -0700 (PDT) Message-ID: <1d38a3350806032237g1d22cdafpc7c0b314e562b5a@mail.gmail.com> Date: Wed, 4 Jun 2008 13:37:20 +0800 From: "Hui Deng" To: p2pi@ietf.org MIME-Version: 1.0 Content-Disposition: inline Subject: [p2pi] Question from mobile operator about 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 Hello all I have not yet read all documents, but basic inpression from ML is that cable operator still have problem during last mile with shared medium. May I ask that for mobile communication like LTE, each subscriber will have point to point link with base station (eNode B), and GTP tunneling will be used between eNode B and PDN GW. So in this case, for mobile communication, P2P _______________________________________________ p2pi mailing list p2pi@ietf.org https://www.ietf.org/mailman/listinfo/p2pi From p2pi-bounces@ietf.org Tue Jun 3 22:39: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 43B423A6832; Tue, 3 Jun 2008 22:39: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 64C473A699E for ; Tue, 3 Jun 2008 22:39:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 10Jjtkktjydt for ; Tue, 3 Jun 2008 22:39:46 -0700 (PDT) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.236]) by core3.amsl.com (Postfix) with ESMTP id D3C593A6AB3 for ; Tue, 3 Jun 2008 22:39:12 -0700 (PDT) Received: by rv-out-0506.google.com with SMTP id b25so1662463rvf.49 for ; Tue, 03 Jun 2008 22:39:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=dUMad3nBBEfFhwfihw3Cynnn18limV0pIcFS147uzME=; b=CkGClqNlH8mw0Ksn8Sfqf3FEazOgPRccmZ6iifz9tRynSVSTMerfg+GWhxclUvi+rOSCZwXP/KTMNhlgREJ4Rjgu9faeDHNy0/wYBitQslMfple6voMrZX++LqI8EvEZtBO8Q0YlyM5ms1VH7N9pvYUp5SdZENYmsive29rFsw0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=EEOb/ih8jvqmP3+94R55hPrbbmkFb5aHeebQ/DlKmfuirFMUgLKx7C4/7QQaQOGkn+eItRZ0XcLlD2si+Tur5wWyplhHh3Ft11KofW0I6FV9X6R9XGLl8E+w1wM0Q2zFo5rqjZ8iUZ8Kzpz28eFg/yKbCcou0PM52ANxabPqssE= Received: by 10.114.183.20 with SMTP id g20mr6721826waf.77.1212557956108; Tue, 03 Jun 2008 22:39:16 -0700 (PDT) Received: by 10.114.47.9 with HTTP; Tue, 3 Jun 2008 22:39:15 -0700 (PDT) Message-ID: <1d38a3350806032239v2819230cq4f497f05768e736e@mail.gmail.com> Date: Wed, 4 Jun 2008 13:39:15 +0800 From: "Hui Deng" To: p2pi@ietf.org In-Reply-To: <1d38a3350806032237g1d22cdafpc7c0b314e562b5a@mail.gmail.com> MIME-Version: 1.0 Content-Disposition: inline References: <1d38a3350806032237g1d22cdafpc7c0b314e562b5a@mail.gmail.com> Subject: [p2pi] Question from mobile operator about 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 sorry for mis-typing and post, gmail has operation issue. 2008/6/4 Hui Deng : > Hello all > > I have not yet read all documents, but basic inpression from ML is that > cable operator still have problem during last mile with shared medium. > > May I ask that for mobile communication like LTE, each subscriber > will have point to point link with base station (eNode B), and GTP tunneling > will be used between eNode B and PDN GW. So in this case, for mobile > communication, P2P will not share this problem? > I am wondering whether this understanding is correct or not? > > Thanks for your comments. > Best regards, -> Hui _______________________________________________ p2pi mailing list p2pi@ietf.org https://www.ietf.org/mailman/listinfo/p2pi From p2pi-bounces@ietf.org Wed Jun 4 01:12:27 2008 Return-Path: X-Original-To: p2pi-archive@ietf.org Delivered-To: ietfarch-p2pi-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0744328C0D0; Wed, 4 Jun 2008 01:12:27 -0700 (PDT) X-Original-To: p2pi@core3.amsl.com Delivered-To: p2pi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 348F13A6923 for ; Wed, 4 Jun 2008 01:12:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.09 X-Spam-Level: X-Spam-Status: No, score=-0.09 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lBneiJUKcraA for ; Wed, 4 Jun 2008 01:12:25 -0700 (PDT) Received: from ns1.nict.go.jp (ns1.nict.go.jp [133.243.3.1]) by core3.amsl.com (Postfix) with ESMTP id E7D0A3A6AA1 for ; Wed, 4 Jun 2008 01:12:24 -0700 (PDT) Received: from gw2.nict.go.jp (gw2.nict.go.jp [133.243.18.251]) by ns1.nict.go.jp with ESMTP id m5488WGF027515; Wed, 4 Jun 2008 17:08:32 +0900 (JST) Received: from gw2.nict.go.jp (localhost [127.0.0.1]) by gw2.nict.go.jp with ESMTP id m5488WRL027317; Wed, 4 Jun 2008 17:08:32 +0900 (JST) Received: from mail2.nict.go.jp (mail.nict.go.jp [133.243.18.3]) by gw2.nict.go.jp with ESMTP id m5488Wm2027314; Wed, 4 Jun 2008 17:08:32 +0900 (JST) Received: from mail2.nict.go.jp (localhost [127.0.0.1]) by localhost.nict.go.jp (Postfix) with ESMTP id 5E4DE6E5C; Wed, 4 Jun 2008 17:08:32 +0900 (JST) Received: from [127.0.0.1] (ssh.nict.go.jp [133.243.3.49]) by mail2.nict.go.jp (Postfix) with ESMTP id F39DB6E49; Wed, 4 Jun 2008 17:08:31 +0900 (JST) User-Agent: Microsoft-Entourage/12.10.0.080409 Date: Wed, 04 Jun 2008 17:08:31 +0900 From: Kurt Tutschku To: Hui Deng , Message-ID: Thread-Topic: [p2pi] Question from mobile operator about P2PI Thread-Index: AcjGGi019A6qE7ReSEiyeCYn46kUbA== In-Reply-To: <1d38a3350806032239v2819230cq4f497f05768e736e@mail.gmail.com> Mime-version: 1.0 Subject: Re: [p2pi] Question from mobile operator about 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 Dear Hui Deng, dear all, there is still a problem generated by the access. An uploading low capacity mobile peer can delay significantly the download when multi-source download is used. You find details in our work available at: http://www3.informatik.uni-wuerzburg.de/research/projects/siemens-mopi/ http://www3.informatik.uni-wuerzburg.de/publications/publications.php If anyone needs an access key to the papers, please drop a private message. I'm not allowed to post it here. Cheers Kurt On 04.06.08 14:39, "Hui Deng" wrote: > sorry for mis-typing and post, gmail has operation issue. > > 2008/6/4 Hui Deng : >> Hello all >> >> I have not yet read all documents, but basic inpression from ML is that >> cable operator still have problem during last mile with shared medium. >> >> May I ask that for mobile communication like LTE, each subscriber >> will have point to point link with base station (eNode B), and GTP tunneling >> will be used between eNode B and PDN GW. So in this case, for mobile >> communication, P2P will not share this problem? >> I am wondering whether this understanding is correct or not? >> >> Thanks for your comments. >> Best regards, > > -> Hui > _______________________________________________ > p2pi mailing list > p2pi@ietf.org > https://www.ietf.org/mailman/listinfo/p2pi -- Dr. Kurt Tutschku, Expert Researcher NICT (National Institute of Information and Communication Technology) Network Architecture Group, Network Research Center Park Court Place, 4th Floor 1-33-16, Hakusan, Bunkyo-ku, Tokyo 113-0001 Japan Tel.: +81-3-3868-6916 FAX.: +81-3-3868-6921 mailto:tutschku@nict.go.jp or mailto:kurt.tutschku@gmail.com http://www.nict.go.jp/index.html _______________________________________________ p2pi mailing list p2pi@ietf.org https://www.ietf.org/mailman/listinfo/p2pi From p2pi-bounces@ietf.org Wed Jun 4 09:40: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 6C34D3A6CC2; Wed, 4 Jun 2008 09:40: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 1A32B3A6B31 for ; Wed, 4 Jun 2008 09:40:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.855 X-Spam-Level: X-Spam-Status: No, score=-1.855 tagged_above=-999 required=5 tests=[AWL=0.745, 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 VAbUBJEUch5Z for ; Wed, 4 Jun 2008 09:40:19 -0700 (PDT) Received: from ihemail2.lucent.com (ihemail2.lucent.com [135.245.0.35]) by core3.amsl.com (Postfix) with ESMTP id 871A528C17F for ; Wed, 4 Jun 2008 09:39:27 -0700 (PDT) Received: from umail.lucent.com (h135-3-40-61.lucent.com [135.3.40.61]) by ihemail2.lucent.com (8.13.8/IER-o) with ESMTP id m54GdDN8006255 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 4 Jun 2008 11:39:13 -0500 (CDT) Received: from [135.185.244.90] (il0015vkg1.ih.lucent.com [135.185.244.90]) by umail.lucent.com (8.13.8/TPES) with ESMTP id m54Gd985017666; Wed, 4 Jun 2008 11:39:09 -0500 (CDT) Message-ID: <4846C52F.9010405@alcatel-lucent.com> Date: Wed, 04 Jun 2008 11:39:11 -0500 From: "Vijay K. Gurbani" Organization: Bell Labs Security Technology Research Group User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Joe Touch References: <00d301c8c541$b18cf410$4c09a40a@china.huawei.com> <4844E51D.9080705@isi.edu> In-Reply-To: <4844E51D.9080705@isi.edu> X-Scanned-By: MIMEDefang 2.57 on 135.245.2.35 Cc: ramit@pando.com, p2pi@ietf.org, p4pwg@yahoogroups.com Subject: Re: [p2pi] Thoughts on how IETF standards can help P2P/ISPs X-BeenThere: p2pi@ietf.org X-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 Joe Touch wrote: > FWIW, there is a lot of work in peer selection in web cache hierarchies > that may be applicable here. Keith Moore's work (SONAR) comes to mind, > but there are others. > > Come to think of it, there are a lot of analogies between P2P - and P4P > - and web cache hierarchies. Has this been explored?? Not to toot our horn here, but our position paper [1] provided what we think is a good literature review on application layer topology estimation -- from synthetic coordinate systems like Vivaldi, PIC, and GNP to the more recent work on Ono, which uses Akamai CDN servers to fine tune peer selection. By and large, the conclusions we arrived at following the literature review were summarized aptly by Enrico in an earlier email: I think the IETF should focus on the first part of the problem, the front-end of a generic third-party peer selection service p2p applications can query in order to make better choices; innovation and competition will then happen on the back-end of such a service without requiring standardization in the first place. [1] 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 Thanks, - vijay -- Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent 2701 Lucent Lane, Rm. 9F-546, Lisle, Illinois 60532 (USA) Email: vkg@{alcatel-lucent.com,bell-labs.com,acm.org} WWW: http://www.alcatel-lucent.com/bell-labs _______________________________________________ p2pi mailing list p2pi@ietf.org https://www.ietf.org/mailman/listinfo/p2pi From p2pi-bounces@ietf.org Wed Jun 4 19:49: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 9464B3A6B7C; Wed, 4 Jun 2008 19:49: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 AF0223A6909 for ; Wed, 4 Jun 2008 19:49:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.047 X-Spam-Level: X-Spam-Status: No, score=-1.047 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, RDNS_NONE=0.1, STOX_REPLY_TYPE=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 L738FNGQ46QB for ; Wed, 4 Jun 2008 19:49:40 -0700 (PDT) Received: from mx4.bupt.edu.cn (unknown [211.68.71.7]) by core3.amsl.com (Postfix) with ESMTP id 9E9EE3A6B58 for ; Wed, 4 Jun 2008 19:48:07 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by mx4.bupt.edu.cn (Postfix) with SMTP id 5ED6233B36 for ; Thu, 5 Jun 2008 10:03:31 +0800 (CST) Received: from ibmPC (unknown [211.160.21.17]) by mx4.bupt.edu.cn (Postfix) with ESMTP id 8CDBC33B4B; Thu, 5 Jun 2008 10:03:29 +0800 (CST) Message-ID: <646DE9D1F2894FB7A9D490A4F3A68C62@ibmPC> From: "Wei Gengyu" To: "Vijay K. Gurbani" References: <00d301c8c541$b18cf410$4c09a40a@china.huawei.com><4844E51D.9080705@isi.edu> <4846C52F.9010405@alcatel-lucent.com> In-Reply-To: <4846C52F.9010405@alcatel-lucent.com> Date: Thu, 5 Jun 2008 10:49:41 +0800 Organization: BUPT MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Windows Mail 6.0.5840.16384 X-MIMEOLE: Produced By Microsoft MimeOLE V6.0.5840.16384 Cc: p2pi@ietf.org Subject: Re: [p2pi] Thoughts on how IETF standards can help P2P/ISPs X-BeenThere: p2pi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: P2P Infrastructure Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: p2pi-bounces@ietf.org Errors-To: p2pi-bounces@ietf.org Hi, Vijay, I have a question. As your paper is about "Application-Layer Traffic Optimization Problem" and CDN service, does it mean that different appoaches are required for P2P file share, P2P voice, and P2P video applications. Regards, Gengyu School of Computer Science and Technology Beijing University of Posts and Telecommunications ----- Original Message ----- From: "Vijay K. Gurbani" To: "Joe Touch" Cc: ; ; Sent: Thursday, June 05, 2008 12:39 AM Subject: Re: [p2pi] Thoughts on how IETF standards can help P2P/ISPs > Joe Touch wrote: >> FWIW, there is a lot of work in peer selection in web cache hierarchies >> that may be applicable here. Keith Moore's work (SONAR) comes to mind, >> but there are others. >> >> Come to think of it, there are a lot of analogies between P2P - and P4P >> - and web cache hierarchies. Has this been explored?? > > Not to toot our horn here, but our position paper [1] provided > what we think is a good literature review on application layer > topology estimation -- from synthetic coordinate systems like > Vivaldi, PIC, and GNP to the more recent work on Ono, which uses > Akamai CDN servers to fine tune peer selection. > > By and large, the conclusions we arrived at following the > literature review were summarized aptly by Enrico in an earlier > email: > > I think the IETF should focus on the first part of the > problem, the front-end of a generic third-party peer selection > service p2p applications can query in order to make better > choices; innovation and competition will then happen on the > back-end of such a service without requiring standardization > in the first place. > > [1] 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 > > Thanks, > > - vijay > -- > Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent > 2701 Lucent Lane, Rm. 9F-546, Lisle, Illinois 60532 (USA) > Email: vkg@{alcatel-lucent.com,bell-labs.com,acm.org} > WWW: http://www.alcatel-lucent.com/bell-labs > _______________________________________________ > p2pi mailing list > p2pi@ietf.org > https://www.ietf.org/mailman/listinfo/p2pi _______________________________________________ p2pi mailing list p2pi@ietf.org https://www.ietf.org/mailman/listinfo/p2pi From p2pi-bounces@ietf.org Thu Jun 5 00:00: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 5DE463A6BC0; Thu, 5 Jun 2008 00:00: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 C978B3A6BEA for ; Thu, 5 Jun 2008 00:00: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 bk3yYqhYFkO0 for ; Thu, 5 Jun 2008 00:00:38 -0700 (PDT) Received: from maild.telecomitalia.it (maild.telecomitalia.it [156.54.233.30]) by core3.amsl.com (Postfix) with ESMTP id 58B4A3A6B78 for ; Thu, 5 Jun 2008 00:00:35 -0700 (PDT) Received: from ptpxch009ba020.idc.cww.telecomitalia.it ([156.54.240.52]) by maild.telecomitalia.it with Microsoft SMTPSVC(6.0.3790.1830); Thu, 5 Jun 2008 09:00:38 +0200 Received: from grfhub701ba020.griffon.local ([10.188.101.111]) by ptpxch009ba020.idc.cww.telecomitalia.it with Microsoft SMTPSVC(6.0.3790.1830); Thu, 5 Jun 2008 09:00:38 +0200 Received: from [10.229.8.35] (10.229.8.35) by smtp.telecomitalia.it (10.188.101.114) with Microsoft SMTP Server (TLS) id 8.1.263.0; Thu, 5 Jun 2008 09:00:37 +0200 Message-ID: <48478EFE.9010009@telecomitalia.it> Date: Thu, 5 Jun 2008 09:00:14 +0200 From: Enrico Marocco User-Agent: Mozilla-Thunderbird 2.0.0.14 (X11/20080509) MIME-Version: 1.0 To: Wei Gengyu References: <00d301c8c541$b18cf410$4c09a40a@china.huawei.com><4844E51D.9080705@isi.edu> <4846C52F.9010405@alcatel-lucent.com> <646DE9D1F2894FB7A9D490A4F3A68C62@ibmPC> In-Reply-To: <646DE9D1F2894FB7A9D490A4F3A68C62@ibmPC> X-Enigmail-Version: 0.95.0 X-OriginalArrivalTime: 05 Jun 2008 07:00:38.0411 (UTC) FILETIME=[DC2BA5B0:01C8C6D9] Cc: "p2pi@ietf.org" Subject: Re: [p2pi] Thoughts on how IETF standards can help P2P/ISPs X-BeenThere: p2pi@ietf.org X-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="===============1239199667==" Sender: p2pi-bounces@ietf.org Errors-To: p2pi-bounces@ietf.org --===============1239199667== Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms020104000702060900070801" --------------ms020104000702060900070801 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Wei Gengyu wrote: > As your paper is about "Application-Layer Traffic Optimization Problem" and > CDN service, > does it mean that different appoaches are required for P2P file share, P2P > voice, and P2P video applications. Actually our goal was to focus the survey on solutions applicable to file-sharing, because that is the main cause of congestion in our networks. However, the same solution would be also beneficial to other applications; we tried to list some in section 3 of the problem statement (http://tools.ietf.org/id/*-alto-problem-statement), but we certainly have missed many. Needless to say, contributions and suggestions are welcome. -- Ciao, Enrico --------------ms020104000702060900070801 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 hkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wODA2MDUwNzAwMTRaMCMG CSqGSIb3DQEJBDEWBBQ/M6iehqpoZBPe6KCAvfP47Bkt+zBfBgkqhkiG9w0BCQ8xUjBQMAsG CWCGSAFlAwQBAjAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAw BwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgYUGCSsGAQQBgjcQBDF4MHYwYjELMAkGA1UEBhMC WkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1Ro YXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAhAeTAANDUMJU97n0e1AWxu4MIGH BgsqhkiG9w0BCRACCzF4oHYwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25z dWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJ c3N1aW5nIENBAhAeTAANDUMJU97n0e1AWxu4MA0GCSqGSIb3DQEBAQUABIIBAKoyW+rXzsgP shDfjVjhtrAfrS8QCC7dMmqxYwbSEZ/WNcamQhks89NaaRfxoHXnMhFmolTBG9g5eBgtSvcS UWJ0lrrM57mdOm/hv2olUHD6swJIhGmxnA5RWDK0g9yZ1Bh9+YFlVnw2wz0WhnDzXBL8pXyS w2lF7nWYxWlNTxQgeHkzJV4/5zdL0QF2F37+vrAzdoW+9FPyN9uS5ldmFW7MeMNHhlzULlFl zmVzrWMyZ9wUdPW4oQHoXLFeWSI6rdX12tSj9WC8DDVXTMFMNU8gflhnOuMorJcn4px9iAix EDXJAFO4V7gCY04Bci/0qSqAqk9gaAPRPRIJHWqVfn8AAAAAAAA= --------------ms020104000702060900070801-- --===============1239199667== 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 --===============1239199667==-- From p2pi-bounces@ietf.org Thu Jun 5 07:40:05 2008 Return-Path: X-Original-To: p2pi-archive@ietf.org Delivered-To: ietfarch-p2pi-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EA21F3A6D28; Thu, 5 Jun 2008 07:40:05 -0700 (PDT) X-Original-To: p2pi@core3.amsl.com Delivered-To: p2pi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 17EC13A6D26 for ; Thu, 5 Jun 2008 07:40:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6Q2V0PkgBaI8 for ; Thu, 5 Jun 2008 07:40:02 -0700 (PDT) Received: from ti-out-0910.google.com (ti-out-0910.google.com [209.85.142.186]) by core3.amsl.com (Postfix) with ESMTP id F0D803A6867 for ; Thu, 5 Jun 2008 07:40:01 -0700 (PDT) Received: by ti-out-0910.google.com with SMTP id a6so280442tib.25 for ; Thu, 05 Jun 2008 07:40:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=7D18YKkF37B1mH5KdYby+4IWPvbialSM3+ioxay0iWY=; b=KcllyqRGYG4FJHJlECub/xqi1Imwl+5imf5uUKASRARVKHx4O5oqjgqQ82Vy0ErOpm bEnVyuVuh6lICrRZvdVsTl2CRLs9e/dXkvntSsNzq/80GNmST99kIfmkSWS9suZyyukA 8npCNidfr6QkpuG/ElDioUGQnGAHIqMAsCx2Y= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=k0nlH3LAOXAvUuHkFK2X6j7uXumdKOqF+pJULBD0aBldHWG6Hp5FJMvhNeoKtu5uWk JMmKpfQQAIzsTb8OD/Ynpza/OtPAfm2+n2LDLjXzeUBvTmm1GRUF7WqUhiGtsev4dbc4 5Gg8mRJBz1hBvLI6EPMPSGf8EsL3V7swTFaKg= Received: by 10.110.109.19 with SMTP id h19mr405189tic.58.1212676803535; Thu, 05 Jun 2008 07:40:03 -0700 (PDT) Received: by 10.110.53.11 with HTTP; Thu, 5 Jun 2008 07:40:03 -0700 (PDT) Message-ID: <1d38a3350806050740o4db46bccn25970175a90a500b@mail.gmail.com> Date: Thu, 5 Jun 2008 22:40:03 +0800 From: "Hui Deng" To: "Kurt Tutschku" In-Reply-To: MIME-Version: 1.0 Content-Disposition: inline References: <1d38a3350806032239v2819230cq4f497f05768e736e@mail.gmail.com> Cc: p2pi@ietf.org Subject: Re: [p2pi] Question from mobile operator about 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 Dear Kurt, I haven't read those paper, swamped for other things, anyhow try to clarify more, I had a talk with the wireless people, the knowlege what I got is basically that in the mobile communication, uploading and downloading channels have been seperated, Secondly, even for one way, different service may have different scheduling method, and could get committed QoS guarantee, Thanks for the discussion. -Hui 2008/6/4 Kurt Tutschku : > Dear Hui Deng, dear all, > > there is still a problem generated by the access. An uploading low capacity > mobile peer can delay significantly the download when multi-source download > is used. > > You find details in our work available at: > > http://www3.informatik.uni-wuerzburg.de/research/projects/siemens-mopi/ > http://www3.informatik.uni-wuerzburg.de/publications/publications.php > > > If anyone needs an access key to the papers, please drop a private message. > I'm not allowed to post it here. > > Cheers > Kurt > > > > On 04.06.08 14:39, "Hui Deng" wrote: > >> sorry for mis-typing and post, gmail has operation issue. >> >> 2008/6/4 Hui Deng : >>> Hello all >>> >>> I have not yet read all documents, but basic inpression from ML is that >>> cable operator still have problem during last mile with shared medium. >>> >>> May I ask that for mobile communication like LTE, each subscriber >>> will have point to point link with base station (eNode B), and GTP tunneling >>> will be used between eNode B and PDN GW. So in this case, for mobile >>> communication, P2P will not share this problem? >>> I am wondering whether this understanding is correct or not? >>> >>> Thanks for your comments. >>> Best regards, >> >> -> Hui >> _______________________________________________ >> p2pi mailing list >> p2pi@ietf.org >> https://www.ietf.org/mailman/listinfo/p2pi > > -- > Dr. Kurt Tutschku, Expert Researcher > NICT (National Institute of Information and Communication Technology) > Network Architecture Group, Network Research Center > Park Court Place, 4th Floor > 1-33-16, Hakusan, Bunkyo-ku, Tokyo 113-0001 > Japan > > Tel.: +81-3-3868-6916 > FAX.: +81-3-3868-6921 > mailto:tutschku@nict.go.jp or mailto:kurt.tutschku@gmail.com > http://www.nict.go.jp/index.html > > > _______________________________________________ p2pi mailing list p2pi@ietf.org https://www.ietf.org/mailman/listinfo/p2pi From p2pi-bounces@ietf.org Fri Jun 6 06:59:05 2008 Return-Path: X-Original-To: p2pi-archive@ietf.org Delivered-To: ietfarch-p2pi-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B207628C1D2; Fri, 6 Jun 2008 06:59:05 -0700 (PDT) X-Original-To: p2pi@core3.amsl.com Delivered-To: p2pi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A062128C17B; Fri, 6 Jun 2008 06:59:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.156 X-Spam-Level: X-Spam-Status: No, score=-6.156 tagged_above=-999 required=5 tests=[AWL=-0.157, BAYES_00=-2.599, J_CHICKENPOX_23=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xd+9dRI7NlAi; Fri, 6 Jun 2008 06:59:03 -0700 (PDT) Received: from mgw-mx03.nokia.com (smtp.nokia.com [192.100.122.230]) by core3.amsl.com (Postfix) with ESMTP id 123A83A6B1F; Fri, 6 Jun 2008 06:59:02 -0700 (PDT) Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145]) by mgw-mx03.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id m56DvlK1003398; Fri, 6 Jun 2008 16:59:09 +0300 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 6 Jun 2008 16:58:18 +0300 Received: from [195.37.70.145] ([10.241.184.208]) by esebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Fri, 6 Jun 2008 16:58:17 +0300 Message-Id: <22F6A875-B548-4C65-AB68-B88E526CCA33@nokia.com> From: Lars Eggert To: TSV Area Mime-Version: 1.0 (Apple Message framework v924) Date: Fri, 6 Jun 2008 15:58:11 +0200 X-Mailer: Apple Mail (2.924) X-OriginalArrivalTime: 06 Jun 2008 13:58:17.0863 (UTC) FILETIME=[5F2E5170:01C8C7DD] X-Nokia-AV: Clean Cc: p2prg@irtf.org, "iab@iab.org IAB" , p2pi@ietf.org, "IESG \(\(E-mail\)\)" , P2PSIP Mailing List Subject: [p2pi] discussing P2PI-related standardization in Dublin X-BeenThere: p2pi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: TSV Area List-Id: P2P Infrastructure Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: p2pi-bounces@ietf.org Errors-To: p2pi-bounces@ietf.org Hi, the recent workshop on P2P infrastructure (P2PI) has resulted in several suggestions for future IETF work. Two of the suggested work items are related to core TSV topics, and a third has at least strong ties to TSV (but also to other areas). We'd be interested to hear from the community if we should schedule a BOF in Dublin to discuss whether the IETF should take on some or all of these, and if so, whether TSV would be the right place for this work. I'll be CC'ing this email to several lists. Please direct your replies to the TSV area list (tsv-area@ietf.org), so that the discussion happens in one place. The working title for the BOF is "Techniques for Advanced Networking Applications" or TANA. The high-level idea is that the IETF would develop guidelines, recommendations and mechanisms for advanced applications that make intensive use of Internet communication in a way that goes beyond the capabilities offered by the IETF's current standard end-to-end transport protocols. Such network-centric applications include those that transmit delay-sensitive traffic and those that transmit delay-insensitive traffic, both using either peer-to-peer approaches or more traditionally structured communication patterns. The work would focus on broadly applicable techniques that address the needs of large subsets of these class of network-centric applications in a fashion that is independent of any particular application. The following three work items were identified as potential new work for the IETF at the P2PI workshop. The first two would be pretty clearly in scope for the TSV area, whereas the third has some significant inter-area relations: (1) A congestion control algorithm for less-than-best-effort "background" transmissions, i.e., an algorithm that attempts to scavenge otherwise idle bandwidth for its transmissions in a way that minimizes interference with regular best-effort traffic. Among the desired features of such an algorithm are the ability to maintain short standing queues, the capability to quickly yield to regular best-effort traffic that uses standard congestion control, the ability to utilize explicit congestion notification (ECN), active queue management (AQM), and/or end-to-end differentiated services (DiffServ) where available, as well as effective operation in situations where some or all of these mechanisms are not available. In addition to specifying a congestion control algorithm, the work may also include specifications of how the algorithm is used in specific UDP-based protocols. (Application of the algorithm to other transport protocols is expected to occur in the working groups that maintain those protocols.) This work item has relations to IETF WGs that deal with congestion control, such as TCPM, DCCP and TSVWG, as well as the IRTF's congestion control research group (ICCRG). (2) A guidelines document that discusses the tradeoffs surrounding the use of many concurrent transport connections to one peer and/or to different peers. Standard Internet congestion control results in a state where different transport connections end up sharing bottleneck capacity, and when an application uses several transport connections to transfer through a bottleneck, it tends to end up with a larger fraction of the bottleneck's loaded resource than if it would be using fewer connections. Note that although capacity is the most commonly considered bottleneck resource, middlebox state table entries are a second important resource for end system communication. Other resource types may exist, and the guidelines are expected to comprehensively discuss them. (3) A mechanism that lets an application that can transfer data from or to several potential peers (i.e., servers, caches, end systems) select a subset of peers for efficient transmission in a way that is aligned with the dynamic interconnection structure of the network operators that provide connectivity to those peers. Application designers, network equipment vendors and network operators will need to collaborate on this work item to define what kinds of dynamic interconnection information is useful to applications, how to obtain it, and how to provide it to applications, resulting in a generic mechanism that is broadly applicable to many current and future applications. This work item has obvious interactions with the IETF's Application, Routing and Operations areas. In order to make this effort more manageable, it may make sense to work out the requirements for such a solution first, before discussing individual proposals or breaking up the work into pieces for specification in different areas or WGs. Please send your thoughts on these three topics. These three work items aren't necessarily the only ones that the IETF could think about taking on; they merely appeared to be the most concrete ones coming out of the P2PI workshop. We could think about discussing additional work items in Dublin - please write up a short description (similar to the ones above), so we can discuss them. Lars _______________________________________________ p2pi mailing list p2pi@ietf.org https://www.ietf.org/mailman/listinfo/p2pi From p2pi-bounces@ietf.org Fri Jun 6 07:41: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 33ED628C1C7; Fri, 6 Jun 2008 07:41: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 ECD8B28C19D; Fri, 6 Jun 2008 07:41:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.443 X-Spam-Level: X-Spam-Status: No, score=-6.443 tagged_above=-999 required=5 tests=[AWL=0.156, 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 pRWBqO7lT46s; Fri, 6 Jun 2008 07:41:14 -0700 (PDT) Received: from mgw-mx03.nokia.com (smtp.nokia.com [192.100.122.230]) by core3.amsl.com (Postfix) with ESMTP id 7F95728C17A; Fri, 6 Jun 2008 07:41:14 -0700 (PDT) Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145]) by mgw-mx03.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id m56Ef9Xp015794; Fri, 6 Jun 2008 17:41:21 +0300 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 6 Jun 2008 17:40:42 +0300 Received: from [195.37.70.145] ([10.241.184.208]) by esebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Fri, 6 Jun 2008 17:40:41 +0300 From: Lars Eggert To: TSV Area In-Reply-To: <22F6A875-B548-4C65-AB68-B88E526CCA33@nokia.com> References: <22F6A875-B548-4C65-AB68-B88E526CCA33@nokia.com> Message-Id: <6E1603B0-7116-45F9-A510-DC5F9040298B@nokia.com> Mime-Version: 1.0 (Apple Message framework v924) Date: Fri, 6 Jun 2008 16:40:36 +0200 X-Mailer: Apple Mail (2.924) X-OriginalArrivalTime: 06 Jun 2008 14:40:42.0158 (UTC) FILETIME=[4BB2ECE0:01C8C7E3] X-Nokia-AV: Clean Cc: p2prg@irtf.org, "iab@iab.org IAB" , p2pi@ietf.org, "IESG \(\(E-mail\)\)" , P2PSIP Mailing List Subject: Re: [p2pi] discussing P2PI-related standardization in Dublin X-BeenThere: p2pi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: TSV Area List-Id: P2P Infrastructure Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: p2pi-bounces@ietf.org Errors-To: p2pi-bounces@ietf.org Hi, related to the work item below, I've just heard that some folks had already been discussing the submission of a more targeted BOF proposal. Depending on the details of that proposal (which I haven't seen yet), work item (3) might be subsumed by it. On 2008-6-6, at 15:58, Lars Eggert wrote: > (3) A mechanism that lets an application that can > transfer data from or to several potential peers (i.e., > servers, caches, end systems) select a subset of peers > for efficient transmission in a way that is aligned with > the dynamic interconnection structure of the network > operators that provide connectivity to those peers. > Application designers, network equipment vendors and > network operators will need to collaborate on this work > item to define what kinds of dynamic interconnection > information is useful to applications, how to obtain it, > and how to provide it to applications, resulting in a > generic mechanism that is broadly applicable to many > current and future applications. This work item has > obvious interactions with the IETF's Application, Routing > and Operations areas. In order to make this effort more > manageable, it may make sense to work out the > requirements for such a solution first, before discussing > individual proposals or breaking up the work into pieces > for specification in different areas or WGs. Lars _______________________________________________ p2pi mailing list p2pi@ietf.org https://www.ietf.org/mailman/listinfo/p2pi From p2pi-bounces@ietf.org Fri Jun 6 09:36:12 2008 Return-Path: X-Original-To: p2pi-archive@ietf.org Delivered-To: ietfarch-p2pi-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9EBFB3A6B09; Fri, 6 Jun 2008 09:36:12 -0700 (PDT) X-Original-To: p2pi@core3.amsl.com Delivered-To: p2pi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EC9DF3A6B09; Fri, 6 Jun 2008 09:36:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.227 X-Spam-Level: X-Spam-Status: No, score=-2.227 tagged_above=-999 required=5 tests=[AWL=0.372, 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 HnkK2gV41qOn; Fri, 6 Jun 2008 09:36:10 -0700 (PDT) Received: from ihemail3.lucent.com (ihemail3.lucent.com [135.245.0.37]) by core3.amsl.com (Postfix) with ESMTP id B5DB53A6AB9; Fri, 6 Jun 2008 09:36:10 -0700 (PDT) Received: from umail.lucent.com (h135-3-40-61.lucent.com [135.3.40.61]) by ihemail3.lucent.com (8.13.8/IER-o) with ESMTP id m56GaHTN016425 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 6 Jun 2008 11:36:17 -0500 (CDT) Received: from [135.185.244.90] (il0015vkg1.ih.lucent.com [135.185.244.90]) by umail.lucent.com (8.13.8/TPES) with ESMTP id m56GaEJm019296; Fri, 6 Jun 2008 11:36:14 -0500 (CDT) Message-ID: <48496781.1030208@alcatel-lucent.com> Date: Fri, 06 Jun 2008 11:36:17 -0500 From: "Vijay K. Gurbani" Organization: Bell Labs Security Technology Research Group User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: TSV Area References: <22F6A875-B548-4C65-AB68-B88E526CCA33@nokia.com> In-Reply-To: <22F6A875-B548-4C65-AB68-B88E526CCA33@nokia.com> X-Scanned-By: MIMEDefang 2.57 on 135.245.2.37 Cc: p2pi@ietf.org, "iab@iab.org IAB" , p2prg@irtf.org, "IESG \(\(E-mail\)\)" , P2PSIP Mailing List Subject: Re: [p2pi] discussing P2PI-related standardization in Dublin X-BeenThere: p2pi@ietf.org X-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 Lars Eggert wrote: > The following three work items were identified as potential > new work for the IETF at the P2PI workshop. The first two > would be pretty clearly in scope for the TSV area, whereas > the third has some significant inter-area relations: > > (1) A congestion control algorithm for > less-than-best-effort "background" transmissions, i.e., > an algorithm that attempts to scavenge otherwise idle [...] I ran across the following references today that I thought may be pertinent to congestion control in DHT algorithms. I do not think they operate on the scavenger principle, nor do I remember them as references in the P2Pi workshop set of papers. Fabius Klemm, Jean-Yves Le Boudec, Karl Aberer: Congestion Control for Distributed Hash Tables. The 5th IEEE International Symposium on Network Computing and Applications (IEEE NCA06), Cambridge, MA, USA, July 24 - 26, 2006 (available online at http://lsirpeople.epfl.ch/klemm/Congestion%20Control%20for%20Distributed%20Hash%20Tables.pdf) Fabius Klemm, Jean-Yves Le Boudec, Dejan Kostic, Karl Aberer: Improving the Throughput of Distributed Hash Tables Using Congestion-Aware Routing. International Workshop on Peer-to-Peer Systems (IPTPS'07), Bellevue, WA, USA, February 26.-27, 2007 (available online at http://lsirpeople.epfl.ch/klemm/Improving%20the%20Throughput%20of%20Distributed%20Hash%20Tables%20Using%20Congestion-Aware%20Routing.pdf) Thanks, - vijay -- Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent 2701 Lucent Lane, Rm. 9F-546, Lisle, Illinois 60532 (USA) Email: vkg@{alcatel-lucent.com,bell-labs.com,acm.org} WWW: http://www.alcatel-lucent.com/bell-labs _______________________________________________ p2pi mailing list p2pi@ietf.org https://www.ietf.org/mailman/listinfo/p2pi From p2pi-bounces@ietf.org Fri Jun 6 17:05:46 2008 Return-Path: X-Original-To: p2pi-archive@ietf.org Delivered-To: ietfarch-p2pi-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4B17A3A6BE9; Fri, 6 Jun 2008 17:05:46 -0700 (PDT) X-Original-To: p2pi@core3.amsl.com Delivered-To: p2pi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8453428C231 for ; Fri, 6 Jun 2008 17:05:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.547 X-Spam-Level: * X-Spam-Status: No, score=1.547 tagged_above=-999 required=5 tests=[AWL=-0.404, BAYES_40=-0.185, 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 C3xr35MVzqWY for ; Fri, 6 Jun 2008 17:05:43 -0700 (PDT) Received: from pacdcimo01.cable.comcast.com (PacdcIMO01.cable.comcast.com [24.40.8.145]) by core3.amsl.com (Postfix) with ESMTP id 9C1A928C1D5 for ; Fri, 6 Jun 2008 17:05:43 -0700 (PDT) Received: from ([10.195.246.152]) by pacdcimo01.cable.comcast.com with ESMTP id 5503620.4837758; Fri, 06 Jun 2008 20:05:28 -0400 Received: from PACDCEXCMB04.cable.comcast.com ([24.40.15.86]) by NJMDCEXCRLY01.cable.comcast.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 6 Jun 2008 20:05:27 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 6 Jun 2008 20:04:17 -0400 Message-ID: <45AEC6EF95942140888406588E1A6602045CBA5E@PACDCEXCMB04.cable.comcast.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Follow-Up from Comcast Presentation Thread-Index: AcjIMgcZVv04IMkkTIiwEw2u3A/+kw== From: "Livingood, Jason" To: X-OriginalArrivalTime: 07 Jun 2008 00:05:27.0952 (UTC) FILETIME=[3134C100:01C8C832] Subject: [p2pi] Follow-Up 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 As a follow-up to our presentation of last week, on slide 3 we cited some of our key focus areas, which were improved/increased transparency, disclosure, openness, and fairness. We hope we took some steps in that direction in the overall slide deck. Beginning on slide 11 we went into a good level of detail on technical trials of a new network management technique, which was protocol-agnostic. Related to this, we now have a new FAQ on our website about those trials at http://help.comcast.net/content/faq/Frequently-Asked-Questions-about-Net work-Management#technique . Also, customers in those trial markets have received an email that explains details about the trial, which is started yesterday. Additional information is also available to subscribers via a link in our Terms of Service, directly to http://www.comcast.net/terms/network/ . In addition, on slide 10, we described speed upgrades for our customers that should now be in place. As noted during our presentation, we continue to be interested in specific feedback on the method described. We hope to be able to share trial results at some point, and in some TBD form. Perhaps that will be possible by the time IETF 72 rolls around. I know I had some private follow-ups with folks like Henning as well, and will get to some of those next week. Regards Jason _______________________________________________ p2pi mailing list p2pi@ietf.org https://www.ietf.org/mailman/listinfo/p2pi From p2pi-bounces@ietf.org Fri Jun 6 19:09:38 2008 Return-Path: X-Original-To: p2pi-archive@ietf.org Delivered-To: ietfarch-p2pi-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C489E3A6991; Fri, 6 Jun 2008 19:09:38 -0700 (PDT) X-Original-To: p2pi@core3.amsl.com Delivered-To: p2pi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 62F993A6991 for ; Fri, 6 Jun 2008 19:09:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.841 X-Spam-Level: X-Spam-Status: No, score=-0.841 tagged_above=-999 required=5 tests=[AWL=-0.836, BAYES_20=-0.74, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SARE_NETPROD=0.111, WHOIS_NETSOLPR=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 bxOWR-ZttFSN for ; Fri, 6 Jun 2008 19:09:36 -0700 (PDT) Received: from wf-out-1314.google.com (wf-out-1314.google.com [209.85.200.172]) by core3.amsl.com (Postfix) with ESMTP id 9CD293A67FB for ; Fri, 6 Jun 2008 19:09:36 -0700 (PDT) Received: by wf-out-1314.google.com with SMTP id 27so1286535wfd.31 for ; Fri, 06 Jun 2008 19:09:47 -0700 (PDT) Received: by 10.142.147.18 with SMTP id u18mr271548wfd.343.1212804587690; Fri, 06 Jun 2008 19:09:47 -0700 (PDT) Received: by 10.142.186.7 with HTTP; Fri, 6 Jun 2008 19:09:47 -0700 (PDT) Message-ID: <3efc39a60806061909n11a65eafnce88df7c73c30639@mail.gmail.com> Date: Fri, 6 Jun 2008 21:09:47 -0500 From: "Robb Topolski" To: "Livingood, Jason" In-Reply-To: <45AEC6EF95942140888406588E1A6602045CBA5E@PACDCEXCMB04.cable.comcast.com> MIME-Version: 1.0 References: <45AEC6EF95942140888406588E1A6602045CBA5E@PACDCEXCMB04.cable.comcast.com> Cc: p2pi@ietf.org Subject: Re: [p2pi] Follow-Up 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: multipart/mixed; boundary="===============0134535212==" Sender: p2pi-bounces@ietf.org Errors-To: p2pi-bounces@ietf.org --===============0134535212== Content-Type: multipart/alternative; boundary="----=_Part_8373_30793110.1212804587654" ------=_Part_8373_30793110.1212804587654 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline My feedback is that discrimination based on user-history is no better than protocol-discriminatory behavior. Just as the Internet Standards do not lead developers to expect a network that discriminates against a protocol, those same standards do not prepare developers for a network that is discriminating based on nebulous concepts of "fairness." In particular, I'm concerned with possible scenarios such as someone who is mid-upload of 1100 European vacation pictures (all at 8 Megapixel) when her husband has a medical emergency. She dials 9-1-1 on Vonage or whatever non-Comcast VOIP device. Comcast delays and drops her packets as the new system places her VOIP call is behind long packet queues created by other activity in her neighborhood. Another set of scenarios pertains to users, applications, or devices reserving bandwidth that should be available to them within their teir, and the unexpected malfunction when the bandwidth that they purchased is not available. First, there is the RSVP scheduler native to Microsoft OS's for many years. Second, there are applications like NetLimiter, where responsible and savvy users can segment their bandwidth or keep certain applications under control Third, and ironically, almost all P2P applications have upload bandwidth limiters. Users are generally advised to set these to less than their subscribed bandwidth so as to allow other Internet uses (such as VOIP calls). Finally, there are many consumer hardware devices that allow users to tune prioritization. For example, many consumer gateway-router devices marketed under different brands use a QoS engine by Ubicom. These devices determine the upload stream size either as manually configured by the user or measured automatically when the router reboots. These devices will not function properly if the bandwidth it believes it is reserving is suddenly made unavailable by the network. In summary, best-effort traffic is the baseline traffic expectation and developers of Internet products do not expect a situation where a network operator has invented a "worse than best-effort" traffic class -- nor should they. The issues are, likewise, the same as with protocol discrimination. The users are harmed because their network is behaving strangely and they have no way of knowing why. The devices that they buy at the store with the system requirements of "Broadband Internet Connection" do not work on their connections. There is no notice before, during, or after their traffic is deprioritized. And finally, they suffer a very non-technical consumer harm in that they receive less than the plan that was marketed and sold to them. Innovation is harmed because the access and transit networks continue to behave unexpectedly. It isn't the network operator who will get the call about the online game or VOIP application that is behaving poorly, it's the software publisher. I particularly worry about how the binary nature of this "penalty box" will look to users (when all traffic is either prioritized or not, deprioritized traffic suffers significant degredation as only it is fighting for the limited resource). Normally, a sustained amount of network congestion slows everyone relatively equally and smooths out the effects -- and this effect is rather well recognized as a congestion effect. Therefore, such behavior will deflect calls for help to publishers and manufacturers of networking products, driving up their costs and decreasing their willingness to invest in new bandwidth-eating applications. And lastly, this is bad for the future growth of the Internet. Allow me to editorialize, please -- this will not be technical. During my career at the worlds largest chip manufacturer, our products (almost by definition) followed a very "Moore's Law" capability curve. If the CPU overhead was not going to be available, then why develop software with richer detail, smoother video, and deeper sound. The USA actually does enjoy among the better broadband speeds (not the best, but at the knee of the curve http://news.bbc.co.uk/2/hi/technology/7098992.stm), even though the Cable industry is clearly overpromising and underdelivering ( http://arstechnica.com/news.ars/post/20080228-att-talks-serious-smack-about-cable-broadband-speeds.html). Comcast is sending the signal that the operators of the access networks are going to tamp down the natural demand-based growth of the internet is as uninteligent as a chip manufacturer saying that they're done making faster chips. So why would someone release a bandwidth-hungry product into that environment? Just as the world's largest chip manufacturers enable innovation by trying to stay as far ahead of developers ability to suck-up MIPS as possible, I would expect someone serious about leading in the business of broadband should be doing the same. Thanks for asking for feedback. I'm sorry it is not at all positive. While I do recognize efforts at more transparency and user notification as good things, the method itself fails the standards compatibility test. Robb Topolski On Fri, Jun 6, 2008 at 7:04 PM, Livingood, Jason < Jason_Livingood@cable.comcast.com> wrote: > As a follow-up to our presentation of last week, on slide 3 we cited > some of our key focus areas, which were improved/increased transparency, > disclosure, openness, and fairness. We hope we took some steps in that > direction in the overall slide deck. Beginning on slide 11 we went into > a good level of detail on technical trials of a new network management > technique, which was protocol-agnostic. > > Related to this, we now have a new FAQ on our website about those trials > at > http://help.comcast.net/content/faq/Frequently-Asked-Questions-about-Net > work-Management#technique. Also, customers in those trial markets have > received an email that explains details about the trial, which is > started yesterday. Additional information is also available to > subscribers via a link in our Terms of Service, directly to > http://www.comcast.net/terms/network/ . In addition, on slide 10, we > described speed upgrades for our customers that should now be in place. > > As noted during our presentation, we continue to be interested in > specific feedback on the method described. We hope to be able to share > trial results at some point, and in some TBD form. Perhaps that will be > possible by the time IETF 72 rolls around. I know I had some private > follow-ups with folks like Henning as well, and will get to some of > those next week. > > Regards > Jason > > > _______________________________________________ > 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_8373_30793110.1212804587654 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline My feedback is that discrimination based on user-history is no better than = protocol-discriminatory behavior. Just as the Internet Standards do not lea= d developers to expect a network that discriminates against a protocol, tho= se same standards do not prepare developers for a network that is discrimin= ating based on nebulous concepts of "fairness." 

In particular, I'm concerned with possible scenarios such as someon= e who is mid-upload of 1100 European vacation pictures (all at 8 Megapixel)= when her husband has a medical emergency.  She dials 9-1-1 on Vonage = or whatever non-Comcast VOIP device. Comcast delays and drops her packets a= s the new system places her VOIP call is behind long packet queues created = by other activity in her neighborhood. 

Another set of scenarios pertains to users, applications, or devices re= serving bandwidth that should be available to them within their teir, and t= he unexpected malfunction when the bandwidth that they purchased is not ava= ilable.  First, there is the RSVP scheduler native to Microsoft OS'= ;s for many years. Second, there are applications like NetLimiter, where re= sponsible and savvy users can segment their bandwidth or keep certain appli= cations under control  Third, and ironically, almost all P2P applicati= ons have upload bandwidth limiters.  Users are generally advised to se= t these to less than their subscribed bandwidth so as to allow other Intern= et uses (such as VOIP calls).  Finally, there are many consumer hardwa= re devices that allow users to tune prioritization.  For example, many= consumer gateway-router devices marketed under different brands use a QoS = engine by Ubicom.  These devices determine the upload stream size eith= er as manually configured by the user or measured automatically when the ro= uter reboots.  These devices will not function properly if the bandwid= th it believes it is reserving is suddenly made unavailable by the network.=   In summary, best-effort traffic is the baseline traffic expectation = and developers of Internet products do not expect a situation where a netwo= rk operator has invented a "worse than best-effort" traffic class= -- nor should they.

The issues are, likewise, the same as with protocol discrimination.&nbs= p;

The users are harmed because their network is behaving strangely= and they have no way of knowing why.  The devices that they buy at th= e store with the system requirements of "Broadband Internet Connection= " do not work on their connections.  There is no notice before, d= uring, or after their traffic is deprioritized.  And finally, they suf= fer a very non-technical consumer harm in that they receive less than the p= lan that was marketed and sold to them.

Innovation is harmed because the access and transit networks continue t= o behave unexpectedly.  It isn't the network operator who will get= the call about the online game or VOIP application that is behaving poorly= , it's the software publisher.  I particularly worry about how the= binary nature of this "penalty box" will look to users (when all= traffic is either prioritized or not, deprioritized traffic suffers signif= icant degredation as only it is fighting for the limited resource).  N= ormally, a sustained amount of network congestion slows everyone relatively= equally and smooths out the effects -- and this effect is rather well reco= gnized as a congestion effect.  Therefore, such behavior will deflect = calls for help to publishers and manufacturers of networking products, driv= ing up their costs and decreasing their willingness to invest in new bandwi= dth-eating applications.

And lastly, this is bad for the future growth of the Internet.  Al= low me to editorialize, please -- this will not be technical.  During = my career at the worlds largest chip manufacturer, our products (almost by = definition) followed a very "Moore's Law" capability curve.&n= bsp; If the CPU overhead was not going to be available, then why develop so= ftware with richer detail, smoother video, and deeper sound.  The USA = actually does enjoy among the better broadband speeds (not the best, but at= the knee of the curve http://news.bbc.co.uk/2/hi/technology/7098992.stm), even thou= gh the Cable industry is clearly overpromising and underdelivering (http://arstechnica.com/news.ars/post/2008= 0228-att-talks-serious-smack-about-cable-broadband-speeds.html).  = Comcast is sending the signal that the operators of the access  networ= ks are going to tamp down the natural demand-based growth of the internet i= s as uninteligent as a chip manufacturer saying that they're done makin= g faster chips.  So why would someone release a bandwidth-hungry produ= ct into that environment?  Just as the world's largest chip manufa= cturers enable innovation by trying to stay as far ahead of developers abil= ity to suck-up MIPS as possible, I would expect someone serious about leadi= ng in the business of broadband should be doing the same.

Thanks for asking for feedback.  I'm sorry it is not at all po= sitive.  While I do recognize efforts at more transparency and user no= tification as good things, the method itself fails the standards compatibil= ity test.

Robb Topolski

 

On Fri, = Jun 6, 2008 at 7:04 PM, Livingood, Jason <Jason_Livingood@cable.comcast.com> wrote:
=
As a follow-up to our presentation of last week, on slide 3 we cited
some of our key focus areas, which were improved/increased transparency, disclosure, openness, and fairness.  We hope we took some steps in tha= t
direction in the overall slide deck.  Beginning on slide 11 we went in= to
a good level of detail on technical trials of a new network management
technique, which was protocol-agnostic.

Related to this, we now have a new FAQ on our website about those trials at
http://help.comcast.ne= t/content/faq/Frequently-Asked-Questions-about-Net
work-Management#technique .  Also, customers in those trial market= s have
received an email that explains details about the trial, which is
started yesterday.  Additional information is also available to
subscribers via a link in our Terms of Service, directly to
http://= www.comcast.net/terms/network/ .  In addition, on slide 10, we
described speed upgrades for our customers that should now be in place.

As noted during our presentation, we continue to be interested in
specific feedback on the method described.  We hope to be able to shar= e
trial results at some point, and in some TBD form.  Perhaps that will = be
possible by the time IETF 72 rolls around.  I know I had some private<= br> follow-ups with folks like Henning as well, and will get to some of
those next week.

Regards
Jason


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



--
Robb Topolski (robb@funchords.com)
Hillsboro, Oregon= USA
http://www.funchords.com/ ------=_Part_8373_30793110.1212804587654-- --===============0134535212== 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 --===============0134535212==-- From p2pi-bounces@ietf.org Fri Jun 6 19:56:03 2008 Return-Path: X-Original-To: p2pi-archive@ietf.org Delivered-To: ietfarch-p2pi-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1FEB63A68C1; Fri, 6 Jun 2008 19:56:03 -0700 (PDT) X-Original-To: p2pi@core3.amsl.com Delivered-To: p2pi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EC5313A6905 for ; Fri, 6 Jun 2008 19:56:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.336 X-Spam-Level: X-Spam-Status: No, score=-6.336 tagged_above=-999 required=5 tests=[AWL=0.263, 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 CSrfATvSMGUg for ; Fri, 6 Jun 2008 19:56:00 -0700 (PDT) Received: from fruitcake.ICSI.Berkeley.EDU (fruitcake.ICSI.Berkeley.EDU [192.150.186.11]) by core3.amsl.com (Postfix) with ESMTP id 003413A68C1 for ; Fri, 6 Jun 2008 19:55:59 -0700 (PDT) Received: from [IPv6:::1] (fruitcake [192.150.186.11]) by fruitcake.ICSI.Berkeley.EDU (8.12.11.20060614/8.12.11) with ESMTP id m572u7bf001930; Fri, 6 Jun 2008 19:56:07 -0700 (PDT) Message-Id: <4CB75CEA-FE7E-4398-A1B3-A03DBF5063D3@icsi.berkeley.edu> From: Nicholas Weaver To: Robb Topolski In-Reply-To: <3efc39a60806061909n11a65eafnce88df7c73c30639@mail.gmail.com> Mime-Version: 1.0 (Apple Message framework v924) Date: Fri, 6 Jun 2008 19:56:08 -0700 References: <45AEC6EF95942140888406588E1A6602045CBA5E@PACDCEXCMB04.cable.comcast.com> <3efc39a60806061909n11a65eafnce88df7c73c30639@mail.gmail.com> X-Mailer: Apple Mail (2.924) Cc: p2pi@ietf.org, "Livingood, Jason" , Nicholas Weaver Subject: Re: [p2pi] Follow-Up 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 On Jun 6, 2008, at 7:09 PM, Robb Topolski wrote: > My feedback is that discrimination based on user-history is no > better than protocol-discriminatory behavior. Just as the Internet > Standards do not lead developers to expect a network that > discriminates against a protocol, those same standards do not > prepare developers for a network that is discriminating based on > nebulous concepts of "fairness." THis is a RIDICULOUS notion. And "Fairness" doesn't have to be nebulous. "In the periods of congestion, when there are N users competing for traffic, no user will get more than 1/N - epsilon of the available bandwidth, measured as a running average over 10 seconds and 10 minutes". A nice concrete definition, that would INSTANTLY prioritize small flows over large flows, and interactive flows over bulk flows, when examined between users. Its what users really expect when you talk about "fairness". > In particular, I'm concerned with possible scenarios such as someone > who is mid-upload of 1100 European vacation pictures (all at 8 > Megapixel) when her husband has a medical emergency. She dials > 9-1-1 on Vonage or whatever non-Comcast VOIP device. Comcast delays > and drops her packets as the new system places her VOIP call is > behind long packet queues created by other activity in her > neighborhood. > So you'd rather her not be able to make a VoIP 911 call because someone ELSE on the same subnet is running BitTorrent grabbing "Indiana Jones and the Latest McGuffin"? In fact, this is EXACTLY the case why ISPs need to do both INTER user fairness (to ensure that everyone gets some reasonable allocation, because TCP DOES NOT PROVIDE THIS AS THE APPLICATIONS ARE USED!) and INTRA-user shaping to prioritize small flows (a simple "prioritize smaller flows" instantly ensures that VoIP still works). Yes, we can all dream of the utopia where the picture upload knows that its a picture upload and the VoIP call knows its a VoIP call and the networking signaling takes care of itself. But with all the crappy NAT boxes (eg, which randomly inject RST packets into active flows!), crappy end host software, and crud in between, if you want the VoIP call to have priority, the ISP must infer that it is a VoIP call and treat it as such, because otherwise the old devices, with their many limitations, will mess up your signaling. But until then, INTER user fairness is essential, because without it, the net can't operate in the flat-rate billing model. > Another set of scenarios pertains to users, applications, or devices > reserving bandwidth that should be available to them within their > teir, and the unexpected malfunction when the bandwidth that they > purchased is not available. If you want a DEDICATED 10 Mbps, rather than a statistically multiplexed 10 Mbps, pay for it! It costs ~$1000 a month or so for a reason. Or pay-per-bit, in which case the ISP would be happy to not do any traffic shaping at all, because your bit is worth the same as your neighbors. But in the flat rate world, heavy users traffic is less valuable to the ISP, and damaging to the light users. Remember, you may have 5000+ users sharing a single 1 Gbps uplink. Yes, they have a "16 Mbps" download, but it only works because not everybody is downloading at full rate at the same time. And notions of network enforced fairness should not mess up the dream of devices which do proper scheduling: NO network device should, or CAN assume that the bandwidth is fully committed to it. Otherwise, why would you have congestion control? _______________________________________________ p2pi mailing list p2pi@ietf.org https://www.ietf.org/mailman/listinfo/p2pi From p2pi-bounces@ietf.org Sat Jun 7 08:51:55 2008 Return-Path: X-Original-To: p2pi-archive@ietf.org Delivered-To: ietfarch-p2pi-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BABA63A6B0D; Sat, 7 Jun 2008 08:51:55 -0700 (PDT) X-Original-To: p2pi@core3.amsl.com Delivered-To: p2pi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 803013A6B03 for ; Sat, 7 Jun 2008 08:51:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.247 X-Spam-Level: X-Spam-Status: No, score=-0.247 tagged_above=-999 required=5 tests=[AWL=-0.871, BAYES_50=0.001, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HZGrCokeNzLK for ; Sat, 7 Jun 2008 08:51:52 -0700 (PDT) Received: from wf-out-1314.google.com (wf-out-1314.google.com [209.85.200.171]) by core3.amsl.com (Postfix) with ESMTP id 6641A3A6B0D for ; Sat, 7 Jun 2008 08:51:52 -0700 (PDT) Received: by wf-out-1314.google.com with SMTP id 27so1544773wfd.31 for ; Sat, 07 Jun 2008 08:52:05 -0700 (PDT) Received: by 10.143.32.4 with SMTP id k4mr559975wfj.251.1212853924903; Sat, 07 Jun 2008 08:52:04 -0700 (PDT) Received: by 10.142.186.7 with HTTP; Sat, 7 Jun 2008 08:52:04 -0700 (PDT) Message-ID: <3efc39a60806070852p49f6a066y27e804fd5d4cf989@mail.gmail.com> Date: Sat, 7 Jun 2008 10:52:04 -0500 From: "Robb Topolski" To: "Nicholas Weaver" In-Reply-To: <4CB75CEA-FE7E-4398-A1B3-A03DBF5063D3@icsi.berkeley.edu> MIME-Version: 1.0 References: <45AEC6EF95942140888406588E1A6602045CBA5E@PACDCEXCMB04.cable.comcast.com> <3efc39a60806061909n11a65eafnce88df7c73c30639@mail.gmail.com> <4CB75CEA-FE7E-4398-A1B3-A03DBF5063D3@icsi.berkeley.edu> Cc: p2pi@ietf.org, "Livingood, Jason" Subject: Re: [p2pi] Follow-Up 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: multipart/mixed; boundary="===============1477956478==" Sender: p2pi-bounces@ietf.org Errors-To: p2pi-bounces@ietf.org --===============1477956478== Content-Type: multipart/alternative; boundary="----=_Part_880_3827984.1212853924899" ------=_Part_880_3827984.1212853924899 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline > THis is a RIDICULOUS notion. > I would have expected a better choice of words, Nick. > And "Fairness" doesn't have to be nebulous. "In the periods of congestion, > when there are N users competing for traffic, no user will get more than 1/N > - epsilon of the available bandwidth, measured as a running average over 10 > seconds and 10 minutes". It seems that we both agree this would be an improvement, but still not good enough unless codified somewhere (suggested, vetted, approved, and made Internet Standard by the IETF). > A nice concrete definition, that would INSTANTLY prioritize small flows > over large flows, and interactive flows over bulk flows, when examined > between users. Its what users really expect when you talk about "fairness". I think you will agree that users don't know about flows, and developers might think fairness means the equal opportunity to send at any given moment despite what happened milliseconds ago. > > 9-1-1 scenario (emergency call, 999, etc.) >> > > So you'd rather her not be able to make a VoIP 911 call because someone > ELSE on the same subnet is running BitTorrent grabbing "Indiana Jones and > the Latest McGuffin"? > Anything that is popular is popular because it works on the Internet -- warts and all. There is nothing out there that depends on prioritization as the differentiating factor between "working" and "not working." Prioritization simply makes such real-time applications more robust. 99% of the time, the Internet is fine. Prioritization helps certain applications during that 1% of the time. (brown numbers disclaimer) Yes, we can all dream of the utopia where the picture upload knows that its > a picture upload and the VoIP call knows its a VoIP call and the networking > signaling takes care of itself. This is not my utopia. > But with all the crappy NAT boxes (eg, which randomly inject RST packets > into active flows!), crappy end host software, and crud in between, The solution to interference by non-Standards-conforming devices should not be adding additional non-standards-conforming devices. if you want the VoIP call to have priority, the ISP must infer that it is a > VoIP call and treat it as such, because otherwise the old devices, with > their many limitations, will mess up your signaling. You have missed my point, and perhaps others did to. Note the word priority does not exist in the following paragraph, nor is any signalling mentioned: Best-effort is the baseline expectation of innovators creating products for the Internet -- even with some congestion thrown in. They design their products to work in such a network. They cannot expect that network operators will invent worse-than-best-effort class that dramatically changes the characteristics of the network from one moment to the next. > But until then, INTER user fairness is essential, because without it, the > net can't operate in the flat-rate billing model. I'm certain that it can, if not for all, for most. According to the NCTA, this is a problem caused by a very few users. That statement doesn't pass the smell test, however. I think that the market demands and competitive abilities for more symmetrical connections in the last mile have outstripped Cable's ability to keep up with it. I think that these are not technical problems, these are willful business choices in approaching the market: Cable Internet is shaping the future by shaping the traffic in the present because it serves many of their business interests to do so. Perhaps the business interest is simply to avoid increasing costs related to bandwidth growth; perhaps it is more. Either way, the follow-on consequence is limiting the options to consumers who are distracted from watching television by the many competing choices on the Internet. The beauty of the Internet Standards is that they hold no such motives or bias. They are EE/CS's answer to MBAs as to what should and should not be happening on the 'Net. Another set of scenarios pertains to users, applications, or devices >> reserving bandwidth that should be available to them within their teir, and >> the unexpected malfunction when the bandwidth that they purchased is not >> available. >> > > If you want a DEDICATED 10 Mbps, rather than a statistically multiplexed 10 > Mbps, pay for it! It costs ~$1000 a month or so for a reason. Or > pay-per-bit, in which case the ISP would be happy to not do any traffic > shaping at all, because your bit is worth the same as your neighbors. > > But in the flat rate world, heavy users traffic is less valuable to the > ISP, and damaging to the light users. Remember, you may have 5000+ users > sharing a single 1 Gbps uplink. Yes, they have a "16 Mbps" download, but it > only works because not everybody is downloading at full rate at the same > time. > Nicholas, everything you said above is true. It is also beside the point to everyone on this list -- we understand the technical implications of the shared nature of their Internet connection. Grandma and Grandpa Farmer or Mr. and Mrs. Factory Worker do not and should not have to understand overbooking (or statistical multiplexing, or bandwidth aggregating, or whatever). The ISPs control the sizes of the shared pools of bandwidth, the number of consumers who share it, the prices of admission, and the size of the pipes between a subscriber and the pool. They have total control and purview over those variables. Controlling these variables to ensure that everyone has a good experience is Reasonable Network Management. Regardless of how ISPs structure the offering, the end effect has to be Internet access that works reliably for subscribers who are using the Internet within those parameters. A major ISP offering Internet service that fluctuates wildly between working and not-working well is bad for the entire community! More and more, people and businesses rely on the internet. If it becomes perceived as unreliable, it is much less valuable and the network will shrink. Today, common advice in VOIP forums is to not rely on your provider for 9-1-1 calls. Regardless of the actual soundness of such advice, we should be working toward a day where such advice is universally dismissed due to the actual increased reliability of Internet services and infrastructure. Users, unnovators, service providers, and even operators should all be able to rely on the fact that the Internet does not and will not behave unpredictably from one segment to the next, from one moment to the next, or from one protocol to the next. > NO network device should, or CAN assume that the bandwidth is fully > committed to it. That is good advice, but it is not yet understood. Even the most savvy network developers expect that once the network is accurately detected or described into its configuration, that it does not change from moment to moment. There's a story some of the Comcast guys told me about Apple iChat and Powerboost. Your advice would have helped the iChat developers avoid some headaches. But, you weren't thinking of these things -- you were thinking about congestion... > Otherwise, why would you have congestion control? > Unlike your advice above, everyone understands that congestion happens. Some congestion on the Internet is expected from time to time, and developers work in enough robustness. But, nothing is really expected to work well through a system that is *cronically clogged*. Current congestion-control algorithms are quick and are sufficient for taming momentary spikes in congestion. Comcast is not talking about relieving spikes of congestion. Instead, they are moving toward *prolonged congestion as a planned operational mode*. As I pointed out, they have announced that they are tripling their upload speeds (presumably even though the underlying shared pool of bandwidth has remained the same as these increases are not related to DOCSIS3 deployment). Comcast would only need to invent this new method unless they have abandoned expectations to keep the amount of available bandwidth well ahead of their consumers' demand for it. -- Robb Topolski (robb@funchords.com) Hillsboro, Oregon USA http://www.funchords.com/ ------=_Part_880_3827984.1212853924899 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline
THis is a RIDICULOUS notion.

I would have expected a better choice of words, Nick. 

 
And "Fairness" doesn't have to be nebulous.  "In the periods of congestion, when there are N users competing for traffic, no user will get more than 1/N - epsilon of the available bandwidth, measured as a running average over 10 seconds and 10 minutes".

It seems that we both agree this would be an improvement, but still not good enough unless codified somewhere (suggested, vetted, approved, and made Internet Standard by the IETF). 

 
A nice concrete definition, that would INSTANTLY prioritize small flows over large flows, and interactive flows over bulk flows, when examined between users.  Its what users really expect when you talk about "fairness".

I think you will agree that users don't know about flows, and developers might think fairness means the equal opportunity to send at any given moment despite what happened milliseconds ago.

 

9-1-1 scenario (emergency call, 999, etc.)

So you'd rather her not be able to make a VoIP 911 call because someone ELSE on the same subnet is running BitTorrent grabbing "Indiana Jones and the Latest McGuffin"?

Anything that is popular is popular because it works on the Internet -- warts and all.  There is nothing out there that depends on prioritization as the differentiating factor between "working" and "not working."  Prioritization simply makes such real-time applications more robust.  99% of the time, the Internet is fine.  Prioritization helps certain applications during that 1% of the time.  (brown numbers disclaimer)


Yes, we can all dream of the utopia where the picture upload knows that its a picture upload and the VoIP call knows its a VoIP call and the networking signaling takes care of itself.  

This is not my utopia. 

 
But with all the crappy NAT boxes (eg, which randomly inject RST packets into active flows!), crappy end host software, and crud in between,

The solution to interference by non-Standards-conforming devices should not be adding additional non-standards-conforming devices.


if you want the VoIP call to have priority, the ISP must infer that it is a VoIP call and treat it as such, because otherwise the old devices, with their many limitations, will mess up your signaling.

You have missed my point, and perhaps others did to.  Note the word priority does not exist in the following paragraph, nor is any signalling mentioned:

Best-effort is the baseline expectation of innovators creating products for the Internet -- even with some congestion thrown in.  They design their products to work in such a network.  They cannot expect that network operators will invent worse-than-best-effort class that dramatically changes the characteristics of the network from one moment to the next.

 
But until then, INTER user fairness is essential, because without it, the net can't operate in the flat-rate billing model.

I'm certain that it can, if not for all, for most. 

According to the NCTA, this is a problem caused by a very few users.  That statement doesn't pass the smell test, however.  I think that the market demands and competitive abilities for more symmetrical connections in the last mile have outstripped Cable's ability to keep up with it. 

I think that these are not technical problems, these are willful business choices in approaching the market: Cable Internet is shaping the future by shaping the traffic in the present because it serves many of their business interests to do so.  Perhaps the business interest is simply to avoid increasing costs related to bandwidth growth; perhaps it is more.  Either way, the follow-on consequence is limiting the options to consumers who are distracted from watching television by the many competing choices on the Internet.

The beauty of the Internet Standards is that they hold no such motives or bias.  They are EE/CS's answer to MBAs as to what should and should not be happening on the 'Net.


Another set of scenarios pertains to users, applications, or devices reserving bandwidth that should be available to them within their teir, and the unexpected malfunction when the bandwidth that they purchased is not available.

If you want a DEDICATED 10 Mbps, rather than a statistically multiplexed 10 Mbps, pay for it!  It costs ~$1000 a month or so for a reason.  Or pay-per-bit, in which case the ISP would be happy to not do any traffic shaping at all, because your bit is worth the same as your neighbors.

But in the flat rate world, heavy users traffic is less valuable to the ISP, and damaging to the light users.  Remember, you may have 5000+ users sharing a single 1 Gbps uplink.  Yes, they have a "16 Mbps" download, but it only works because not everybody is downloading at full rate at the same time.

Nicholas, everything you said above is true.  It is also beside the point to everyone on this list -- we understand the technical implications of the shared nature of their Internet connection.  Grandma and Grandpa Farmer or Mr. and Mrs. Factory Worker do not and should not have to understand overbooking (or statistical multiplexing, or bandwidth aggregating, or whatever).

The ISPs control the sizes of the shared pools of bandwidth, the number of consumers who share it, the prices of admission, and the size of the pipes between a subscriber and the pool.  They have total control and purview over those variables.  Controlling these variables to ensure that everyone has a good experience is Reasonable Network Management. 

Regardless of how ISPs structure the offering, the end effect has to be Internet access that works reliably for subscribers who are using the Internet within those parameters. A major ISP offering Internet service that fluctuates wildly between working and not-working well is bad for the entire community!

More and more, people and businesses rely on the internet.  If it becomes perceived as unreliable, it is much less valuable and the network will shrink. Today, common advice in VOIP forums is to not rely on your provider for 9-1-1 calls.  Regardless of the actual soundness of such advice, we should be working toward a day where such advice is universally dismissed due to the actual increased reliability of Internet services and infrastructure.

Users, unnovators, service providers, and even operators should all be able to rely on the fact that the Internet does not and will not behave unpredictably from one segment to the next, from one moment to the next, or from one protocol to the next.
 
NO network device should, or CAN assume that the bandwidth is fully committed to it.  

That is good advice, but it is not yet understood.  Even the most savvy network developers expect that once the network is accurately detected or described into its configuration, that it does not change from moment to moment.

There's a story some of the Comcast guys told me about Apple iChat and Powerboost.  Your advice would have helped the iChat developers avoid some headaches. 

But, you weren't thinking of these things -- you were thinking about congestion...
 
Otherwise, why would you have congestion control?

Unlike your advice above, everyone understands that congestion happens.  Some congestion on the Internet is expected from time to time, and developers work in enough robustness.  But, nothing is really expected to work well through a system that is cronically clogged.  Current congestion-control algorithms are quick and are sufficient for taming momentary spikes in congestion.

Comcast is not talking about relieving spikes of congestion.  Instead, they are moving toward prolonged congestion as a planned operational mode.  As I pointed out, they have announced that they are tripling their upload speeds (presumably even though the underlying shared pool of bandwidth has remained the same as these increases are not related to DOCSIS3 deployment). 

Comcast would only need to invent this new method unless they have abandoned expectations to keep the amount of available bandwidth well ahead of their consumers' demand for it. 

--
Robb Topolski (robb@funchords.com)
Hillsboro, Oregon USA
http://www.funchords.com/ ------=_Part_880_3827984.1212853924899-- --===============1477956478== 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 --===============1477956478==-- From p2pi-bounces@ietf.org Sat Jun 7 10:39: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 EE95A3A6805; Sat, 7 Jun 2008 10:39: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 D8FD73A6805 for ; Sat, 7 Jun 2008 10:39:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.962 X-Spam-Level: X-Spam-Status: No, score=-0.962 tagged_above=-999 required=5 tests=[AWL=-0.963, BAYES_50=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 taaV7+yCp6-t for ; Sat, 7 Jun 2008 10:39:12 -0700 (PDT) Received: from mailhost.jlc.net (mailhost.jlc.net [199.201.159.9]) by core3.amsl.com (Postfix) with ESMTP id 5BCFE3A67B1 for ; Sat, 7 Jun 2008 10:39:12 -0700 (PDT) Received: by mailhost.jlc.net (Postfix, from userid 104) id A9E8D33C74; Sat, 7 Jun 2008 13:39:25 -0400 (EDT) Date: Sat, 7 Jun 2008 13:39:25 -0400 From: John Leslie To: Robb Topolski Message-ID: <20080607173925.GJ8579@verdi> References: <45AEC6EF95942140888406588E1A6602045CBA5E@PACDCEXCMB04.cable.comcast.com> <3efc39a60806061909n11a65eafnce88df7c73c30639@mail.gmail.com> <4CB75CEA-FE7E-4398-A1B3-A03DBF5063D3@icsi.berkeley.edu> <3efc39a60806070852p49f6a066y27e804fd5d4cf989@mail.gmail.com> Mime-Version: 1.0 Content-Disposition: inline In-Reply-To: <3efc39a60806070852p49f6a066y27e804fd5d4cf989@mail.gmail.com> User-Agent: Mutt/1.4.1i Cc: p2pi@ietf.org Subject: Re: [p2pi] Follow-Up 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 Robb Topolski wrote: > > Best-effort is the baseline expectation of innovators creating products > for the Internet -- even with some congestion thrown in. They design > their products to work in such a network. They cannot expect that > network operators will invent worse-than-best-effort class that > dramatically changes the characteristics of the network from one moment > to the next. I strongly recommend we avoid the term "worse-than-best-effort" -- it is unlikely we can agree on a common meaning for it. Obviously Robb likes the connotations it brings (and dislikes the idea of such a beast); but others are using the term to mean something which _could_ be reasonable. Rather than try to agree on a term, I suggest we instead invest the time to write words that say what we actually mean. > According to the NCTA, this is a problem caused by a very few users. That's at least partly true -- today. Part of our job is to convince them that only a sucker would bet it will still be true six months from now. > I think that the market demands and competitive abilities for more > symmetrical connections in the last mile have outstripped Cable's > ability to keep up with it. I wouldn't put it quite that way. However, market demand is already seriously taxing Cable ISPs' _practices_ for keeping up with it. > I think that these are not technical problems, these are willful > business choices in approaching the market: Cable Internet is shaping > the future by shaping the traffic in the present because it serves > many of their business interests to do so. That bears repeating. Cable ISPs don't enjoy great support from Corporate management. Most sales are for combinations of services, and Corporate management is used to thinking ten-year depreciation schedules which can be stretched to twenty to improve quarterly profits. > Perhaps the business interest is simply to avoid increasing costs > related to bandwidth growth... Absolutely. > The ISPs control the sizes of the shared pools of bandwidth, the > number of consumers who share it, the prices of admission, and the > size of the pipes between a subscriber and the pool. They have total > control and purview over those variables. Controlling these variables > to ensure that everyone has a good experience is Reasonable Network > Management. ... but what Corporate management wants is to serve a mass market. > A major ISP offering Internet service that fluctuates wildly between > working and not-working well is bad for the entire community! Correct! So long as Corporate management believes they can avoid those fluctuations by eliminating "bad users", they will try to do so. > Today, common advice in VOIP forums is to not rely on your provider > for 9-1-1 calls. Regardless of the actual soundness of such advice, > we should be working toward a day where such advice is universally > dismissed due to the actual increased reliability of Internet > services and infrastructure. I'm not sure that is a reasonable goal for Cable ISPs. Telco ISPs can certainly get there, and independent ISPs are already there; but Cable ISPs are perceived as cost centers, not profit centers. > Even the most savvy network developers expect that once the network > is accurately detected or described into its configuration, that it > does not change from moment to moment. Another misconception we should try to cure. (I'm not holding my breath!) > Some congestion on the Internet is expected from time to time, and > developers work in enough robustness. But, nothing is really > expected to work well through a system that is *cronically clogged*. Nonetheless, chronic clogging has been a local feature as long as there has been an Internet. > Comcast is not talking about relieving spikes of congestion. > Instead, they are moving toward *prolonged congestion as a planned > operational mode*. Actually, I disagree: they are perfectly willing to shed the customers they believe are causing congestion. > As I pointed out, they have announced that they are tripling their > upload speeds (because that's what a DOCSIS upgrade promises for "free") > (presumably even though the underlying shared pool of bandwidth > has remained the same as these increases are not related to DOCSIS3 > deployment). Upstream _transport_ (to the "backbone") is pretty cheap. Last-mile upstream is congested because of design choices (the technical term IMHO is "mistakes") of DOCSIS upstream scheduling). I am not privy to actual DOCSIS 3 specs; so I don't know whether these "adverse features" have been fixed. -- John Leslie _______________________________________________ p2pi mailing list p2pi@ietf.org https://www.ietf.org/mailman/listinfo/p2pi From p2pi-bounces@ietf.org Sat Jun 7 10:48:34 2008 Return-Path: X-Original-To: p2pi-archive@ietf.org Delivered-To: ietfarch-p2pi-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 777CD3A6B43; Sat, 7 Jun 2008 10:48:34 -0700 (PDT) X-Original-To: p2pi@core3.amsl.com Delivered-To: p2pi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D4C4B3A67A7 for ; Sat, 7 Jun 2008 10:48:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.499 X-Spam-Level: X-Spam-Status: No, score=-2.499 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5ZjUaEWqmHSS for ; Sat, 7 Jun 2008 10:48:33 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by core3.amsl.com (Postfix) with ESMTP id 17DB23A6AF2 for ; Sat, 7 Jun 2008 10:48:33 -0700 (PDT) Received: from [127.0.0.1] (pool-71-106-109-69.lsanca.dsl-w.verizon.net [71.106.109.69]) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id m57HmSwu020485 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sat, 7 Jun 2008 10:48:30 -0700 (PDT) Message-ID: <484AC9EB.8060501@isi.edu> Date: Sat, 07 Jun 2008 10:48:27 -0700 From: Joe Touch User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: John Leslie References: <45AEC6EF95942140888406588E1A6602045CBA5E@PACDCEXCMB04.cable.comcast.com> <3efc39a60806061909n11a65eafnce88df7c73c30639@mail.gmail.com> <4CB75CEA-FE7E-4398-A1B3-A03DBF5063D3@icsi.berkeley.edu> <3efc39a60806070852p49f6a066y27e804fd5d4cf989@mail.gmail.com> <20080607173925.GJ8579@verdi> In-Reply-To: <20080607173925.GJ8579@verdi> X-Enigmail-Version: 0.95.6 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: p2pi@ietf.org Subject: Re: [p2pi] Follow-Up 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: multipart/mixed; boundary="===============1345081010==" Sender: p2pi-bounces@ietf.org Errors-To: p2pi-bounces@ietf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============1345081010== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig2DB097BE1E3058F935D6E707" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig2DB097BE1E3058F935D6E707 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable John Leslie wrote: > Robb Topolski wrote: >> Best-effort is the baseline expectation of innovators creating product= s >> for the Internet -- even with some congestion thrown in. They design >> their products to work in such a network. They cannot expect that >> network operators will invent worse-than-best-effort class that >> dramatically changes the characteristics of the network from one momen= t >> to the next. >=20 > I strongly recommend we avoid the term "worse-than-best-effort" -- > it is unlikely we can agree on a common meaning for it. Least effort? Joe --------------enig2DB097BE1E3058F935D6E707 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFISsnsE5f5cImnZrsRAiWhAJ9itkIXN5p3RgWExOjPV2ZBC4gicgCgg/xz DmSg5AWq758Eev01+nku0I8= =S4gy -----END PGP SIGNATURE----- --------------enig2DB097BE1E3058F935D6E707-- --===============1345081010== 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 --===============1345081010==-- From p2pi-bounces@ietf.org Sat Jun 7 10:57:00 2008 Return-Path: X-Original-To: p2pi-archive@ietf.org Delivered-To: ietfarch-p2pi-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B8A7C3A6B21; Sat, 7 Jun 2008 10:57:00 -0700 (PDT) X-Original-To: p2pi@core3.amsl.com Delivered-To: p2pi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CA5A53A6B21 for ; Sat, 7 Jun 2008 10:56:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.102 X-Spam-Level: X-Spam-Status: No, score=-2.102 tagged_above=-999 required=5 tests=[AWL=0.497, 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 WAaW6lR8RZJM for ; Sat, 7 Jun 2008 10:56:59 -0700 (PDT) Received: from mailhost.jlc.net (mailhost.jlc.net [199.201.159.9]) by core3.amsl.com (Postfix) with ESMTP id 1C9FB3A6AF2 for ; Sat, 7 Jun 2008 10:56:59 -0700 (PDT) Received: by mailhost.jlc.net (Postfix, from userid 104) id 8738933C35; Sat, 7 Jun 2008 13:57:12 -0400 (EDT) Date: Sat, 7 Jun 2008 13:57:12 -0400 From: John Leslie To: Joe Touch Message-ID: <20080607175712.GK8579@verdi> References: <45AEC6EF95942140888406588E1A6602045CBA5E@PACDCEXCMB04.cable.comcast.com> <3efc39a60806061909n11a65eafnce88df7c73c30639@mail.gmail.com> <4CB75CEA-FE7E-4398-A1B3-A03DBF5063D3@icsi.berkeley.edu> <3efc39a60806070852p49f6a066y27e804fd5d4cf989@mail.gmail.com> <20080607173925.GJ8579@verdi> <484AC9EB.8060501@isi.edu> Mime-Version: 1.0 Content-Disposition: inline In-Reply-To: <484AC9EB.8060501@isi.edu> User-Agent: Mutt/1.4.1i Cc: p2pi@ietf.org Subject: Re: [p2pi] Follow-Up 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 Joe Touch wrote: > John Leslie wrote: >> >> I strongly recommend we avoid the term "worse-than-best-effort" -- >> it is unlikely we can agree on a common meaning for it. > > Least effort? Not a bad term... ;^) But can we actually _agree_ on a meaning for it? -- John Leslie _______________________________________________ p2pi mailing list p2pi@ietf.org https://www.ietf.org/mailman/listinfo/p2pi From p2pi-bounces@ietf.org Sat Jun 7 11:05: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 0242A3A6B43; Sat, 7 Jun 2008 11:05: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 F0EAD3A6B1C for ; Sat, 7 Jun 2008 11:05:23 -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 TIpS+pOSV9du for ; Sat, 7 Jun 2008 11:05:23 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by core3.amsl.com (Postfix) with ESMTP id 2F5C53A67A7 for ; Sat, 7 Jun 2008 11:05:23 -0700 (PDT) Received: from [127.0.0.1] (pool-71-106-109-69.lsanca.dsl-w.verizon.net [71.106.109.69]) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id m57I5FKf027127 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sat, 7 Jun 2008 11:05:17 -0700 (PDT) Message-ID: <484ACDDA.6010303@isi.edu> Date: Sat, 07 Jun 2008 11:05:14 -0700 From: Joe Touch User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: John Leslie References: <45AEC6EF95942140888406588E1A6602045CBA5E@PACDCEXCMB04.cable.comcast.com> <3efc39a60806061909n11a65eafnce88df7c73c30639@mail.gmail.com> <4CB75CEA-FE7E-4398-A1B3-A03DBF5063D3@icsi.berkeley.edu> <3efc39a60806070852p49f6a066y27e804fd5d4cf989@mail.gmail.com> <20080607173925.GJ8579@verdi> <484AC9EB.8060501@isi.edu> <20080607175712.GK8579@verdi> In-Reply-To: <20080607175712.GK8579@verdi> X-Enigmail-Version: 0.95.6 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: p2pi@ietf.org Subject: Re: [p2pi] Follow-Up 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: multipart/mixed; boundary="===============1078116742==" Sender: p2pi-bounces@ietf.org Errors-To: p2pi-bounces@ietf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============1078116742== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigFA5B5E103E97D0899D592FBD" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigFA5B5E103E97D0899D592FBD Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable John Leslie wrote: > Joe Touch wrote: >> John Leslie wrote: >>> I strongly recommend we avoid the term "worse-than-best-effort" -- >>> it is unlikely we can agree on a common meaning for it. >> Least effort? >=20 > Not a bad term... ;^) >=20 > But can we actually _agree_ on a meaning for it? >=20 > -- > John Leslie Least effort =3D the first traffic dropped in a the presence of congestio= n That means it would lose to best effort, though. In some cases, that's what you want. In other cases, you want something=20 that basically loses to TCP, but competes with current best-effort=20 normally. That's just best-effort, AFAICT. Joe --------------enigFA5B5E103E97D0899D592FBD Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFISs3bE5f5cImnZrsRAgk9AJ9S7NwjSoqk2qkedI7V9eli1+dAzQCfSc86 TI1YlD4HEyPwfuJ/DJ90JBo= =o/Co -----END PGP SIGNATURE----- --------------enigFA5B5E103E97D0899D592FBD-- --===============1078116742== 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 --===============1078116742==-- From p2pi-bounces@ietf.org Sat Jun 7 11:10:13 2008 Return-Path: X-Original-To: p2pi-archive@ietf.org Delivered-To: ietfarch-p2pi-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 18AEA3A6B43; Sat, 7 Jun 2008 11:10:13 -0700 (PDT) X-Original-To: p2pi@core3.amsl.com Delivered-To: p2pi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AE3893A6B43 for ; Sat, 7 Jun 2008 11:10:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aBdWo59+Bg8v for ; Sat, 7 Jun 2008 11:10:09 -0700 (PDT) Received: from bender-mail.tigertech.net (bender-mail.tigertech.net [64.62.209.30]) by core3.amsl.com (Postfix) with ESMTP id EE7B23A6B33 for ; Sat, 7 Jun 2008 11:10:09 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by bender.tigertech.net (Postfix) with ESMTP id 4733C7DC8 for ; Sat, 7 Jun 2008 11:10:23 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at bender.tigertech.net Received: from [192.168.1.3] (pool-71-163-24-2.washdc.fios.verizon.net [71.163.24.2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by bender.tigertech.net (Postfix) with ESMTP id BAC7D7DC2 for ; Sat, 7 Jun 2008 11:10:21 -0700 (PDT) Message-ID: <484ACEEC.9070705@joelhalpern.com> Date: Sat, 07 Jun 2008 14:09:48 -0400 From: "Joel M. Halpern" User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: p2pi@ietf.org References: <45AEC6EF95942140888406588E1A6602045CBA5E@PACDCEXCMB04.cable.comcast.com> <3efc39a60806061909n11a65eafnce88df7c73c30639@mail.gmail.com> <4CB75CEA-FE7E-4398-A1B3-A03DBF5063D3@icsi.berkeley.edu> <3efc39a60806070852p49f6a066y27e804fd5d4cf989@mail.gmail.com> <20080607173925.GJ8579@verdi> <484AC9EB.8060501@isi.edu> <20080607175712.GK8579@verdi> In-Reply-To: <20080607175712.GK8579@verdi> Subject: Re: [p2pi] Follow-Up 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 Several of the meeting presentations referred to "Scavenger service". As a definition, assuming I am allowed to define using diffserv, how about: Unmarked packets, and packets marked for better diffserv classes will receive preferential queueing treatment compared with those marked with Scavenger class service. To avoid starvatation, the Scavanger queue will be guaranteed a minimal percentage (10%?) of the data capacity even when normal and better services could consume all available bandwidth. That is basically the inverse of the simplified EF definition, for achieving essentially the opposite goal. Joel John Leslie wrote: > Joe Touch wrote: >> John Leslie wrote: >>> I strongly recommend we avoid the term "worse-than-best-effort" -- >>> it is unlikely we can agree on a common meaning for it. >> Least effort? > > Not a bad term... ;^) > > But can we actually _agree_ on a meaning for it? > > -- > John Leslie > _______________________________________________ > p2pi mailing list > p2pi@ietf.org > https://www.ietf.org/mailman/listinfo/p2pi > _______________________________________________ p2pi mailing list p2pi@ietf.org https://www.ietf.org/mailman/listinfo/p2pi From p2pi-bounces@ietf.org Sat Jun 7 12:15:00 2008 Return-Path: X-Original-To: p2pi-archive@ietf.org Delivered-To: ietfarch-p2pi-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D78383A6BA1; Sat, 7 Jun 2008 12:15:00 -0700 (PDT) X-Original-To: p2pi@core3.amsl.com Delivered-To: p2pi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5C0493A6B9E for ; Sat, 7 Jun 2008 12:14:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.173 X-Spam-Level: X-Spam-Status: No, score=-2.173 tagged_above=-999 required=5 tests=[AWL=0.426, 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 r+QRB7rIAKxz for ; Sat, 7 Jun 2008 12:14:58 -0700 (PDT) Received: from mailhost.jlc.net (mailhost.jlc.net [199.201.159.9]) by core3.amsl.com (Postfix) with ESMTP id 736593A6B93 for ; Sat, 7 Jun 2008 12:14:55 -0700 (PDT) Received: by mailhost.jlc.net (Postfix, from userid 104) id 2068033C37; Sat, 7 Jun 2008 15:15:09 -0400 (EDT) Date: Sat, 7 Jun 2008 15:15:09 -0400 From: John Leslie To: "Joel M. Halpern" Message-ID: <20080607191509.GL8579@verdi> References: <45AEC6EF95942140888406588E1A6602045CBA5E@PACDCEXCMB04.cable.comcast.com> <3efc39a60806061909n11a65eafnce88df7c73c30639@mail.gmail.com> <4CB75CEA-FE7E-4398-A1B3-A03DBF5063D3@icsi.berkeley.edu> <3efc39a60806070852p49f6a066y27e804fd5d4cf989@mail.gmail.com> <20080607173925.GJ8579@verdi> <484AC9EB.8060501@isi.edu> <20080607175712.GK8579@verdi> <484ACEEC.9070705@joelhalpern.com> Mime-Version: 1.0 Content-Disposition: inline In-Reply-To: <484ACEEC.9070705@joelhalpern.com> User-Agent: Mutt/1.4.1i Cc: p2pi@ietf.org Subject: Re: [p2pi] Follow-Up 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 Joel M. Halpern wrote: > > Several of the meeting presentations referred to "Scavenger service". > > As a definition, assuming I am allowed to define using diffserv, how about: > > Unmarked packets, and packets marked for better diffserv classes will > receive preferential queueing treatment compared with those marked with > Scavenger class service. To avoid starvatation, the Scavanger queue > will be guaranteed a minimal percentage (10%?) of the data capacity even > when normal and better services could consume all available bandwidth. > > That is basically the inverse of the simplified EF definition, for > achieving essentially the opposite goal. Hmm... we really _ought_ to be able to define "scavenger service"... To me, "scavenger service" implies that the application is happy to see some periods -- say ten minutes or more -- where no packets are getting delivered at all, so long as the connection isn't lost. (Of course, this definition starts to fall apart at inter-planetary distances...) -- John Leslie _______________________________________________ p2pi mailing list p2pi@ietf.org https://www.ietf.org/mailman/listinfo/p2pi From p2pi-bounces@ietf.org Sat Jun 7 12:23:32 2008 Return-Path: X-Original-To: p2pi-archive@ietf.org Delivered-To: ietfarch-p2pi-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 68C1A3A6B9A; Sat, 7 Jun 2008 12:23:32 -0700 (PDT) X-Original-To: p2pi@core3.amsl.com Delivered-To: p2pi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E651A3A6B9A for ; Sat, 7 Jun 2008 12:23:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.369 X-Spam-Level: X-Spam-Status: No, score=-6.369 tagged_above=-999 required=5 tests=[AWL=0.230, 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 UGht7Ww3DxVd for ; Sat, 7 Jun 2008 12:23:29 -0700 (PDT) Received: from fruitcake.ICSI.Berkeley.EDU (fruitcake.ICSI.Berkeley.EDU [192.150.186.11]) by core3.amsl.com (Postfix) with ESMTP id 8F6EB3A6B33 for ; Sat, 7 Jun 2008 12:23:29 -0700 (PDT) Received: from [IPv6:::1] (fruitcake [192.150.186.11]) by fruitcake.ICSI.Berkeley.EDU (8.12.11.20060614/8.12.11) with ESMTP id m57JNepf026232; Sat, 7 Jun 2008 12:23:40 -0700 (PDT) Message-Id: <1B22E2BD-9910-477D-AF13-AC6F1B5FAD43@icsi.berkeley.edu> From: Nicholas Weaver To: John Leslie In-Reply-To: <20080607191509.GL8579@verdi> Mime-Version: 1.0 (Apple Message framework v924) Date: Sat, 7 Jun 2008 12:23:39 -0700 References: <45AEC6EF95942140888406588E1A6602045CBA5E@PACDCEXCMB04.cable.comcast.com> <3efc39a60806061909n11a65eafnce88df7c73c30639@mail.gmail.com> <4CB75CEA-FE7E-4398-A1B3-A03DBF5063D3@icsi.berkeley.edu> <3efc39a60806070852p49f6a066y27e804fd5d4cf989@mail.gmail.com> <20080607173925.GJ8579@verdi> <484AC9EB.8060501@isi.edu> <20080607175712.GK8579@verdi> <484ACEEC.9070705@joelhalpern.com> <20080607191509.GL8579@verdi> X-Mailer: Apple Mail (2.924) Cc: p2pi@ietf.org, Nicholas Weaver Subject: Re: [p2pi] Follow-Up 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 There is always just "friendlier than TCP-Reno under reasonable ranges of latency and bandwidth" as a definition, so conventional TCP flows will outcompete the "scavenger" service. Of which there are plenty of examples, including TCP-vegas, of stable congestion control algorithms which have this property. So the question is not "How do you do this?" but "Why is this not done?". I believe that the Linux stack, for example, allows you to switch the behavior of newly-created flows from Vegas to Reno with a /proc update. _______________________________________________ p2pi mailing list p2pi@ietf.org https://www.ietf.org/mailman/listinfo/p2pi From p2pi-bounces@ietf.org Sat Jun 7 12:54: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 255E43A6BCD; Sat, 7 Jun 2008 12:54: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 8D4493A6BCD for ; Sat, 7 Jun 2008 12:54:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.265 X-Spam-Level: X-Spam-Status: No, score=-2.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id REdXVAGqCzE5 for ; Sat, 7 Jun 2008 12:54:38 -0700 (PDT) Received: from outbound-mail-134.bluehost.com (outbound-mail-134.bluehost.com [67.222.39.24]) by core3.amsl.com (Postfix) with SMTP id 73F0E3A6B33 for ; Sat, 7 Jun 2008 12:54:38 -0700 (PDT) Received: (qmail 25064 invoked by uid 0); 7 Jun 2008 19:54:48 -0000 Received: from unknown (HELO host46.hostmonster.com) (74.220.202.46) by outboundproxy4.bluehost.com with SMTP; 7 Jun 2008 19:54:48 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=bennett.com; h=Received:Message-ID:Date:From:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding:X-Identified-User:DomainKey-Status; b=C8xPNXQy7TsYogQMpw5nOFaxrbsMsjPY+OAq3NRbtUZ4VkhSIbm+/RPPqBZFQ3Tf09TAKmOrcN05vJd/bJBtEI+0vWSxiN20MZ2q/RQUbnURDjWu2x3FxKch2+S87thT; Received: from c-67-169-90-32.hsd1.ca.comcast.net ([67.169.90.32] helo=[192.168.0.12]) by host46.hostmonster.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.68) (envelope-from ) id 1K54Uy-0006u9-G1; Sat, 07 Jun 2008 13:54:48 -0600 Message-ID: <484AE788.1030208@bennett.com> Date: Sat, 07 Jun 2008 12:54:48 -0700 From: Richard Bennett User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: p2pi@ietf.org References: <45AEC6EF95942140888406588E1A6602045CBA5E@PACDCEXCMB04.cable.comcast.com> <3efc39a60806061909n11a65eafnce88df7c73c30639@mail.gmail.com> <4CB75CEA-FE7E-4398-A1B3-A03DBF5063D3@icsi.berkeley.edu> <3efc39a60806070852p49f6a066y27e804fd5d4cf989@mail.gmail.com> <20080607173925.GJ8579@verdi> <484AC9EB.8060501@isi.edu> <20080607175712.GK8579@verdi> <484ACEEC.9070705@joelhalpern.com> <20080607191509.GL8579@verdi> <1B22E2BD-9910-477D-AF13-AC6F1B5FAD43@icsi.berkeley.edu> In-Reply-To: <1B22E2BD-9910-477D-AF13-AC6F1B5FAD43@icsi.berkeley.edu> X-Identified-User: {842:host46.hostmonster.com:bennett1:bennett.com} {sentby:smtp auth 67.169.90.32 authed with richard+bennett.com} DomainKey-Status: no signature Cc: Nicholas Weaver Subject: Re: [p2pi] Follow-Up 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 This is an interesting discussion. By way of introduction, I'm mainly an IEEE 802 guy, having contributed to 802.3, 802.11, and 802.15.3a, but I did have some input into RFC 1001 and 1002, and have worked on Bandwidth Brokers to support video conferencing and that sort of thing for a while. I think some combination of Re-ECN and Diffserv will solve the congestion problem that we see on primarily on Layer 2 networks thanks to increased use of P2P. In the 802.11e/Wi-Fi Alliance WMM world, we created four priorities that are easily mappable to DSCP and 802.1d VLAN tags: Voice, Video, Best Effort, and Background. The worse-than-best-effort service is Background. WMM is implemented in all the wireless NAT boxes that have sold over the last three years or so, so it's basically the status quo model for residential networks. In the early days of the Internet, during the Great Switchover period, the default Layer 2 was DIX Ethernet, a single service system, but nowadays Wi-Fi is a major part of the Layer 2 scenario with its four service classes. We could do worse than see how to smoothly integrate this sort of Layer 2 service into the IETF stack. David Clark made the observation at the FCC hearing in Cambridge that it would be nice for the network to communicate its congestion state to applications a priori, so that applications would make decisions about how to handle current conditions. This strikes me as a wise enhancement. It would no doubt be facilitated by a system that improved layer-to-layer communication within the stack. IEEE 802 goes to great pains to describe Service Access Points at each layer and a variety of return codes for accessing functions. In principle a Layer 3 function desiring a specific priority from Layer 2 can simply ask for it when presenting a packet, and be told if it got what it wanted. In practice, the DiffServ model of tagging packets with priority can be married with 802.11e/WMM through what we call a Convergence Function in 802 land. The 802.11e standard actually describes one, but I'm not sure it's right. We probably won't make much progress here if we engage in too much hand-waving and opining about the old days of the Internet and what assumptions developers may or may not have, so it's probably wise to stick to specifics as Nick has below. Richard Bennett Nicholas Weaver wrote: > There is always just "friendlier than TCP-Reno under reasonable ranges > of latency and bandwidth" as a definition, so conventional TCP flows > will outcompete the "scavenger" service. > > Of which there are plenty of examples, including TCP-vegas, of stable > congestion control algorithms which have this property. > > So the question is not "How do you do this?" but "Why is this not > done?". > > I believe that the Linux stack, for example, allows you to switch the > behavior of newly-created flows from Vegas to Reno with a /proc update. > > _______________________________________________ > p2pi mailing list > p2pi@ietf.org > https://www.ietf.org/mailman/listinfo/p2pi > _______________________________________________ p2pi mailing list p2pi@ietf.org https://www.ietf.org/mailman/listinfo/p2pi From p2pi-bounces@ietf.org Sat Jun 7 15:26:59 2008 Return-Path: X-Original-To: p2pi-archive@ietf.org Delivered-To: ietfarch-p2pi-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B46DB3A6895; Sat, 7 Jun 2008 15:26:59 -0700 (PDT) X-Original-To: p2pi@core3.amsl.com Delivered-To: p2pi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 75F283A6884 for ; Sat, 7 Jun 2008 15:26:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.33 X-Spam-Level: X-Spam-Status: No, score=-1.33 tagged_above=-999 required=5 tests=[AWL=0.646, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jcZK49D+v-xA for ; Sat, 7 Jun 2008 15:26:57 -0700 (PDT) Received: from wf-out-1314.google.com (wf-out-1314.google.com [209.85.200.170]) by core3.amsl.com (Postfix) with ESMTP id 14E6A3A67EE for ; Sat, 7 Jun 2008 15:26:53 -0700 (PDT) Received: by wf-out-1314.google.com with SMTP id 27so1651843wfd.31 for ; Sat, 07 Jun 2008 15:27:07 -0700 (PDT) Received: by 10.143.16.15 with SMTP id t15mr683007wfi.285.1212877627604; Sat, 07 Jun 2008 15:27:07 -0700 (PDT) Received: by 10.142.186.7 with HTTP; Sat, 7 Jun 2008 15:27:07 -0700 (PDT) Message-ID: <3efc39a60806071527x1460fdefg26226cbaa682c8f1@mail.gmail.com> Date: Sat, 7 Jun 2008 17:27:07 -0500 From: "Robb Topolski" To: "John Leslie" In-Reply-To: <20080607173925.GJ8579@verdi> MIME-Version: 1.0 References: <45AEC6EF95942140888406588E1A6602045CBA5E@PACDCEXCMB04.cable.comcast.com> <3efc39a60806061909n11a65eafnce88df7c73c30639@mail.gmail.com> <4CB75CEA-FE7E-4398-A1B3-A03DBF5063D3@icsi.berkeley.edu> <3efc39a60806070852p49f6a066y27e804fd5d4cf989@mail.gmail.com> <20080607173925.GJ8579@verdi> Cc: p2pi@ietf.org Subject: Re: [p2pi] Follow-Up 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: multipart/mixed; boundary="===============0350027825==" Sender: p2pi-bounces@ietf.org Errors-To: p2pi-bounces@ietf.org --===============0350027825== Content-Type: multipart/alternative; boundary="----=_Part_1344_8212095.1212877627606" ------=_Part_1344_8212095.1212877627606 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline responses inlined -- On Sat, Jun 7, 2008 at 12:39 PM, John Leslie wrote: > I strongly recommend we avoid the term "worse-than-best-effort" -- > it is unlikely we can agree on a common meaning for it. > > Obviously Robb likes the connotations it brings (and dislikes the > idea of such a beast); but others are using the term to mean something > which _could_ be reasonable. On the contrary, I have no particular affection for the term at all. I simply mean Comcast's new (under trial) traffic classification for traffic from heavy bandwidth users. Since most would assume that "best effort" describes the undifferentiated traffic from subscribers, traffic that comes from Comcast's "affected" users will be dropped or delayed more often than "best-effort" traffic. That was not an attempt to word-smith, and please do not read in malice where there is none intended. The above description is simply easily summarized as "worse-than-best-effort." I apologize that my post could be read with some tone of snarkyness. None was intended. Thanks to John for pointing that out. > So long as Corporate management believes they can avoid those > fluctuations by eliminating "bad users", they will try to do so. > > ...and... > > > Comcast is not talking about relieving spikes of congestion. > > Instead, they are moving toward *prolonged congestion as a planned > > operational mode*. > > Actually, I disagree: they are perfectly willing to shed the > customers they believe are causing congestion. > > Then the ISP should end the provider-consumer relationship. This is not a technical problem the IETF can solve, either. Instead of sponsoring the idea The IETF should run in the opposite direction of this PR nightmare. Nonetheless, chronic clogging has been a local feature as long as > there has been an Internet. Maybe I've just been plain lucky. Comcast in my area (AT&T Broadband, TCI prior to that) have been excellent. Do we have any data to work with about this congestion? (I feel like I'm back to the subject of my paper.) How bad? How prolonged? And since the ISPs control the product parameters -- the sizes of the shared pools of bandwidth, the number of consumers who share it, the prices of admission, and the size of the pipes between a subscriber and the shared pool -- does the technical community generally accept that this as a business problem or a technical problem? Robb Topolski -- Robb Topolski (robb@funchords.com) Hillsboro, Oregon USA http://www.funchords.com/ ------=_Part_1344_8212095.1212877627606 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline responses inlined --

On Sat, Jun 7, 2008 at 12:39 PM, John Leslie <john@jlc.net> wrote:
  I strongly recommend we avoid the term "worse-than-best-effort" --
it is unlikely we can agree on a common meaning for it.

  Obviously Robb likes the connotations it brings (and dislikes the
idea of such a beast); but others are using the term to mean something
which _could_ be reasonable.

On the contrary, I have no particular affection for the term at all.

I simply mean Comcast's new (under trial) traffic classification for traffic from heavy bandwidth users.  Since most would assume that "best effort" describes the undifferentiated traffic from subscribers, traffic that comes from Comcast's "affected" users will be dropped or delayed more often than "best-effort" traffic. 

That was not an attempt to word-smith, and please do not read in malice where there is none intended. The above description is simply easily summarized as "worse-than-best-effort." 

I apologize that my post could be read with some tone of snarkyness.  None was intended.  Thanks to John for pointing that out.


  So long as Corporate management believes they can avoid those
fluctuations by eliminating "bad users", they will try to do so.

...and...

> Comcast is not talking about relieving spikes of congestion.
> Instead, they are moving toward *prolonged congestion as a planned
> operational mode*.

  Actually, I disagree: they are perfectly willing to shed the
customers they believe are causing congestion.



Then the ISP should end the provider-consumer relationship.  This is not a technical problem the IETF can solve, either.  Instead of sponsoring the idea The IETF should run in the opposite direction of this PR nightmare.


  Nonetheless, chronic clogging has been a local feature as long as
there has been an Internet.

Maybe I've just been plain lucky.  Comcast in my area (AT&T Broadband, TCI prior to that) have been excellent. 

Do we have any data to work with about this congestion?  (I feel like I'm back to the subject of my paper.)  How bad? How prolonged?  And since the ISPs control the product parameters -- the sizes of the shared pools of bandwidth, the number of consumers who share it, the prices of admission, and the size of the pipes between a subscriber and the shared pool -- does the technical community generally accept that this as a business problem or a technical problem?

Robb Topolski

--
Robb Topolski (robb@funchords.com)
Hillsboro, Oregon USA
http://www.funchords.com/ ------=_Part_1344_8212095.1212877627606-- --===============0350027825== 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 --===============0350027825==-- From p2pi-bounces@ietf.org Sat Jun 7 17:10:37 2008 Return-Path: X-Original-To: p2pi-archive@ietf.org Delivered-To: ietfarch-p2pi-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4321F3A6810; Sat, 7 Jun 2008 17:10:37 -0700 (PDT) X-Original-To: p2pi@core3.amsl.com Delivered-To: p2pi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0F5EF3A6810 for ; Sat, 7 Jun 2008 17:10:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.536 X-Spam-Level: X-Spam-Status: No, score=-1.536 tagged_above=-999 required=5 tests=[AWL=-0.729, BAYES_00=-2.599, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334, MIME_HTML_ONLY=1.457] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S4+kGxjVxpPd for ; Sat, 7 Jun 2008 17:10:35 -0700 (PDT) Received: from outbound-mail-32.bluehost.com (outbound-mail-32.bluehost.com [69.89.18.152]) by core3.amsl.com (Postfix) with SMTP id 9F20E3A6C2C for ; Sat, 7 Jun 2008 17:10:17 -0700 (PDT) Received: (qmail 3044 invoked by uid 0); 8 Jun 2008 00:10:28 -0000 Received: from unknown (HELO host46.hostmonster.com) (74.220.202.46) by outboundproxy2.bluehost.com with SMTP; 8 Jun 2008 00:10:28 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=bennett.com; h=Received:Message-ID:Date:From:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding:X-Identified-User:DomainKey-Status; b=BY+cm9xFAr3yk4stPxrt9iW7MP8egjNHzInxWiSfiFgqQEyHzTYs8Git2s0Naiu/s4sHsWWfepzhpN1NUc2/060cNRDVQ7A0U5pkMfBPPCv4J9S6JxZXVePlPBIotkcv; Received: from c-67-169-90-32.hsd1.ca.comcast.net ([67.169.90.32] helo=[192.168.0.12]) by host46.hostmonster.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.68) (envelope-from ) id 1K58UN-0006eX-Eq; Sat, 07 Jun 2008 18:10:27 -0600 Message-ID: <484B2372.80401@bennett.com> Date: Sat, 07 Jun 2008 17:10:26 -0700 From: Richard Bennett User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: Robb Topolski References: <45AEC6EF95942140888406588E1A6602045CBA5E@PACDCEXCMB04.cable.comcast.com> <3efc39a60806061909n11a65eafnce88df7c73c30639@mail.gmail.com> <4CB75CEA-FE7E-4398-A1B3-A03DBF5063D3@icsi.berkeley.edu> <3efc39a60806070852p49f6a066y27e804fd5d4cf989@mail.gmail.com> <20080607173925.GJ8579@verdi> <3efc39a60806071527x1460fdefg26226cbaa682c8f1@mail.gmail.com> In-Reply-To: <3efc39a60806071527x1460fdefg26226cbaa682c8f1@mail.gmail.com> X-Identified-User: {842:host46.hostmonster.com:bennett1:bennett.com} {sentby:smtp auth 67.169.90.32 authed with richard+bennett.com} DomainKey-Status: no signature Cc: p2pi@ietf.org Subject: Re: [p2pi] Follow-Up 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: multipart/mixed; boundary="===============1666449471==" Sender: p2pi-bounces@ietf.org Errors-To: p2pi-bounces@ietf.org --===============1666449471== Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit I think the point is that the Internet's traffic model only works if the first-hop network handled most of the congestion and the core is relatively uncongested. That's because congestion management mitigates overload at the source, and the fewer hops the load travels before back-pressure is applied, the more efficient the use of network resources. Reading RFCs 896 and 970 and this remark by John Nagle on Slashdot may help:

http://tech.slashdot.org/comments.pl?sid=497516&cid=22847764

RB

Robb Topolski wrote:
responses inlined --

On Sat, Jun 7, 2008 at 12:39 PM, John Leslie <john@jlc.net> wrote:
  Nonetheless, chronic clogging has been a local feature as long as
there has been an Internet.

Maybe I've just been plain lucky.  Comcast in my area (AT&T Broadband, TCI prior to that) have been excellent. 

Do we have any data to work with about this congestion?  (I feel like I'm back to the subject of my paper.)  How bad? How prolonged?  And since the ISPs control the product parameters -- the sizes of the shared pools of bandwidth, the number of consumers who share it, the prices of admission, and the size of the pipes between a subscriber and the shared pool -- does the technical community generally accept that this as a business problem or a technical problem?

Robb Topolski

--
Robb Topolski (robb@funchords.com)
Hillsboro, Oregon USA
http://www.funchords.com/ 

_______________________________________________
p2pi mailing list
p2pi@ietf.org
https://www.ietf.org/mailman/listinfo/p2pi
--===============1666449471== 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 --===============1666449471==-- From p2pi-bounces@ietf.org Sun Jun 8 01:00: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 273A93A6AE3; Sun, 8 Jun 2008 01:00: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 58ABB3A6AE3 for ; Sun, 8 Jun 2008 01:00:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.095 X-Spam-Level: X-Spam-Status: No, score=-5.095 tagged_above=-999 required=5 tests=[AWL=-1.096, BAYES_50=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fWR+c8o7kZ4a for ; Sun, 8 Jun 2008 01:00:19 -0700 (PDT) Received: from fruitcake.ICSI.Berkeley.EDU (fruitcake.ICSI.Berkeley.EDU [192.150.186.11]) by core3.amsl.com (Postfix) with ESMTP id EB05D3A6AB6 for ; Sun, 8 Jun 2008 01:00:18 -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 m5880EHR019879; Sun, 8 Jun 2008 01:00:29 -0700 (PDT) Message-Id: From: Nicholas Weaver To: p2pi@ietf.org Mime-Version: 1.0 (Apple Message framework v924) Date: Sun, 8 Jun 2008 01:00:13 -0700 X-Mailer: Apple Mail (2.924) Cc: Nicholas Weaver Subject: [p2pi] For those who think "User Fairness/Cost Fairness" is unacceptable... X-BeenThere: p2pi@ietf.org X-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 following is a bunch of semi-random thoughts, mostly addressed at the notion that user fairness enforced in the network is an unacceptable solution, and that traffic management should not discriminate based on protocol. For those who think "User Fairness"/"Cost Fairness" is unacceptable: Which would you rather have a) Usage based pricing/usage caps b) App manipulation/prioritization/blocking [1] c) User-based fairness It has got to be one of the three as long as 5% of the users use >50% of the bandwidth, and as long as you have effectively misbehaving users and applications centered around flow-fairness, because there is no economic model which justifies adding more bandwidth when the 5%-10% users benefit but the 90% don't see a benefit when the pricing is flat rate. Its only if you no longer have the heavy tail that adding more bandwidth makes sense in flat pricing. [2] And if instead of statistical multiplexing, you want committed or at least semi-committed bandwidth (the "They sold me a 16 Mbps link, so where is my 16 Mbps?" argument), there is a reason it is vastly more expensive. Talk to a commercial ISP about a 1.5 Mbps T1 with a service level agreement, and compare that to the cost of your "16 Mbps" cable-modem. Additionally, there is a reason why I believe the example given by Mr Topolski of fairness disrupting a VoIP 911 call "ridiculous". This argument seems to rests on the assumption that limiting a heavy user to some non-zero fair fraction of a total pipe would disrupt a VoIP 911 that is concurrent with a user's other activity [3], but at the same time, insist that the ISP should not take action to limit other users who disrupt the pipe (which is the current situation where some users are opening up 1/2 a dozen torrents simultaneously) which has been shown in practice to disrupt VoIP calls? I will also argue there is a compelling case for protocol discrimination by the ISPs. For example, users would benefit if the ISP shaped their flows just enough to keep the send buffers on the cable/DSL modems reasonably empty using delay-based heuristics, even when there is NOT congestion in the overall network, just the upload limit for the access device. Instead, the current model means you can't make a VoIP call if someone in your household is doing too much BitTorrent (see, http://www.formortals.com/Home/tabid/36/EntryID/57/Default.aspx ), which is obviously an unacceptable situation. Such "remote queue management" shaping would improve everybody's quality of service. And when the ISP determines that a user is using too much bandwidth for any reason, be it user fairness, congestion, queue occupancy, or the capricious whims, should the ISP be completely blind about dropping packets? Or should the ISP, when it can reasonably infer user intent but in the absence of explicit guidance, prioritize traffic based on inferred usage? [4] Finally, I think there is a misunderstanding in the implications of how Comcast is proposing to implement fairness: All they need to do is ensure that the usage of the "default priority" users is significantly less than the total channel capacity, and that whenever "default priority" traffic grows above that fraction, the heaviest default priority users are shifted into the low priority category. As a result, the default priority (the low-bandwidth users) see no congestion and are happily statistically multiplexed, see low latency, and all the good they would expect. As these are the bulk of the users, the ISP is therefore mostly happy. And the "low priority" users will still have bandwidth, and they will still enjoy the current best-effort free-for-all: so if they could make their VoIP 911 call before, they probably still can (assuming the competing traffic is at least SOMEWHAT congestion responsive). And if they couldn't before, its not like the situation was made worse. [5] Its just their best effort free-for-all can no longer step on the low volume users. Yes, it would be a much better world if cable and DSL devices weren't overbuffered, if end-hosts would correctly mark prioritization of packets, if bulk-data P2P used congestion control that was friendly to standard TCP, if ISPs actually provisioned more bandwidth per user, if there were no worms, viruses, spam, spit, etc... But we are living in a grossly impure and imperfect world, and we may have to accept grossly impure and imperfect solutions. [1] And I suspect there is a LOT more of the app-based/usage based manipulation going on than anyone is willing to admit. EG, even relatively benign policies (eg, limit seeding to 2 peers when there is no other activity, blocking leeches in normal mode on BitTorrent. This is a policy which actually helps most/all of the ISP's users at the expense of the rest of the swarm) can get really hostile responses. Such manipulation would be REALLY hard to detect when done using inline shapers rather than out-of-path devices, or even with out-of- path devices which use ACL blocking instead of RST injection. [2] The other way to get much more bandwidth is to either have large government subsidies (which again, would only really help the 5%-10% heavy users, eg the Japanese experience) or to have a situation like Verizon's FiOS, where they are pulling fiber to develop a CableTV competitor. That it gives good Internet performance is in many ways a happy side effect of pulling modern physical media. [3] The further example of it being an image upload is also not well chosen. A single TCP flow will easily adapt and not really interfere with the (no congestion control) VoIP call, even on a relatively narrowly throttled pipe. It is the problem when you have dozens of TCP flows (BitTorrent as used by some individuals), or large non- responsive UDP flows (Joost), or device send buffers which are overly large (which could get filled to frightening-jitter capacities on upload-limited flows). [4] Traffic analysis, rather than DPI, is sufficient. Bulk data P2P is just that: bulk data and P2P. Streaming downloads from Youtube don't look like VoIP calls. Very simple heuristics can distinguish these classes of traffic, and because of their inherent properties, you can't make bulk data P2P look like VoIP. Although some DPI could help: EG, YouTube and other flash-based streaming sources tends to operate in two modes: underbuffered (where the play rate is less then the bandwidth, and the user has to wait) or overbuffered (where the flash app downloads the video much faster than it is able to be watched, and the user may often download most of the video while watching only a little.). Since YouTube does have the ability to seek, it would be of benefit to the user, if shaping needs to occur, if the shaping on a YouTube video was just enough to minimize the amount of overbuffering, as that would match the user's data rate with the consumption rate. The only user penalty would be a greater delay when skipping forward, but the savings would be substantial if streaming video flash apps are unwilling to calibrate their buffering better. [5] This may be a weakness of Comcast's proposal: its not fair ENOUGH. Because it really only allocates into two categories rather than per user ceilings, you might have a case where, eg, a user is doing a single heavy TCP flow, enough to get bumped into the "Low priority" category where it gets stomped on by people doing many-flow transfers. Thus it can preserve behavior for the lighter users, it doesn't necessarily help the heavy users who are using a few connections vs the many connection heavy users. Thus its only a partial fairness rather than per-user fairness. In fact, depending on parameters, you might have thrashing situations where a user with one heavy TCP flow is swapped back and forth between categories as the bandwidth usage goes way down when that one TCP flow has to compete among many flow usage. _______________________________________________ p2pi mailing list p2pi@ietf.org https://www.ietf.org/mailman/listinfo/p2pi From p2pi-bounces@ietf.org Sun Jun 8 08:22:39 2008 Return-Path: X-Original-To: p2pi-archive@ietf.org Delivered-To: ietfarch-p2pi-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CCAF03A6B0F; Sun, 8 Jun 2008 08:22:39 -0700 (PDT) X-Original-To: p2pi@core3.amsl.com Delivered-To: p2pi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 254B23A6B19 for ; Sun, 8 Jun 2008 08:22:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.252 X-Spam-Level: X-Spam-Status: No, score=-0.252 tagged_above=-999 required=5 tests=[AWL=-0.690, BAYES_40=-0.185, 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 wWx8zEKdmCEH for ; Sun, 8 Jun 2008 08:22:36 -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 29A873A6B0F for ; Sun, 8 Jun 2008 08:22:36 -0700 (PDT) Received: by wf-out-1314.google.com with SMTP id 27so1882219wfd.31 for ; Sun, 08 Jun 2008 08:22:52 -0700 (PDT) Received: by 10.142.188.3 with SMTP id l3mr991688wff.174.1212938572259; Sun, 08 Jun 2008 08:22:52 -0700 (PDT) Received: by 10.142.186.7 with HTTP; Sun, 8 Jun 2008 08:22:52 -0700 (PDT) Message-ID: <3efc39a60806080822l575c83c1p2a370bbb20a41bd6@mail.gmail.com> Date: Sun, 8 Jun 2008 10:22:52 -0500 From: "Robb Topolski" To: p2pi@ietf.org In-Reply-To: MIME-Version: 1.0 References: Subject: Re: [p2pi] For those who think "User Fairness/Cost Fairness" is unacceptable... X-BeenThere: p2pi@ietf.org X-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="===============1356129814==" Sender: p2pi-bounces@ietf.org Errors-To: p2pi-bounces@ietf.org --===============1356129814== Content-Type: multipart/alternative; boundary="----=_Part_2479_18039962.1212938572241" ------=_Part_2479_18039962.1212938572241 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline On Sun, Jun 8, 2008 at 3:00 AM, Nicholas Weaver wrote: > Which would you rather have > > a) Usage based pricing/usage caps > b) App manipulation/prioritization/blocking [1] > c) User-based fairness > > It has got to be one of the three as long as 5% of the users use >50% > of the bandwidth Since you hold that position, then why do you overlook these? d) dividing the shared pool of bandwidth by fewer customers so that 5% of the users use >50% of the bandwidth e) increasing the shared pool of bandwidth so that 5% of the users use >50% of the bandwidth f) dividing the shared pool of bandwidth into smaller allocations so that 5% of the users use >50% of the bandwidth g) pricing admission into the shared pool of bandwidth so that the price of the largest allocations encourages users to behave economically > This argument seems to rests on the assumption that limiting a heavy > user to some non-zero fair fraction of a total pipe would disrupt a > VoIP 911 that is concurrent with a user's other activity [3], but at > the same time, insist that the ISP should not take action to limit > other users who disrupt the pipe (which is the current situation where > some users are opening up 1/2 a dozen torrents simultaneously) which > has been shown in practice to disrupt VoIP calls? Perhaps the user has the concurrency problem solved. Let's assume that they've used their VOIP device and and performed background file-transfers at the same time (because some people have, or else these same people wouldn't depend on VOIP). If properly managed, shouldn't the network in the middle allow it to work? I can't write an application to do VOIP with an expectation as vague as "non-zero fair fraction." When looking for investment money, Venture Capitalists walk away when the unknown factors are high and an Internet where the largest Cable-Internet provider in the nation uses terms like "non-zero fair fraction" to describe their network environment makes their hair stand on end. Occasional congestion, the growing pains of the Internet, they might accept. They will not invest, however, if they feel that access providers have *carte blanche* to depart from Internet Standards and perform attacks on the customers most likely to adopt a new bandwidth-using technology. As a result, the default priority (the low-bandwidth users) see no > congestion and are happily statistically multiplexed, see low latency, > and all the good they would expect. As these are the bulk of the > users, the ISP is therefore mostly happy. I can see the ads for it now, "...the *bulk *of our users are *mostly *happy (...but don't ask what the rest of our users say about us.)" Why is the definition of fair that "the *bulk *of our users are *mostly *happy?" These companies provide Internet to *all *of us. Nick, in our current environment, either the incumbant cable or telelephone company is the only real broadband choice. Lucky residents have the ability to choose between them. In such an environment, it's *everyone's*Broadband. The Internet Access provided by these companies cannot attack one fraction of users in service of the remainder. It's different on dial-up, where choice among competitors remains robust. Several of these offer flat-rate, several offer metered, several offer a mix (a flat base amount and metered thereafter). Healthy competition means that some ISPs can *specialize *in things like filtering without disturbing the health of the market. All: I become increasingly frustrated by being the negative guy -- I'm an optimist. I do believe that Comcast made strides toward more transparency. But simply advertising that they interfere with some users does not excuse it (see RFC 1087). When so plainly asked to take a position, the IETF as an engineering body answer Comcast and reject non-Standards conforming behaviors. -- Robb Topolski (robb@funchords.com) Hillsboro, Oregon USA http://www.funchords.com/ ------=_Part_2479_18039962.1212938572241 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline

On Sun, Jun 8, 2008 at 3:00 AM, Nicholas Weaver <nweaver@icsi.berkeley.edu> wrote:
Which would you rather have

a)  Usage based pricing/usage caps
b)  App manipulation/prioritization/blocking [1]
c)  User-based fairness

It has got to be one of the three as long as 5% of the users use >50%
of the bandwidth

Since you hold that position, then why do you overlook these?

d) dividing the shared pool of bandwidth by fewer customers so that 5% of the users use >50% of the bandwidth
e) increasing the shared pool of bandwidth so that 5% of the users use >50% of the bandwidth
f) dividing the shared pool of bandwidth into smaller allocations so that 5% of the users use >50% of the bandwidth
g) pricing admission into the shared pool of bandwidth so that the price of the largest allocations encourages users to behave economically

 
This argument seems to rests on the assumption that limiting a heavy
user to some non-zero fair fraction of a total pipe would disrupt a
VoIP 911 that is concurrent with a user's other activity [3], but at
the same time, insist that the ISP should not take action to limit
other users who disrupt the pipe (which is the current situation where
some users are opening up 1/2 a dozen torrents simultaneously) which
has been shown in practice to disrupt VoIP calls?

Perhaps the user has the concurrency problem solved.  Let's assume that they've used their VOIP device and and performed background file-transfers at the same time (because some people have, or else these same people wouldn't depend on VOIP).  If properly managed, shouldn't the network in the middle allow it to work? 

I can't write an application to do VOIP with an expectation as vague as "non-zero fair fraction." When looking for investment money, Venture Capitalists walk away when the unknown factors are high and an Internet where the largest Cable-Internet provider in the nation uses terms like "non-zero fair fraction" to describe their network environment makes their hair stand on end.

Occasional congestion, the growing pains of the Internet, they might accept.  They will not invest, however, if they feel that access providers have carte blanche to depart from Internet Standards and perform attacks on the customers most likely to adopt a new bandwidth-using technology.


As a result, the default priority (the low-bandwidth users) see no
congestion and are happily statistically multiplexed, see low latency,
and all the good they would expect.  As these are the bulk of the
users, the ISP is therefore mostly happy.

I can see the ads for it now, "...the bulk of our users are mostly happy (...but don't ask what the rest of our users say about us.)" 

Why is the definition of fair that "the bulk of our users are mostly happy?" These companies provide Internet to all of us.

Nick, in our current environment, either the incumbant cable or telelephone company is the only real broadband choice.  Lucky residents have the ability to choose between them.  In such an environment, it's everyone's Broadband.   The Internet Access provided by these companies cannot attack one fraction of users in service of the remainder. 

It's different on dial-up, where choice among competitors remains robust.  Several of these offer flat-rate, several offer metered, several offer a mix (a flat base amount and metered thereafter).  Healthy competition means that some ISPs can specialize in things like filtering without disturbing the health of the market. 

All:  I become increasingly frustrated by being the negative guy -- I'm an optimist.  I do believe that Comcast made strides toward more transparency.  But simply advertising that they interfere with some users does not excuse it (see RFC 1087).  When so plainly asked to take a position, the IETF as an engineering body answer Comcast and reject non-Standards conforming behaviors. 

--
Robb Topolski (robb@funchords.com)
Hillsboro, Oregon USA
http://www.funchords.com/ ------=_Part_2479_18039962.1212938572241-- --===============1356129814== 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 --===============1356129814==-- From p2pi-bounces@ietf.org Sun Jun 8 08:25:27 2008 Return-Path: X-Original-To: p2pi-archive@ietf.org Delivered-To: ietfarch-p2pi-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 537C03A6B45; Sun, 8 Jun 2008 08:25:27 -0700 (PDT) X-Original-To: p2pi@core3.amsl.com Delivered-To: p2pi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8958F3A6B45 for ; Sun, 8 Jun 2008 08:25:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.137 X-Spam-Level: X-Spam-Status: No, score=-0.137 tagged_above=-999 required=5 tests=[AWL=-0.575, BAYES_40=-0.185, 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 Z47ZNohzdWCE for ; Sun, 8 Jun 2008 08:25:25 -0700 (PDT) Received: from wf-out-1314.google.com (wf-out-1314.google.com [209.85.200.172]) by core3.amsl.com (Postfix) with ESMTP id 004F33A6B2C for ; Sun, 8 Jun 2008 08:25:24 -0700 (PDT) Received: by wf-out-1314.google.com with SMTP id 27so1883013wfd.31 for ; Sun, 08 Jun 2008 08:25:40 -0700 (PDT) Received: by 10.142.131.18 with SMTP id e18mr996295wfd.42.1212938740673; Sun, 08 Jun 2008 08:25:40 -0700 (PDT) Received: by 10.142.186.7 with HTTP; Sun, 8 Jun 2008 08:25:40 -0700 (PDT) Message-ID: <3efc39a60806080825yc1261ddmf2ce3da4b308a722@mail.gmail.com> Date: Sun, 8 Jun 2008 10:25:40 -0500 From: "Robb Topolski" To: p2pi@ietf.org In-Reply-To: <3efc39a60806080822l575c83c1p2a370bbb20a41bd6@mail.gmail.com> MIME-Version: 1.0 References: <3efc39a60806080822l575c83c1p2a370bbb20a41bd6@mail.gmail.com> Subject: [p2pi] Fwd: For those who think "User Fairness/Cost Fairness" is unacceptable... X-BeenThere: p2pi@ietf.org X-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="===============1250754129==" Sender: p2pi-bounces@ietf.org Errors-To: p2pi-bounces@ietf.org --===============1250754129== Content-Type: multipart/alternative; boundary="----=_Part_2483_17559270.1212938740645" ------=_Part_2483_17559270.1212938740645 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline ((fix grammar error -- added CANNOT three times below)) On Sun, Jun 8, 2008 at 3:00 AM, Nicholas Weaver wrote: > Which would you rather have > > a) Usage based pricing/usage caps > b) App manipulation/prioritization/blocking [1] > c) User-based fairness > > It has got to be one of the three as long as 5% of the users use >50% > of the bandwidth Since you hold that position, then why do you overlook these? d) dividing the shared pool of bandwidth by fewer customers so that 5% of the users CANNOT use >50% of the bandwidth e) increasing the shared pool of bandwidth so that 5% of the users CANNOT use >50% of the bandwidth f) dividing the shared pool of bandwidth into smaller allocations so that 5% of the users CANNOT use >50% of the bandwidth g) pricing admission into the shared pool of bandwidth so that the price of the largest allocations encourages users to behave economically > This argument seems to rests on the assumption that limiting a heavy > user to some non-zero fair fraction of a total pipe would disrupt a > VoIP 911 that is concurrent with a user's other activity [3], but at > the same time, insist that the ISP should not take action to limit > other users who disrupt the pipe (which is the current situation where > some users are opening up 1/2 a dozen torrents simultaneously) which > has been shown in practice to disrupt VoIP calls? Perhaps the user has the concurrency problem solved. Let's assume that they've used their VOIP device and and performed background file-transfers at the same time (because some people have, or else these same people wouldn't depend on VOIP). If properly managed, shouldn't the network in the middle allow it to work? I can't write an application to do VOIP with an expectation as vague as "non-zero fair fraction." When looking for investment money, Venture Capitalists walk away when the unknown factors are high and an Internet where the largest Cable-Internet provider in the nation uses terms like "non-zero fair fraction" to describe their network environment makes their hair stand on end. Occasional congestion, the growing pains of the Internet, they might accept. They will not invest, however, if they feel that access providers have *carte blanche* to depart from Internet Standards and perform attacks on the customers most likely to adopt a new bandwidth-using technology. As a result, the default priority (the low-bandwidth users) see no > congestion and are happily statistically multiplexed, see low latency, > and all the good they would expect. As these are the bulk of the > users, the ISP is therefore mostly happy. I can see the ads for it now, "...the *bulk *of our users are *mostly *happy (...but don't ask what the rest of our users say about us.)" Why is the definition of fair that "the *bulk *of our users are *mostly *happy?" These companies provide Internet to *all *of us. Nick, in our current environment, either the incumbant cable or telelephone company is the only real broadband choice. Lucky residents have the ability to choose between them. In such an environment, it's *everyone's*Broadband. The Internet Access provided by these companies cannot attack one fraction of users in service of the remainder. It's different on dial-up, where choice among competitors remains robust. Several of these offer flat-rate, several offer metered, several offer a mix (a flat base amount and metered thereafter). Healthy competition means that some ISPs can *specialize *in things like filtering without disturbing the health of the market. All: I become increasingly frustrated by being the negative guy -- I'm an optimist. I do believe that Comcast made strides toward more transparency. But simply advertising that they interfere with some users does not excuse it (see RFC 1087). When so plainly asked to take a position, the IETF as an engineering body answer Comcast and reject non-Standards conforming behaviors. -- Robb Topolski (robb@funchords.com) Hillsboro, Oregon USA http://www.funchords.com/ -- Robb Topolski (robb@funchords.com) Hillsboro, Oregon USA http://www.funchords.com/ ------=_Part_2483_17559270.1212938740645 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline ((fix grammar error -- added CANNOT three times below))


On Sun, Jun 8, 2008 at 3:00 AM, Nicholas Weaver <nweaver@icsi.berkeley.edu> wrote:
Which would you rather have

a)  Usage based pricing/usage caps
b)  App manipulation/prioritization/blocking [1]
c)  User-based fairness

It has got to be one of the three as long as 5% of the users use >50%
of the bandwidth

Since you hold that position, then why do you overlook these?

d) dividing the shared pool of bandwidth by fewer customers so that 5% of the users CANNOT use >50% of the bandwidth
e) increasing the shared pool of bandwidth so that 5% of the users CANNOT use >50% of the bandwidth
f) dividing the shared pool of bandwidth into smaller allocations so that 5% of the users CANNOT use >50% of the bandwidth
g) pricing admission into the shared pool of bandwidth so that the price of the largest allocations encourages users to behave economically

 
This argument seems to rests on the assumption that limiting a heavy
user to some non-zero fair fraction of a total pipe would disrupt a
VoIP 911 that is concurrent with a user's other activity [3], but at
the same time, insist that the ISP should not take action to limit
other users who disrupt the pipe (which is the current situation where
some users are opening up 1/2 a dozen torrents simultaneously) which
has been shown in practice to disrupt VoIP calls?

Perhaps the user has the concurrency problem solved.  Let's assume that they've used their VOIP device and and performed background file-transfers at the same time (because some people have, or else these same people wouldn't depend on VOIP).  If properly managed, shouldn't the network in the middle allow it to work? 

I can't write an application to do VOIP with an expectation as vague as "non-zero fair fraction." When looking for investment money, Venture Capitalists walk away when the unknown factors are high and an Internet where the largest Cable-Internet provider in the nation uses terms like "non-zero fair fraction" to describe their network environment makes their hair stand on end.

Occasional congestion, the growing pains of the Internet, they might accept.  They will not invest, however, if they feel that access providers have carte blanche to depart from Internet Standards and perform attacks on the customers most likely to adopt a new bandwidth-using technology.


As a result, the default priority (the low-bandwidth users) see no
congestion and are happily statistically multiplexed, see low latency,
and all the good they would expect.  As these are the bulk of the
users, the ISP is therefore mostly happy.

I can see the ads for it now, "...the bulk of our users are mostly happy (...but don't ask what the rest of our users say about us.)" 

Why is the definition of fair that "the bulk of our users are mostly happy?" These companies provide Internet to all of us.

Nick, in our current environment, either the incumbant cable or telelephone company is the only real broadband choice.  Lucky residents have the ability to choose between them.  In such an environment, it's everyone's Broadband.   The Internet Access provided by these companies cannot attack one fraction of users in service of the remainder. 

It's different on dial-up, where choice among competitors remains robust.  Several of these offer flat-rate, several offer metered, several offer a mix (a flat base amount and metered thereafter).  Healthy competition means that some ISPs can specialize in things like filtering without disturbing the health of the market. 

All:  I become increasingly frustrated by being the negative guy -- I'm an optimist.  I do believe that Comcast made strides toward more transparency.  But simply advertising that they interfere with some users does not excuse it (see RFC 1087).  When so plainly asked to take a position, the IETF as an engineering body answer Comcast and reject non-Standards conforming behaviors. 

--
Robb Topolski (robb@funchords.com)
Hillsboro, Oregon USA
http://www.funchords.com/



--
Robb Topolski (robb@funchords.com)
Hillsboro, Oregon USA
http://www.funchords.com/ ------=_Part_2483_17559270.1212938740645-- --===============1250754129== 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 --===============1250754129==-- From p2pi-bounces@ietf.org Sun Jun 8 09:16: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 94A6A28C122; Sun, 8 Jun 2008 09:16: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 73C9928C122 for ; Sun, 8 Jun 2008 09:16:40 -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 aAlZHDlc-00q for ; Sun, 8 Jun 2008 09:16:39 -0700 (PDT) Received: from brinza.cc.columbia.edu (brinza.cc.columbia.edu [128.59.29.8]) by core3.amsl.com (Postfix) with ESMTP id 6EA323A6A7E for ; Sun, 8 Jun 2008 09:16:39 -0700 (PDT) Received: from [192.168.0.61] (pool-71-250-59-79.nwrknj.east.verizon.net [71.250.59.79]) (user=hgs10 mech=PLAIN bits=0) by brinza.cc.columbia.edu (8.14.1/8.14.1) with ESMTP id m58GGnWA029030 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT) for ; Sun, 8 Jun 2008 12:16:52 -0400 (EDT) Message-Id: <215A468E-603E-486F-A544-D9CC0AF7C243@cs.columbia.edu> From: Henning Schulzrinne To: p2pi@ietf.org In-Reply-To: Mime-Version: 1.0 (Apple Message framework v924) Date: Sun, 8 Jun 2008 12:16:49 -0400 References: X-Mailer: Apple Mail (2.924) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.63 on 128.59.29.8 Subject: Re: [p2pi] For those who think "User Fairness/Cost Fairness" is unacceptable... X-BeenThere: p2pi@ietf.org X-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 think the problem of the discussion is that several factors are getting conflated. First, there are two very different perspectives, namely that of optimizing the overall public good and the financial health of the ISP. We're not operating in a normal 'intro-to-econ' competitive environment, given that most residential users have essentially no choice in their broadband provider. At the very least, it's a duopoly, switching costs between providers are very high and we have asymmetric information. (The provider knows a lot, customers, being non-technical and not having access to network performance data, are at a disadvantage.) Thus, providers can extract monopoly rents that are only limited by the cost of substitution goods (NetFlix, say) and the ability of customers to pay. This is easily observable in the prices for non-basic cable TV services which have outpaced inflation. Self-interference is a separate problem; I won't discuss it here, as there are relatively easy solutions for that. Also, we tend to conflate two kinds of congestion: temporary "busy hour" congestion, and general capacity limits. Currently, we mostly operate in the former, i.e., the network is only busy during certain hours of the day. In that case, shifting demand to the less-busy hours makes economic sense for everyone. This is similar to load shifting in power generation. Just as in power generation, access network cost is largely driven by peak demand. However, it is likely that peer-to-peer video downloads will fill in the night valley of traffic as well. In that case, congestion control really just means denying service. In other words, I can't get the bits I want. My perception is that average and peak utilization are only about 30-40% apart, i.e., maybe a year or two worth of traffic growth, at best. We tend to treat congestion control as being about fairness. But the bandwidth throttled doesn't just magically go away; unless it is just time-shifted, it means that a user can't get the data they wanted to get or provide. A third, completely separate, problem is that wide area bandwidth is currently a commodity, priced by volume and independent of time of day. Residential ISPs generally will have to pay for that commodity, unless they are also tier-1 providers. From an optimize-the-public-good perspective, there is an unmet need to bandwidth that costs somewhat more than low-volume Internet and less than a fully dedicated line. (The installation costs of a dedicated fiber to the home would be prohibitive for most consumers. T1 is not a reasonable alternative.) Volume charging (probably above a threshold) offers this compromise, making both customers and providers better off compared to the plausible alternatives. Given the absence of effective competition in many geographic areas and the natural monopoly aspect of providing last-mile services, I suspect that we'll need different regulatory models than pretending that we're in a fully-competitive environment, but that's a different discussion. Henning _______________________________________________ p2pi mailing list p2pi@ietf.org https://www.ietf.org/mailman/listinfo/p2pi From p2pi-bounces@ietf.org Sun Jun 8 09:16:55 2008 Return-Path: X-Original-To: p2pi-archive@ietf.org Delivered-To: ietfarch-p2pi-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C093A28C124; Sun, 8 Jun 2008 09:16:55 -0700 (PDT) X-Original-To: p2pi@core3.amsl.com Delivered-To: p2pi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 89AF328C126 for ; Sun, 8 Jun 2008 09:16:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.985 X-Spam-Level: X-Spam-Status: No, score=-4.985 tagged_above=-999 required=5 tests=[AWL=-0.986, BAYES_50=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id paEQYGwgZoYc for ; Sun, 8 Jun 2008 09:16:53 -0700 (PDT) Received: from fruitcake.ICSI.Berkeley.EDU (fruitcake.ICSI.Berkeley.EDU [192.150.186.11]) by core3.amsl.com (Postfix) with ESMTP id 50F3428C11B for ; Sun, 8 Jun 2008 09:16:53 -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 m58GH5TX015479; Sun, 8 Jun 2008 09:17:05 -0700 (PDT) Message-Id: <7DFBDD81-6551-42AD-9E8F-6B3E00EDF254@icsi.berkeley.edu> From: Nicholas Weaver To: "Robb Topolski" In-Reply-To: <3efc39a60806080825yc1261ddmf2ce3da4b308a722@mail.gmail.com> Mime-Version: 1.0 (Apple Message framework v924) Date: Sun, 8 Jun 2008 09:17:05 -0700 References: <3efc39a60806080822l575c83c1p2a370bbb20a41bd6@mail.gmail.com> <3efc39a60806080825yc1261ddmf2ce3da4b308a722@mail.gmail.com> X-Mailer: Apple Mail (2.924) Cc: p2pi@ietf.org, Nicholas Weaver Subject: Re: [p2pi] Fwd: For those who think "User Fairness/Cost Fairness" is unacceptable... X-BeenThere: p2pi@ietf.org X-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 Assuming for the following that, if you eliminated the 5% heavy users, the 95% aren't seening significant congestion... As such. On Jun 8, 2008, at 8:25 AM, Robb Topolski wrote: > > Since you hold that position, then why do you overlook these? > > d) dividing the shared pool of bandwidth by fewer customers so that > 5% of the users CANNOT use >50% of the bandwidth This is overprovisioning which benefits the 5% without benefiting the 95%, which does not have an economic rationalle (see Brisco's writing on the topic for example) in flat-rate pricing. > e) increasing the shared pool of bandwidth so that 5% of the users > CANNOT use >50% of the bandwidth How is E different from D? And E is harder if congestion is in the last mile physical media. And E seems impossible based on the Japanese experience. > f) dividing the shared pool of bandwidth into smaller allocations so > that 5% of the users CANNOT use >50% of the bandwidth This seems to be "abandoninng statistical multiplexing" mixed with "overprovisioning". For the bulk of the users, statistical multiplexing works, and I'd be loath to give it up. > g) pricing admission into the shared pool of bandwidth so that the > price of the largest allocations encourages users to behave > economically Usage based pricing, billed by committed capacity rather than usage. (Of course, the ideal is charge for congestion, but that may be hard to bill and harder to explain) Note, that in usage based pricing, ISP's attitude about P2P do a complete 180: its a huge profit center: because a user's app can keep sucking down and up bandwidth, all through the night (where the cost is less but you charge the same), and with the localization, not suck up access link bandwidth. IT, however, kills the P2P companies business model, as they are now at least 2x, if not 4x, more expensive to users than conventional HTTP- based streaming. > Perhaps the user has the concurrency problem solved. Let's assume > that they've used their VOIP device and and performed background > file-transfers at the same time (because some people have, or else > these same people wouldn't depend on VOIP). If properly managed, > shouldn't the network in the middle allow it to work? > How is isolating the 5% to fight amongst themselves not doing that? If you are managing your background transfers RIGHT (eg, capping your BitTorrent to a reasonably small fraction, and participating in only one or maby two swarms at a time) you aren't part of the problem anyway, and probably wouldn't even get to play in the 5%ers "best effort" playground if the window of fairness is set to some reasonably low time scale (eg, 5-10 minutes). [1] > I can see the ads for it now, "...the bulk of our users are mostly > happy (...but don't ask what the rest of our users say about us.)" > > Why is the definition of fair that "the bulk of our users are mostly > happy?" These companies provide Internet to all of us. Why should the model be "The bulk of the users are unhappy (except for the few heavy users...)"? Why should the 95% of the light users, however, have to pay the congestion penalty from the 5% of the users who AREN'T PAYING ANY MORE! This is a classic externality, and externalities in the network MUST be managed if you want a viable, stable network fabric. Remember, Comcast does NOT claim to do shaping based on protocol beyond the protocol-interference of Sandvine. Yet, strangely enough, the complaints of "Comcast Breaking Vonage" really did go away once they started blocking seeds and leeches (and ONLY seeds and leeches) Because it really takes only one or two idiots with their BitTorrent cranked to full and running on many torrents to ruin your day on a network. We have seen it. > Nick, in our current environment, either the incumbant cable or > telelephone company is the only real broadband choice. Lucky > residents have the ability to choose between them. In such an > environment, it's everyone's Broadband. The Internet Access > provided by these companies cannot attack one fraction of users in > service of the remainder. At the same time, how can it allow a small fraction of users to attack the rest?!? TCP is flow fair [2], it is NOT user fair. UDP based crap like Joost isn't even flow-fair. This is, frankly speaking, "Internet Air Pollution Control": If a user uses many flows rather than one, or large non-flow fair protocols, should the user NOT be shaped to have the same congestion- control behavior as users who are using only one or two TCP flows? I want user fairness specifically BECAUSE it is "everybody's broadband": I don't want my light flows to be stepped on because some neighbor's kid has a dozen Torrents open, because said neighbor's traffic will vastly outcompete my traffic, yet he's not paying a penny more. And this might actually be the ideal definition of fairness: "Methods to ENFORCE the network such that every user's congestion response is equivalent to that of aggregating all their traffic into, at most, four TCP streams under a reasonable queuing discipline". Would you accept this definition? Rather, the service you describe, and the service you desire, the fully committed rate, without shaping and without bias, is perfectly available. It is marketed to businesses and costs real money. For the rest of us, statistical multiplexing buys a huge amount. But if you have statistical multiplexing, you must have a way to resolve congestion, enforced in the network. And end-hosts, through the use of recent protocols, have proven they are not sufficient. BitTorrent, as commonly misused, is hostile to the user's OWN network, let alone everyone else. So how does this not require enforcement by the network? > All: I become increasingly frustrated by being the negative guy -- > I'm an optimist. I do believe that Comcast made strides toward more > transparency. But simply advertising that they interfere with some > users does not excuse it (see RFC 1087). When so plainly asked to > take a position, the IETF as an engineering body answer Comcast and > reject non-Standards conforming behaviors. [1] You are a great demonstration of why the current model, of app- based disruption, shows huge issues and is really evil. But since you are actually tuning your BitTorrent correctly, it wouldn't suprise me if in a fairness-based doctrine you'd actually benefit. Especially under the "TCP flow equivelent" definition. [2] ANd its not even that if you consider the effect of different RTT times. _______________________________________________ p2pi mailing list p2pi@ietf.org https://www.ietf.org/mailman/listinfo/p2pi From p2pi-bounces@ietf.org Sun Jun 8 09:19:01 2008 Return-Path: X-Original-To: p2pi-archive@ietf.org Delivered-To: ietfarch-p2pi-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 80FBE3A6A7E; Sun, 8 Jun 2008 09:19:01 -0700 (PDT) X-Original-To: p2pi@core3.amsl.com Delivered-To: p2pi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 718173A6958 for ; Sun, 8 Jun 2008 09:19:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.195 X-Spam-Level: X-Spam-Status: No, score=-6.195 tagged_above=-999 required=5 tests=[AWL=0.404, 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 Gq-5N2iL+CR7 for ; Sun, 8 Jun 2008 09:18:59 -0700 (PDT) Received: from fruitcake.ICSI.Berkeley.EDU (fruitcake.ICSI.Berkeley.EDU [192.150.186.11]) by core3.amsl.com (Postfix) with ESMTP id 893643A6C05 for ; Sun, 8 Jun 2008 09:18:59 -0700 (PDT) Received: from [IPv6:::1] (fruitcake [192.150.186.11]) by fruitcake.ICSI.Berkeley.EDU (8.12.11.20060614/8.12.11) with ESMTP id m58GJFSx015896; Sun, 8 Jun 2008 09:19:15 -0700 (PDT) Message-Id: <06BEE447-3D17-45D0-A73B-E248C3141F51@ICSI.Berkeley.EDU> From: Nicholas Weaver To: p2pi@ietf.org Mime-Version: 1.0 (Apple Message framework v924) Date: Sun, 8 Jun 2008 09:19:15 -0700 X-Mailer: Apple Mail (2.924) Cc: Nicholas Weaver Subject: [p2pi] One more proposed definition of fairness... X-BeenThere: p2pi@ietf.org X-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 (Buried in a previous mail, but I'd like comments on this separately) How does the following sound as one possible ideal goal for user- fairness: "Mechanisms to enable the network to enforce traffic such that, in the presence of congestion, a user's congestion control response becomes equivalent to aggregating all traffic from that user into a single TCP stream." _______________________________________________ p2pi mailing list p2pi@ietf.org https://www.ietf.org/mailman/listinfo/p2pi From p2pi-bounces@ietf.org Sun Jun 8 10:40: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 4C2503A6898; Sun, 8 Jun 2008 10:40: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 063D53A685B for ; Sun, 8 Jun 2008 10:40:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.539 X-Spam-Level: X-Spam-Status: No, score=-2.539 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5iXaI6-CXHAR for ; Sun, 8 Jun 2008 10:40:08 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by core3.amsl.com (Postfix) with ESMTP id 46C6E3A6898 for ; Sun, 8 Jun 2008 10:40:08 -0700 (PDT) Received: from [127.0.0.1] (pool-71-106-109-69.lsanca.dsl-w.verizon.net [71.106.109.69]) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id m58HdqT0001225 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sun, 8 Jun 2008 10:39:54 -0700 (PDT) Message-ID: <484C1958.2010900@isi.edu> Date: Sun, 08 Jun 2008 10:39:36 -0700 From: Joe Touch User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: Nicholas Weaver References: <06BEE447-3D17-45D0-A73B-E248C3141F51@ICSI.Berkeley.EDU> In-Reply-To: <06BEE447-3D17-45D0-A73B-E248C3141F51@ICSI.Berkeley.EDU> X-Enigmail-Version: 0.95.6 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: p2pi@ietf.org Subject: Re: [p2pi] One more proposed definition of fairness... X-BeenThere: p2pi@ietf.org X-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="===============0058260609==" Sender: p2pi-bounces@ietf.org Errors-To: p2pi-bounces@ietf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============0058260609== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig5545B0EF2070C81C770E47D1" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig5545B0EF2070C81C770E47D1 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Nicholas Weaver wrote: > (Buried in a previous mail, but I'd like comments on this separately) >=20 >=20 > How does the following sound as one possible ideal goal for user-=20 > fairness: >=20 > "Mechanisms to enable the network to enforce traffic such that, in the = =20 > presence of congestion, a user's congestion control response becomes =20 > equivalent to aggregating all traffic from that user into a single TCP = =20 > stream." See the Congestion Manager or RFC2140 ;-) This is easy to do at the end system, but, AFAICT, impossible to=20 accomplish anywhere else (users will just grab multiple IP addresses,=20 e.g.) - or worse, involves violating TCP (or, equivalently, won't work=20 on encrypted/authenticated streams). Joe --------------enig5545B0EF2070C81C770E47D1 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFITBlnE5f5cImnZrsRAoRzAJ0W514e2Twj4uxK/Ee8IIZplMuUCACglw98 L4p38aLxB/IZKn0wiBeTS5s= =LSOq -----END PGP SIGNATURE----- --------------enig5545B0EF2070C81C770E47D1-- --===============0058260609== 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 --===============0058260609==-- From p2pi-bounces@ietf.org Sun Jun 8 11:28: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 AC5263A6A8B; Sun, 8 Jun 2008 11:28: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 0B1393A6911 for ; Sun, 8 Jun 2008 11:28:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.495 X-Spam-Level: X-Spam-Status: No, score=-0.495 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3elOjSMsM+IS for ; Sun, 8 Jun 2008 11:28:08 -0700 (PDT) Received: from gw.sandvine.com (unknown [199.243.201.138]) by core3.amsl.com (Postfix) with ESMTP id 065633A6AE5 for ; Sun, 8 Jun 2008 11:28:07 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Sun, 8 Jun 2008 14:28:22 -0400 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: ietf mandate ... Thread-Index: AcjJPcFPZHhrtek+QSeBfukW3GULQQAVUPzQ References: From: "Don Bowman" To: Subject: [p2pi] ietf mandate ... X-BeenThere: p2pi@ietf.org X-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 of the questions we left unanswered was what, if anything, the ietf should do to be involved. Since the ietf is a technical standards body, rather than a political or legal, that contrains the area 'somewhat' :) personally I have a real problem with the idea of 'flow destination selection signalled from the network for times of congestion or locations of cost', I think that it will be very hard, these things change dynamically (mobile ip, load, network failovers, ospf changes, ...). Thus I am not a fan of trying to build the 'best cost path' approach (despite having designed and deployed Product at large scale that did this)... although its pragmatic For certain classes of network, its not a generic solution. I really like the idea of a true scavenger class. It would hugely incent ISP's and operate in the best interest of the users of the network. People could have a 'quota' that they purchased as part of their plan, and choose to spend their credits on each packet according to its delivery guarantees. Any packet they didn't wish to 'pay for' would go in scavenger. The implementation of a true end-to-end scavenger class is quite hard, when placed into network designs that have properties like: * L2 (ATM, MPLS, ...) that don't look @ DSCP mark * overlay networks that priortise the overlay rather than the Packets within * access equipment that doesn't look @ packet priority * dynamic bandwidth access networks such as WiMax, 3GPP So this is an area a standard's body could invest additional (I'm aware of the considerable efforts thus far) effort. Another idea which might have merit is the use of 'anycast' With ipv6 it would be economic to assign an ipv6 anycast IP to each unique piece of content, and on a packet-by Packet basis (e.g. SCTP? UDP?) obtain it from the 'closest' location, even as you or the destination moved around a mobile ip Network. I realise this is a proposed implementation, but Maybe forget the method... I think TCP is just the incorrect transport to get content from many locations that offer the same thing, when the transfer might be long in duration and high in cost. For this to work, a fairly dynamic directory service (think DDNS w/ huge update rates) would be pretty cool. Its kind of similar to the problem of allocating a new Multicast group address, world-wide. The 'anycast' addressing scheme would lend itself well to access ISP who had a higher cost of upstream than downstream (e.g. WiMax, Cable, 3G), or ones which had a higher cost of transit than access (e.g. island nations) as they could more easily deploy caching. So maybe a standard which allowed: * allocation of 'l3 address' <-> content * scavenger-aware connectionless, guaranteed transport to dynamic l3 endpoints Would be pretty cool. It would align a lot of 'non-technical' interests too. The issue of user-to-user fairness w/in the scavenger class would be left to the ISP to enforce in some fashion, either economically or technically or not at all. _______________________________________________ p2pi mailing list p2pi@ietf.org https://www.ietf.org/mailman/listinfo/p2pi From p2pi-bounces@ietf.org Sun Jun 8 12:18:36 2008 Return-Path: X-Original-To: p2pi-archive@ietf.org Delivered-To: ietfarch-p2pi-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A57F03A6BE4; Sun, 8 Jun 2008 12:18:36 -0700 (PDT) X-Original-To: p2pi@core3.amsl.com Delivered-To: p2pi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 19A8428C130 for ; Sun, 8 Jun 2008 12:18:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.229 X-Spam-Level: X-Spam-Status: No, score=-6.229 tagged_above=-999 required=5 tests=[AWL=0.370, 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 e5ggeJFfhNQj for ; Sun, 8 Jun 2008 12:18:35 -0700 (PDT) Received: from fruitcake.ICSI.Berkeley.EDU (fruitcake.ICSI.Berkeley.EDU [192.150.186.11]) by core3.amsl.com (Postfix) with ESMTP id 1E6843A6B25 for ; Sun, 8 Jun 2008 12:18:35 -0700 (PDT) Received: from [IPv6:::1] (fruitcake [192.150.186.11]) by fruitcake.ICSI.Berkeley.EDU (8.12.11.20060614/8.12.11) with ESMTP id m58JIo1l020950; Sun, 8 Jun 2008 12:18:50 -0700 (PDT) Message-Id: <8719C03C-9EC9-482B-9536-1784F95DC8A8@ICSI.Berkeley.EDU> From: Nicholas Weaver To: Joe Touch , p2pi@ietf.org In-Reply-To: <484C1958.2010900@isi.edu> Mime-Version: 1.0 (Apple Message framework v924) Date: Sun, 8 Jun 2008 12:18:50 -0700 References: <06BEE447-3D17-45D0-A73B-E248C3141F51@ICSI.Berkeley.EDU> <484C1958.2010900@isi.edu> X-Mailer: Apple Mail (2.924) Cc: Nicholas Weaver Subject: Re: [p2pi] One more proposed definition of fairness... X-BeenThere: p2pi@ietf.org X-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 Jun 8, 2008, at 10:39 AM, Joe Touch wrote: > Nicholas Weaver wrote: >> (Buried in a previous mail, but I'd like comments on this separately) >> How does the following sound as one possible ideal goal for user- >> fairness: >> "Mechanisms to enable the network to enforce traffic such that, in >> the presence of congestion, a user's congestion control response >> becomes equivalent to aggregating all traffic from that user into >> a single TCP stream." > > See the Congestion Manager or RFC2140 ;-) > > This is easy to do at the end system, but, AFAICT, impossible to > accomplish anywhere else (users will just grab multiple IP > addresses, e.g.) - or worse, involves violating TCP (or, > equivalently, won't work on encrypted/authenticated streams). I'm a security person. I have to assume the end systems don't behave right. But I actually don't think it is impossible to enforce in the network for the local users' ISP. EG, the ISP can at a single bidirectional point in the network (admittedly keeping lots of state, but...) for a large group of users infer the congestion on each TCP flow, and correlate across multiple flows on multiple users to see a) There is common congestion affecting a large group of flows b) What the available bottleneck bandwidth for the common point of congestion and then c) ECN mark/drop packets from the user's flows at the common point of congestion, so that when a user has multiple TCP flows they experience the same throughput they would if they just had one TCP flow. Yes, this is a LOT of engineering work to get right [1], but I believe it is doable, and could accomplish the stated definition of fairness (or something very close to it). Furthermore, you can resist the attacks you mentioned. Because the ISP can prevent the user from minting new IP addresses (as they control the point of attachment), this prevents address forging. And because the ISP is forcing the flows to drop packets remote of the point of congestion to maintain the target flow, if the end host is doing ANY congestion control at all, it will be forced to conform to the allocated fair share. [2] It was also pointed out to me that http://www.anagran.com/ actually claims to be targeting this ability, or something similar, managing congestion that is remote from the point of management, although their web site literature is pretty shy on information on how they are doing it. [1] note, however, it doesn't have to be perfect: sampling and other approximations can allow you to bound state at the cost of complete accuracy. And it only has to work at 1 Gbps to be deployable in many networks today (well within the range of a commodity PC) and there is enough available parallelism that you could probably implement at 10 Gbps on a Tilera-based system or other highly parallel programmable system. [2] And even completely unresponsive flows can be shaped as long as the actual bottleneck is downstream of the point of management and, if upstream, this could easily be considered an attack on the network and an ACL block would probably be appropriate. _______________________________________________ p2pi mailing list p2pi@ietf.org https://www.ietf.org/mailman/listinfo/p2pi From p2pi-bounces@ietf.org Sun Jun 8 14:10:08 2008 Return-Path: X-Original-To: p2pi-archive@ietf.org Delivered-To: ietfarch-p2pi-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 900083A68DF; Sun, 8 Jun 2008 14:10:08 -0700 (PDT) X-Original-To: p2pi@core3.amsl.com Delivered-To: p2pi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2B95E3A68DF for ; Sun, 8 Jun 2008 14:10:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.262 X-Spam-Level: X-Spam-Status: No, score=-1.262 tagged_above=-999 required=5 tests=[AWL=0.714, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RjJIl7V07Izv for ; Sun, 8 Jun 2008 14:10:06 -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 ED8D13A6890 for ; Sun, 8 Jun 2008 14:10:05 -0700 (PDT) Received: by wf-out-1314.google.com with SMTP id 27so1977191wfd.31 for ; Sun, 08 Jun 2008 14:10:20 -0700 (PDT) Received: by 10.142.89.13 with SMTP id m13mr1089746wfb.338.1212959420787; Sun, 08 Jun 2008 14:10:20 -0700 (PDT) Received: by 10.142.186.7 with HTTP; Sun, 8 Jun 2008 14:10:20 -0700 (PDT) Message-ID: <3efc39a60806081410i340fc5c2mf27da8eefebbc0cf@mail.gmail.com> Date: Sun, 8 Jun 2008 16:10:20 -0500 From: "Robb Topolski" To: "Don Bowman" In-Reply-To: MIME-Version: 1.0 References: Cc: p2pi@ietf.org Subject: Re: [p2pi] ietf mandate ... X-BeenThere: p2pi@ietf.org X-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="===============1900446295==" Sender: p2pi-bounces@ietf.org Errors-To: p2pi-bounces@ietf.org --===============1900446295== Content-Type: multipart/alternative; boundary="----=_Part_3246_14060759.1212959420750" ------=_Part_3246_14060759.1212959420750 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline On Sun, Jun 8, 2008 at 1:28 PM, Don Bowman wrote: > personally I have a real problem with the idea of 'flow destination > selection signalled from the network for times of congestion > or locations of cost', I think that it will be very hard, these > things change dynamically (mobile ip, load, network failovers, > ospf changes, ...). Thus I am not a fan of trying to build the > 'best cost path' approach (despite having designed and deployed > Product at large scale that did this)... although its pragmatic > For certain classes of network, its not a generic solution. Don, Although your suggestion comes with so many asterisks and concerns that I don't quite know what to make of it all, *I like the gist of it*. (If congestion control really needs to be fixed, that is, which I am trending toward the doubful side as events unfold.) However, thinking about your suggestion, I have this question: Can you help me understand it by contrasting it to (my understanding, at least, of) DSCP / DiffServ? Instead of a scavenger class, why couldn't "best-effort" or undesignated traffic *be *the scavenger class traffic, and allow consumers to designate some relatively tiny amount (either by monthly allocation or daily percentage or whatever) for Expedited Forwarding. (The EF quota would be an amount definitely enough to make VOIP and head-to-head games work -- since that's the practical example that we have today -- but the choice of what to prioritize is the users' and not the ISP's purview.) This idea could be built upon further with a second larger quota with some "average" amount for a better-than-default Assured Forwarding class. We could think of this as an "very interactive class" or perhaps a "live streaming" class. What's left is "best-effort." Users (through their applications) could identify which packets are which. To prevent abuse, the network should ignore the markings if the user is above their quota for that DSCP. An opt-in DPI device at the carrier could help consumers get on board without further configuration. It would feature a one-size-fits-most preset that applies for most users. Otherwise, consumers could enable or upgrade their applications and equipment to enable packet marking to fit their own desires. -- Robb Topolski (robb@funchords.com) Hillsboro, Oregon USA http://www.funchords.com/ ------=_Part_3246_14060759.1212959420750 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline

On Sun, Jun 8, 2008 at 1:28 PM, Don Bowman <don@sandvine.com> wrote:
personally I have a real problem with the idea of 'flow destination
selection signalled from the network for times of congestion
or locations of cost', I think that it will be very hard, these
things change dynamically (mobile ip, load, network failovers,
ospf changes, ...). Thus I am not a fan of trying to build the
'best cost path' approach (despite having designed and deployed
Product at large scale that did this)... although its pragmatic
For certain classes of network, its not a generic solution.

Don,

Although your suggestion comes with so many asterisks and concerns that I don't quite know what to make of it all, I like the gist of it.  (If congestion control really needs to be fixed, that is, which I am trending toward the doubful side as events unfold.)

However, thinking about your suggestion, I have this question:  Can you help me understand it by contrasting it to (my understanding, at least, of) DSCP / DiffServ?

Instead of a scavenger class, why couldn't "best-effort" or undesignated traffic be the scavenger class traffic, and allow consumers to designate some relatively tiny amount (either by monthly allocation or daily percentage or whatever) for Expedited Forwarding.  (The EF quota would be an amount definitely enough to make VOIP and head-to-head games work -- since that's the practical example that we have today -- but the choice of what to prioritize is the users' and not the ISP's purview.) 

This idea could be built upon further with a second larger quota with some "average" amount for a better-than-default Assured Forwarding class.  We could think of this as an "very interactive class" or perhaps a "live streaming" class.   What's left is "best-effort."

Users (through their applications) could identify which packets are which.  To prevent abuse, the network should ignore the markings if the user is above their quota for that DSCP. 

An opt-in DPI device at the carrier could help consumers get on board without further configuration.  It would feature a one-size-fits-most preset that applies for most users. Otherwise, consumers could enable or upgrade their applications and equipment to enable packet marking to fit their own desires.

--
Robb Topolski (robb@funchords.com)
Hillsboro, Oregon USA
http://www.funchords.com/ ------=_Part_3246_14060759.1212959420750-- --===============1900446295== 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 --===============1900446295==-- From p2pi-bounces@ietf.org Sun Jun 8 14:29: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 779C33A6912; Sun, 8 Jun 2008 14:29: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 0E84A3A6912 for ; Sun, 8 Jun 2008 14:29:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.351 X-Spam-Level: X-Spam-Status: No, score=-1.351 tagged_above=-999 required=5 tests=[AWL=0.625, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MMa0DzFCpbh4 for ; Sun, 8 Jun 2008 14:29:41 -0700 (PDT) Received: from wf-out-1314.google.com (wf-out-1314.google.com [209.85.200.171]) by core3.amsl.com (Postfix) with ESMTP id 2705B3A67E7 for ; Sun, 8 Jun 2008 14:29:41 -0700 (PDT) Received: by wf-out-1314.google.com with SMTP id 27so1982510wfd.31 for ; Sun, 08 Jun 2008 14:29:58 -0700 (PDT) Received: by 10.142.133.8 with SMTP id g8mr1095866wfd.312.1212960597910; Sun, 08 Jun 2008 14:29:57 -0700 (PDT) Received: by 10.142.186.7 with HTTP; Sun, 8 Jun 2008 14:29:57 -0700 (PDT) Message-ID: <3efc39a60806081429k3a2d2df7u861b400e9188850e@mail.gmail.com> Date: Sun, 8 Jun 2008 16:29:57 -0500 From: "Robb Topolski" To: "Henning Schulzrinne" In-Reply-To: <215A468E-603E-486F-A544-D9CC0AF7C243@cs.columbia.edu> MIME-Version: 1.0 References: <215A468E-603E-486F-A544-D9CC0AF7C243@cs.columbia.edu> Cc: p2pi@ietf.org Subject: Re: [p2pi] For those who think "User Fairness/Cost Fairness" is unacceptable... X-BeenThere: p2pi@ietf.org X-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="===============0329288132==" Sender: p2pi-bounces@ietf.org Errors-To: p2pi-bounces@ietf.org --===============0329288132== Content-Type: multipart/alternative; boundary="----=_Part_3259_22048681.1212960597899" ------=_Part_3259_22048681.1212960597899 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Henning, now THAT was excellent. Great summation! I'm with you up to this point: From an optimize-the-public-good perspective, there is an unmet need > to bandwidth that costs somewhat more than low-volume Internet and > less than a fully dedicated line. > > And on that point, I only can say "I'm not sure." There certainly is an unmet demand, but I'm not sure if it rises to the status of unmet need. And perhaps these are Economics 101 terms that I do not fully understand. When I was gigging, I could spend every weekend doing birthday and anniversary parties for free. We weren't that good, but we decided to charge a small fee. When the price of getting four performers tuxedoed across town for an hour became $50-$100, things quickly struck a happy balance. In that case, it wasn't that there was an unmet need for barbershop quartet singers, it was more true that "free" was a very good price. In your opinion, or perhaps in the Econ. vernacular, is that an "unmet need" or something less? And is it important IETF business either way? -- Robb Topolski (robb@funchords.com) Hillsboro, Oregon USA http://www.funchords.com/ ------=_Part_3259_22048681.1212960597899 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Henning, now THAT was excellent.  Great summation!

I'm with you up to this point:

 From an optimize-the-public-good perspective, there is an unmet need
to bandwidth that costs somewhat more than low-volume Internet and
less than a fully dedicated line.


And on that point, I only can say "I'm not sure."  There certainly is an unmet demand, but I'm not sure if it rises to the status of unmet need.  And perhaps these are Economics 101 terms that I do not fully understand. 

When I was gigging, I could spend every weekend doing birthday and anniversary parties for free. We weren't that good, but we decided to charge a small fee.  When the price of getting four performers tuxedoed across town for an hour became $50-$100, things quickly struck a happy balance.  In that case, it wasn't that there was an unmet need for barbershop quartet singers, it was more true that "free" was a very good price.

In your opinion, or perhaps in the Econ. vernacular, is that an "unmet need" or something less?   And is it important IETF business either way?

--
Robb Topolski (robb@funchords.com)
Hillsboro, Oregon USA
http://www.funchords.com/ ------=_Part_3259_22048681.1212960597899-- --===============0329288132== 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 --===============0329288132==-- From p2pi-bounces@ietf.org Sun Jun 8 14:48: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 D8E963A69CD; Sun, 8 Jun 2008 14:48:23 -0700 (PDT) X-Original-To: p2pi@core3.amsl.com Delivered-To: p2pi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8B09C3A6964 for ; Sun, 8 Jun 2008 14:48:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.421 X-Spam-Level: X-Spam-Status: No, score=-1.421 tagged_above=-999 required=5 tests=[AWL=0.555, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HIkOErPAzjZ8 for ; Sun, 8 Jun 2008 14:48:21 -0700 (PDT) Received: from wf-out-1314.google.com (wf-out-1314.google.com [209.85.200.171]) by core3.amsl.com (Postfix) with ESMTP id 9070C3A68C5 for ; Sun, 8 Jun 2008 14:48:21 -0700 (PDT) Received: by wf-out-1314.google.com with SMTP id 27so1987546wfd.31 for ; Sun, 08 Jun 2008 14:48:38 -0700 (PDT) Received: by 10.143.3.4 with SMTP id f4mr1111711wfi.233.1212961718436; Sun, 08 Jun 2008 14:48:38 -0700 (PDT) Received: by 10.142.186.7 with HTTP; Sun, 8 Jun 2008 14:48:38 -0700 (PDT) Message-ID: <3efc39a60806081448x7499519brbef093888d7ee29d@mail.gmail.com> Date: Sun, 8 Jun 2008 16:48:38 -0500 From: "Robb Topolski" To: "Nicholas Weaver" In-Reply-To: <7DFBDD81-6551-42AD-9E8F-6B3E00EDF254@icsi.berkeley.edu> MIME-Version: 1.0 References: <3efc39a60806080822l575c83c1p2a370bbb20a41bd6@mail.gmail.com> <3efc39a60806080825yc1261ddmf2ce3da4b308a722@mail.gmail.com> <7DFBDD81-6551-42AD-9E8F-6B3E00EDF254@icsi.berkeley.edu> Cc: p2pi@ietf.org Subject: Re: [p2pi] Fwd: For those who think "User Fairness/Cost Fairness" is unacceptable... X-BeenThere: p2pi@ietf.org X-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="===============0285121698==" Sender: p2pi-bounces@ietf.org Errors-To: p2pi-bounces@ietf.org --===============0285121698== Content-Type: multipart/alternative; boundary="----=_Part_3291_8245084.1212961718440" ------=_Part_3291_8245084.1212961718440 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline On Sun, Jun 8, 2008 at 11:17 AM, Nicholas Weaver wrote: > > Assuming for the following that, if you eliminated the 5% heavy users, the > 95% aren't seening significant congestion... > Nick, you obviously are investing a lot of time in writing responses to me. To be honest, I'm only skimming the first few lines at this point. The only way to win "The Lifeboat Game" is to assume that your particular values are better than anyone elses values. And, odds are, you're right. However, you are also probably in the minority of lifeboat passengers who hold that opinion. So while you're busy deciding who its okay to throw overboard, know that *I'm stubbornly going to remain convinced that a person who has paid their bill, who has not hacked their modem, who is using applications who have not behaved nefariously, and who is acting within the law has every right to the next bit of bandwidth as I do. *I also believe that truly abusive users should not be handled through probability guesses enabled by packet inspection and throttling, but with evidence, due process, and the entire termination of their service. I deeply respect this body and will not continue repeating myself. I want to contribute technically, and this has become less than a technical conversation. --Robb ------=_Part_3291_8245084.1212961718440 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline On Sun, Jun 8, 2008 at 11:17 AM, Nicholas Weaver <nweaver@icsi.berkeley.edu> wrote:

Assuming for the following that, if you eliminated the 5% heavy users, the 95% aren't seening significant congestion...

Nick, you obviously are investing a lot of time in writing responses to me.  To be honest, I'm only skimming the first few lines at this point.  

The only way to win "The Lifeboat Game" is to assume that your particular values are better than anyone elses values.  And, odds are, you're right.  However, you are also probably in the minority of lifeboat passengers who hold that opinion. 

So while you're busy deciding who its okay to throw overboard, know that I'm stubbornly going to remain convinced that a person who has paid their bill, who has not hacked their modem, who is using applications who have not behaved nefariously, and who is acting within the law has every right to the next bit of bandwidth as I do.  I also believe that truly abusive users should not be handled through probability guesses enabled by packet inspection and throttling, but with evidence, due process, and the entire termination of their service.

I deeply respect this body and will not continue repeating myself.  I want to contribute technically, and this has become less than a technical conversation.

--Robb
------=_Part_3291_8245084.1212961718440-- --===============0285121698== 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 --===============0285121698==-- From p2pi-bounces@ietf.org Sun Jun 8 15:34: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 315213A6A24; Sun, 8 Jun 2008 15:34: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 7B2A93A6883 for ; Sun, 8 Jun 2008 15:34:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.855 X-Spam-Level: X-Spam-Status: No, score=-2.855 tagged_above=-999 required=5 tests=[AWL=-0.745, BAYES_05=-1.11, 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 xXli-Cqv2PPF for ; Sun, 8 Jun 2008 15:34:32 -0700 (PDT) Received: from serrano.cc.columbia.edu (serrano.cc.columbia.edu [128.59.29.6]) by core3.amsl.com (Postfix) with ESMTP id 43A2C3A6844 for ; Sun, 8 Jun 2008 15:34:32 -0700 (PDT) Received: from [192.168.0.61] (pool-71-250-59-79.nwrknj.east.verizon.net [71.250.59.79]) (user=hgs10 mech=PLAIN bits=0) by serrano.cc.columbia.edu (8.14.1/8.14.1) with ESMTP id m58MYfdk023185 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Sun, 8 Jun 2008 18:34:47 -0400 (EDT) Message-Id: From: Henning Schulzrinne To: Robb Topolski In-Reply-To: <3efc39a60806081429k3a2d2df7u861b400e9188850e@mail.gmail.com> Mime-Version: 1.0 (Apple Message framework v924) Date: Sun, 8 Jun 2008 18:34:41 -0400 References: <215A468E-603E-486F-A544-D9CC0AF7C243@cs.columbia.edu> <3efc39a60806081429k3a2d2df7u861b400e9188850e@mail.gmail.com> X-Mailer: Apple Mail (2.924) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.63 on 128.59.29.6 Cc: p2pi@ietf.org Subject: Re: [p2pi] For those who think "User Fairness/Cost Fairness" is unacceptable... X-BeenThere: p2pi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: P2P Infrastructure Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: p2pi-bounces@ietf.org Errors-To: p2pi-bounces@ietf.org This is straying somewhat outside the technical, but, as I've said before, this is largely an economics problem. For simplicity, let's assume for a moment that Internet access was a regulated monopoly as opposed to an unregulated monopoly, as it is now, or a classical competitive market. A fictitious public utility commission or competitive business now has three choices, given the mix of users of today (95% "light", 5% "heavy"): (1) Light users and heavy users pay the same, but light users pay more than they would without the heavy users, since the network capacity has to be much larger. (2) Heavy users are kicked off the network. They now have a choice: run their own fiber or only get service below what they are interested in. They are lost as customers to the provider and the cost of the own fiber is prohibitive, so nobody earns any extra money (but the provider and 95% of the customers save some money; the division of the spoils between the two is a matter of market power or choices made by the regulator). (3) Heavy users are charged more, but significantly less than it would cost to lay a separate fiber. Assuming that heavy users value the service sufficiently to pay the extra charge, everybody gains: the provider gets additional revenue with modest additional infrastructure investment, the light user doesn't subsidize the heavy user and the heavy user gets extra bandwidth. There is one core economics assumption here: The heavy user actually values bandwidth more than the incremental charge. (This is the classical problem in discussions of pirating: Many users would forego the movie rather than pay full fare. It could well be that heavy users don't value the extra bandwidth they use at what it costs to provide it, but that's just a version of "there is no free lunch".) This is under the assumption that separating or charging heavy users is feasible and worthwhile. At an "all you can eat" buffet, finite stomach capacity and the prohibition against doggy-bagging make counting trips to the salad bar not worth the hassle. With high-speed Internet access, the consumption ratio between light and heavy users is much larger than for other "flat-rate" services. Measuring isn't much of an issue, but the fear of $1000 bill surprises might be. In an unregulated monopoly, the calculations are different since the provider can potentially practice perfect market segmentation and capture all the surplus. That's a discussion for a different day. Henning On Jun 8, 2008, at 5:29 PM, Robb Topolski wrote: > > And on that point, I only can say "I'm not sure." There certainly > is an unmet demand, but I'm not sure if it rises to the status of > unmet need. And perhaps these are Economics 101 terms that I do not > fully understand. > > When I was gigging, I could spend every weekend doing birthday and > anniversary parties for free. We weren't that good, but we decided > to charge a small fee. When the price of getting four performers > tuxedoed across town for an hour became $50-$100, things quickly > struck a happy balance. In that case, it wasn't that there was an > unmet need for barbershop quartet singers, it was more true that > "free" was a very good price. > > In your opinion, or perhaps in the Econ. vernacular, is that an > "unmet need" or something less? And is it important IETF business > either way? > > -- > Robb Topolski (robb@funchords.com) > Hillsboro, Oregon USA > http://www.funchords.com/ _______________________________________________ p2pi mailing list p2pi@ietf.org https://www.ietf.org/mailman/listinfo/p2pi From p2pi-bounces@ietf.org Sun Jun 8 15:44:56 2008 Return-Path: X-Original-To: p2pi-archive@ietf.org Delivered-To: ietfarch-p2pi-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 90B2D3A6A92; Sun, 8 Jun 2008 15:44: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 8D5A23A6A92 for ; Sun, 8 Jun 2008 15:44:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.547 X-Spam-Level: X-Spam-Status: No, score=-1.547 tagged_above=-999 required=5 tests=[AWL=1.052, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3Zgcl8yZrVbk for ; Sun, 8 Jun 2008 15:44:53 -0700 (PDT) Received: from gw.sandvine.com (gw.sandvine.com [199.243.201.138]) by core3.amsl.com (Postfix) with ESMTP id CFBE03A6A2B for ; Sun, 8 Jun 2008 15:44:52 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Sun, 8 Jun 2008 18:45:07 -0400 Message-ID: In-Reply-To: <3efc39a60806081410i340fc5c2mf27da8eefebbc0cf@mail.gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [p2pi] ietf mandate ... Thread-Index: AcjJrBgIJk04GsKfRGObkZDPfObPagACOJrA References: <3efc39a60806081410i340fc5c2mf27da8eefebbc0cf@mail.gmail.com> From: "Don Bowman" To: "Robb Topolski" Cc: p2pi@ietf.org Subject: Re: [p2pi] ietf mandate ... X-BeenThere: p2pi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: P2P Infrastructure Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: p2pi-bounces@ietf.org Errors-To: p2pi-bounces@ietf.org From: Robb Topolski [mailto:robb@funchords.com] = Sent: 2008-06-08 17:10 >Don, = >Although your suggestion comes with so many asterisks and = >concerns that I don't quite know what to make of it all, = >I like the gist of it.=A0 (If congestion control really needs = >to be fixed, that is, which I am trending toward the doubful = >side as events unfold.) >However, thinking about your suggestion, I have this question:=A0 >Can you help me understand it by contrasting it to (my = >understanding, at least, of) DSCP / DiffServ? >Instead of a scavenger class, why couldn't "best-effort" or = >undesignated traffic be the scavenger class traffic, and = >allow consumers to designate some relatively tiny amount = >(either by monthly allocation or daily percentage or = >whatever) for Expedited Forwarding.=A0 (The EF quota would be = >an amount definitely enough to make VOIP and head-to-head = >games work -- since that's the practical example that we = >have today -- but the choice of what to prioritize is the users' = >and not the ISP's purview.)=A0 = BTW, I think I'm also proposing the same thing: a user-to-user enforced 'fairness' in the network, and then you set the priority on your packets within that 'envelope'. My suggestion is not exclusive of DSCP. However, scavenger / = Congestion is more than just drop. Consider that I use UDP for all my traffic, and I transmit @ a constant 10Mbps rate. I go through 3 successive choke points in the network, 1 in my home @ 6Mbps, 1 in the = access network @ 4Mbps, and 1 in the core network @ 2Mbps. In the DSCP - only model, I will have 40% dropped in my modem, another 20% dropped in the access, and another 20% dropped in the core, constantly. The 20% dropped in the core still leaves 20% of access BW consumed that helped no one: not me, not the destination. DSCP would have simply tried to drop my packets with a higher priority than some others, but I would still have fought against others of the same priority (and others of higher priority). In a perfect world, this 2Mbps minimum rate would have been instantly known by the sender, who would have xmit no more than 2Mbps. So clearly DSCP alone is not sufficient to create a 'scavenger class'. Now, consider the same as above w/ TCP. Various TCP implementations balance the bandwidth-latency product differently, slow start, nagle, delayed-ack, reno, vegas, window sizes, sack, lots of algorithms that try to make it robust, good throughput, etc. So one option is to simply set the DSCP on TCP and see what happens, those end-to-end bandwidth factors get keyed in somehow. Some access technologies have control systems (e.g. WiMax) which may fight with this, they dynamically increase your bandwidth. Some network topologies carry those DSCP - encoded packets over a type of link that ignores them. DSL does this (typically). The link from your home to a DSLAM is yours alone. But the link from your DSLAM to your BRAS is shared, and is typically a L2 tunnel on ATM. This is where the oversubscription occurs, and there is no use of DSCP. In fact, its practically a guarantee that somewhere between Your house and your destination you travel over at least one tunnel. If the tunnel is but one hop, the right thing might still happen as the label-edge-router will use the DSCP to decide which packets to route into the tunnel, and which to drop. But I suspect a single-hop tunnel is not so common. Similarly in a wireless network, 3GPP(2) use a proportional-fair algorithm to try and maximise the useful BW of the network. They have the challenge that as you walk further into a building, your data rate goes down. As the sky gets cloudy, buildings go up, you get in a train, etc... a very dynamic environment. And, the highest cost part of the network, the RF side, doesn't use that DSCP mark at all. Once a packet is xmit from you onto the RF, they want to keep it (no sense making you retransmit it). The worst case is to drop an ACK packet upstream for an already delivered downstream packet. So I guess a 'scavenger class' is not that simple as just a DSCP mark. In an enterprise network it is, but as an end-to-end method through multiple providers, it doesn't really work. * access technology rarely is able to use it on all pieces (DSL doesn't, docsis doesn't, wimax doesn't, 3gpp(2) doesn't) * providers remark on the border to prevent 'theft of qos' * tunnels through the core ignore We also have the issue of the widely deployed nature of things (e.g. home routers, NAT, MS Windows networking stacks, ...) which = makes 'improvements' frustrating :) The so-called '80%' problem: 80% of the solution exists, so its not too motivating to work on the 100% solution. E.g. why switch to ipv6, I can just go buy another NAT. Networks have switched to packet-switched for a reason, so we can't really go back to 'this flow has this property' -> core routers just can't handle the routing table size or updates needed. -> I'm arguing in mobile ip it would be non-constant anyway _______________________________________________ p2pi mailing list p2pi@ietf.org https://www.ietf.org/mailman/listinfo/p2pi From p2pi-bounces@ietf.org Sun Jun 8 16:33:39 2008 Return-Path: X-Original-To: p2pi-archive@ietf.org Delivered-To: ietfarch-p2pi-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 936FF3A6862; Sun, 8 Jun 2008 16:33:39 -0700 (PDT) X-Original-To: p2pi@core3.amsl.com Delivered-To: p2pi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D9D723A6783 for ; Sun, 8 Jun 2008 16:33:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_17=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 69ttORdiC5KO for ; Sun, 8 Jun 2008 16:33:30 -0700 (PDT) Received: from mout.perfora.net (mout.perfora.net [74.208.4.195]) by core3.amsl.com (Postfix) with ESMTP id 9107A3A6862 for ; Sun, 8 Jun 2008 16:33:30 -0700 (PDT) Received: from viceroy (c-98-207-41-81.hsd1.ca.comcast.net [98.207.41.81]) by mrelay.perfora.net (node=mrus1) with ESMTP (Nemesis) id 0MKpCa-1K5UNv1XHB-00048h; Sun, 08 Jun 2008 19:33:19 -0400 From: "Stas Khirman" To: "'Nicholas Weaver'" , "'Joe Touch'" , References: <06BEE447-3D17-45D0-A73B-E248C3141F51@ICSI.Berkeley.EDU><484C1958.2010900@isi.edu> <8719C03C-9EC9-482B-9536-1784F95DC8A8@ICSI.Berkeley.EDU> Date: Sun, 8 Jun 2008 16:33:15 -0700 Message-ID: <064e01c8c9c0$08f77cc0$710d11ac@jnpr.net> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <8719C03C-9EC9-482B-9536-1784F95DC8A8@ICSI.Berkeley.EDU> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Thread-Index: AcjJnH2jAhUlEteESY+NvNPWvKy7fwAHf7MQ X-Provags-ID: V01U2FsdGVkX1+RsUzsrDib47pvX46q36qikTtyJo3r8YkF446 RH0bvhI5uh1doBtdYQXmWCUD2tWCoH3xGnLTWvIpvgIGex3BYq RNvNbvzRoli2mWKjmvEfg== Subject: Re: [p2pi] One more proposed definition of fairness... X-BeenThere: p2pi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: P2P Infrastructure Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: p2pi-bounces@ietf.org Errors-To: p2pi-bounces@ietf.org > Nicholas Weaver wrote: > > > It was also pointed out to me that http://www.anagran.com/ actually > claims to be targeting this ability, or something similar, managing > congestion that is remote from the point of management, although their > web site literature is pretty shy on information on how they are doing > it. > [Stas Khirman] They probably refer to implementation of the TIA 1039 / ITU Y.2121 (Y.flowreq) recommendations http://www.anagran.com/technology_enhanced_flow_rate_signaling.php The main idea is to negotiate capacity reservation on the first few packets of the flow ( SYN and SYN-ACK for example) using "in-band" signaling. Flow reservation request/response information is "attached" to the original TCP packet as an TCP option . IMHO, the main Y.flowreq challenge is to how originator of Y.flowreq request decides to classify a new arbitrary flow. It hard to believe that many end nodes will have "modified TCP/IP stack" installed anytime soon. Even if deployed, it will need a modification of networking applications ( or development new ones) to directly control FLOWREQ API. Alternative, is to use some kind heuristically (or DPI) flow classification, but it not always work well, especially if application ( like p2p) try to hide its protocol. P.S. I have no idea if Y.flowreq had been reviewed by IETF and will appreciate any input on this topic. _______________________________________________ p2pi mailing list p2pi@ietf.org https://www.ietf.org/mailman/listinfo/p2pi From p2pi-bounces@ietf.org Sun Jun 8 22:44: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 3D19F28C0FA; Sun, 8 Jun 2008 22:44: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 6B71C28C0FA for ; Sun, 8 Jun 2008 22:44:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.556 X-Spam-Level: X-Spam-Status: No, score=-2.556 tagged_above=-999 required=5 tests=[AWL=0.043, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jZGDpMLQnZYR for ; Sun, 8 Jun 2008 22:44:49 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by core3.amsl.com (Postfix) with ESMTP id 3CD7128C0E7 for ; Sun, 8 Jun 2008 22:44:49 -0700 (PDT) Received: from [127.0.0.1] (pool-71-106-109-69.lsanca.dsl-w.verizon.net [71.106.109.69]) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id m595fx4f025117 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sun, 8 Jun 2008 22:42:01 -0700 (PDT) Message-ID: <484CC2A5.6050105@isi.edu> Date: Sun, 08 Jun 2008 22:41:57 -0700 From: Joe Touch User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: Nicholas Weaver References: <06BEE447-3D17-45D0-A73B-E248C3141F51@ICSI.Berkeley.EDU> <484C1958.2010900@isi.edu> <8719C03C-9EC9-482B-9536-1784F95DC8A8@ICSI.Berkeley.EDU> In-Reply-To: <8719C03C-9EC9-482B-9536-1784F95DC8A8@ICSI.Berkeley.EDU> X-Enigmail-Version: 0.95.6 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: p2pi@ietf.org Subject: Re: [p2pi] One more proposed definition of fairness... X-BeenThere: p2pi@ietf.org X-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="===============1818393673==" Sender: p2pi-bounces@ietf.org Errors-To: p2pi-bounces@ietf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============1818393673== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigEC76B49C6C0EE7529BCC081C" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigEC76B49C6C0EE7529BCC081C Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Nicholas Weaver wrote: >=20 > On Jun 8, 2008, at 10:39 AM, Joe Touch wrote: >> Nicholas Weaver wrote: >>> (Buried in a previous mail, but I'd like comments on this separately)= >>> How does the following sound as one possible ideal goal for user-=20 >>> fairness: >>> "Mechanisms to enable the network to enforce traffic such that, in=20 >>> the presence of congestion, a user's congestion control response=20 >>> becomes equivalent to aggregating all traffic from that user into a = >>> single TCP stream." >> >> See the Congestion Manager or RFC2140 ;-) >> >> This is easy to do at the end system, but, AFAICT, impossible to=20 >> accomplish anywhere else (users will just grab multiple IP addresses, = >> e.g.) - or worse, involves violating TCP (or, equivalently, won't work= =20 >> on encrypted/authenticated streams). >=20 >=20 > I'm a security person. I have to assume the end systems don't behave=20 > right. But I actually don't think it is impossible to enforce in the=20 > network for the local users' ISP. =2E.. > EG, the ISP can at a single bidirectional point in the network=20 > (admittedly keeping lots of state, but...) for a large group of users=20 > infer the congestion on each TCP flow,... That's the point, however, where things stop when someone uses encrypted = transport layers. =2E.. > Yes, this is a LOT of engineering work to get right [1], but I believe = > it is doable, and could accomplish the stated definition of fairness (o= r=20 > something very close to it). A key question is whether it's worth the state it will take to get=20 right. An endpoint might open a few thousand flows just to help overload = your system ;-) > Furthermore, you can resist the attacks you mentioned. Because the ISP= =20 > can prevent the user from minting new IP addresses (as they control the= =20 > point of attachment), this prevents address forging. Sure - the local ISP can prevent that. You can't prevent someone=20 accessing multiple ISPs (cable, DSL, etc.), but presumably you don't=20 care about that? Joe --------------enigEC76B49C6C0EE7529BCC081C Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFITMKmE5f5cImnZrsRAgrtAKD0mO2hzOlFFBFPhF5DGX48CFWAoQCfYBIp 907kkZkUL4zAGolR1R5VeAc= =+0M+ -----END PGP SIGNATURE----- --------------enigEC76B49C6C0EE7529BCC081C-- --===============1818393673== 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 --===============1818393673==-- From p2pi-bounces@ietf.org Mon Jun 9 02:15: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 626D93A6B23; Mon, 9 Jun 2008 02:15: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 E14FD3A6B23 for ; Mon, 9 Jun 2008 02:15:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.469 X-Spam-Level: X-Spam-Status: No, score=-6.469 tagged_above=-999 required=5 tests=[AWL=0.130, 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 hutC9mmQkxmu for ; Mon, 9 Jun 2008 02:15:22 -0700 (PDT) Received: from mgw-mx06.nokia.com (smtp.nokia.com [192.100.122.233]) by core3.amsl.com (Postfix) with ESMTP id BC3253A6AC6 for ; Mon, 9 Jun 2008 02:15:21 -0700 (PDT) Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-mx06.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id m599FRbW004564; Mon, 9 Jun 2008 12:15:37 +0300 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 9 Jun 2008 12:15:35 +0300 Received: from dhcp180.dagstuhl.de ([10.241.184.208]) by esebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Mon, 9 Jun 2008 12:15:34 +0300 Message-Id: From: Lars Eggert To: "ext Joel M. Halpern" In-Reply-To: <484ACEEC.9070705@joelhalpern.com> Mime-Version: 1.0 (Apple Message framework v924) Date: Mon, 9 Jun 2008 11:15:17 +0200 References: <45AEC6EF95942140888406588E1A6602045CBA5E@PACDCEXCMB04.cable.comcast.com> <3efc39a60806061909n11a65eafnce88df7c73c30639@mail.gmail.com> <4CB75CEA-FE7E-4398-A1B3-A03DBF5063D3@icsi.berkeley.edu> <3efc39a60806070852p49f6a066y27e804fd5d4cf989@mail.gmail.com> <20080607173925.GJ8579@verdi> <484AC9EB.8060501@isi.edu> <20080607175712.GK8579@verdi> <484ACEEC.9070705@joelhalpern.com> X-Mailer: Apple Mail (2.924) X-OriginalArrivalTime: 09 Jun 2008 09:15:34.0975 (UTC) FILETIME=[5FC044F0:01C8CA11] X-Nokia-AV: Clean Cc: p2pi@ietf.org Subject: Re: [p2pi] Follow-Up 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 RFC3662? On 2008-6-7, at 20:09, ext Joel M. Halpern wrote: > Several of the meeting presentations referred to "Scavenger service". > > As a definition, assuming I am allowed to define using diffserv, how > about: > > Unmarked packets, and packets marked for better diffserv classes will > receive preferential queueing treatment compared with those marked > with > Scavenger class service. To avoid starvatation, the Scavanger queue > will be guaranteed a minimal percentage (10%?) of the data capacity > even > when normal and better services could consume all available bandwidth. > > That is basically the inverse of the simplified EF definition, for > achieving essentially the opposite goal. _______________________________________________ p2pi mailing list p2pi@ietf.org https://www.ietf.org/mailman/listinfo/p2pi From p2pi-bounces@ietf.org Mon Jun 9 02:23:29 2008 Return-Path: X-Original-To: p2pi-archive@ietf.org Delivered-To: ietfarch-p2pi-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9A6993A6C3B; Mon, 9 Jun 2008 02:23:29 -0700 (PDT) X-Original-To: p2pi@core3.amsl.com Delivered-To: p2pi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4FA563A6C24 for ; Mon, 9 Jun 2008 02:23:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qy+Zcb2kHUSg for ; Mon, 9 Jun 2008 02:23:27 -0700 (PDT) Received: from yw-out-2324.google.com (yw-out-2324.google.com [74.125.46.31]) by core3.amsl.com (Postfix) with ESMTP id 1B37D3A6C1B for ; Mon, 9 Jun 2008 02:23:26 -0700 (PDT) Received: by yw-out-2324.google.com with SMTP id 3so1083601ywj.49 for ; Mon, 09 Jun 2008 02:23:45 -0700 (PDT) Received: by 10.151.143.3 with SMTP id v3mr5944694ybn.229.1213003422987; Mon, 09 Jun 2008 02:23:42 -0700 (PDT) Received: by 10.150.148.13 with HTTP; Mon, 9 Jun 2008 02:23:42 -0700 (PDT) Message-ID: Date: Mon, 9 Jun 2008 02:23:42 -0700 From: "Stanislav Shalunov" To: "Lars Eggert" In-Reply-To: MIME-Version: 1.0 Content-Disposition: inline References: <45AEC6EF95942140888406588E1A6602045CBA5E@PACDCEXCMB04.cable.comcast.com> <3efc39a60806061909n11a65eafnce88df7c73c30639@mail.gmail.com> <4CB75CEA-FE7E-4398-A1B3-A03DBF5063D3@icsi.berkeley.edu> <3efc39a60806070852p49f6a066y27e804fd5d4cf989@mail.gmail.com> <20080607173925.GJ8579@verdi> <484AC9EB.8060501@isi.edu> <20080607175712.GK8579@verdi> <484ACEEC.9070705@joelhalpern.com> X-Google-Sender-Auth: 2048d745aa99742f Cc: p2pi@ietf.org Subject: Re: [p2pi] Follow-Up 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 See also http://qos.internet2.edu/wg/wg-documents/qbss-definition.txt On Mon, Jun 9, 2008 at 2:15 AM, Lars Eggert wrote: > RFC3662? > > On 2008-6-7, at 20:09, ext Joel M. Halpern wrote: >> Several of the meeting presentations referred to "Scavenger service". >> >> As a definition, assuming I am allowed to define using diffserv, how >> about: >> >> Unmarked packets, and packets marked for better diffserv classes will >> receive preferential queueing treatment compared with those marked >> with >> Scavenger class service. To avoid starvatation, the Scavanger queue >> will be guaranteed a minimal percentage (10%?) of the data capacity >> even >> when normal and better services could consume all available bandwidth. >> >> That is basically the inverse of the simplified EF definition, for >> achieving essentially the opposite goal. > > _______________________________________________ > p2pi mailing list > p2pi@ietf.org > https://www.ietf.org/mailman/listinfo/p2pi > -- Stanislav Shalunov http://shlang.com/ _______________________________________________ p2pi mailing list p2pi@ietf.org https://www.ietf.org/mailman/listinfo/p2pi From p2pi-bounces@ietf.org Mon Jun 9 02:28: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 D8E423A6BAB; Mon, 9 Jun 2008 02:28:18 -0700 (PDT) X-Original-To: p2pi@core3.amsl.com Delivered-To: p2pi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 50FFB3A6BAB for ; Mon, 9 Jun 2008 02:28:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.173 X-Spam-Level: X-Spam-Status: No, score=-6.173 tagged_above=-999 required=5 tests=[AWL=-0.174, BAYES_00=-2.599, J_CHICKENPOX_17=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yotUSo0BGsdD for ; Mon, 9 Jun 2008 02:28:16 -0700 (PDT) Received: from mgw-mx09.nokia.com (smtp.nokia.com [192.100.105.134]) by core3.amsl.com (Postfix) with ESMTP id 717023A690F for ; Mon, 9 Jun 2008 02:28:16 -0700 (PDT) Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-mx09.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id m599Rn6M015923; Mon, 9 Jun 2008 04:28:24 -0500 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 9 Jun 2008 12:27:44 +0300 Received: from dhcp180.dagstuhl.de ([10.241.184.208]) by esebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Mon, 9 Jun 2008 12:27:42 +0300 Message-Id: From: Lars Eggert To: ext Stas Khirman In-Reply-To: <064e01c8c9c0$08f77cc0$710d11ac@jnpr.net> Mime-Version: 1.0 (Apple Message framework v924) Date: Mon, 9 Jun 2008 11:25:21 +0200 References: <06BEE447-3D17-45D0-A73B-E248C3141F51@ICSI.Berkeley.EDU><484C1958.2010900@isi.edu> <8719C03C-9EC9-482B-9536-1784F95DC8A8@ICSI.Berkeley.EDU> <064e01c8c9c0$08f77cc0$710d11ac@jnpr.net> X-Mailer: Apple Mail (2.924) X-OriginalArrivalTime: 09 Jun 2008 09:27:44.0013 (UTC) FILETIME=[124AA3D0:01C8CA13] X-Nokia-AV: Clean Cc: p2pi@ietf.org, 'Nicholas Weaver' , 'Joe Touch' Subject: Re: [p2pi] One more proposed definition of fairness... X-BeenThere: p2pi@ietf.org X-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 2008-6-9, at 1:33, ext Stas Khirman wrote: > P.S. I have no idea if Y.flowreq had been reviewed by IETF and will > appreciate any input on this topic. It has; the transport area has exchanged a number of liaison statements with the ITU-T on this over the last few years. The latest one, FYI, is at https://datatracker.ietf.org/liaison/447/. The executive summary is that Y.flowreq proposes to redefine a number of core Internet protocols in a way that isn't clearly understood at a technical level, and the interactions of those changes with the rest of the Internet protocol suite are even more unclear at this point. We've cautioned the ITU-T that a realization of Y.flowreq requires changes to protocols that aren't under their control, and that any such work will hence need to happen in the IETF. Lars _______________________________________________ p2pi mailing list p2pi@ietf.org https://www.ietf.org/mailman/listinfo/p2pi From p2pi-bounces@ietf.org Mon Jun 9 02:35:34 2008 Return-Path: X-Original-To: p2pi-archive@ietf.org Delivered-To: ietfarch-p2pi-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 87A7F28C0FA; Mon, 9 Jun 2008 02:35:34 -0700 (PDT) X-Original-To: p2pi@core3.amsl.com Delivered-To: p2pi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 119A43A6AB4 for ; Mon, 9 Jun 2008 02:35:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TgbhTSB58Wuv for ; Mon, 9 Jun 2008 02:35:31 -0700 (PDT) Received: from yw-out-2324.google.com (yw-out-2324.google.com [74.125.46.31]) by core3.amsl.com (Postfix) with ESMTP id A55743A690F for ; Mon, 9 Jun 2008 02:35:31 -0700 (PDT) Received: by yw-out-2324.google.com with SMTP id 3so1085013ywj.49 for ; Mon, 09 Jun 2008 02:35:36 -0700 (PDT) Received: by 10.151.100.17 with SMTP id c17mr5956942ybm.210.1213004136493; Mon, 09 Jun 2008 02:35:36 -0700 (PDT) Received: by 10.150.148.13 with HTTP; Mon, 9 Jun 2008 02:35:36 -0700 (PDT) Message-ID: Date: Mon, 9 Jun 2008 02:35:36 -0700 From: "Stanislav Shalunov" To: "Henning Schulzrinne" In-Reply-To: MIME-Version: 1.0 Content-Disposition: inline References: <215A468E-603E-486F-A544-D9CC0AF7C243@cs.columbia.edu> <3efc39a60806081429k3a2d2df7u861b400e9188850e@mail.gmail.com> X-Google-Sender-Auth: 60185cacf3d09040 Cc: p2pi@ietf.org Subject: Re: [p2pi] For those who think "User Fairness/Cost Fairness" is unacceptable... X-BeenThere: p2pi@ietf.org X-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 Henning, The topic, is, indeed, not related to engineering, and your analysis is quite right. One small point while we're on the subject: ISPs charge flat rates not by coincidence or charity, but because they expect to make the most money this way. Uneven consumption within flat plans existed before P2P. Light and heavy users existed since mail systems were first built in your favorite ancient empire. (I once wrote a script to find and quantify this in dialup days and found what I didn't expect to find: the modem pool spent most of its time negotiating the speed, and so disabling the most high-speed option shortened the negotiation and removed the congestion before I had to decide what to do with the heavy users.) Users are prepared to pay a premium for consistent month-to-month pricing. ISPs are happy to take this premium. If usage mix changes, they can change the pricing plans, but consumers will continue to be prepared to pay a premium for consistent month-to-month spending, and many ISPs will likely choose to continue to take this premium, offering different plans to different types of users. -- Stas On Sun, Jun 8, 2008 at 3:34 PM, Henning Schulzrinne wrote: > This is straying somewhat outside the technical, but, as I've said > before, this is largely an economics problem. > > For simplicity, let's assume for a moment that Internet access was a > regulated monopoly as opposed to an unregulated monopoly, as it is > now, or a classical competitive market. A fictitious public utility > commission or competitive business now has three choices, given the > mix of users of today (95% "light", 5% "heavy"): > > (1) Light users and heavy users pay the same, but light users pay more > than they would without the heavy users, since the network capacity > has to be much larger. > > (2) Heavy users are kicked off the network. They now have a choice: > run their own fiber or only get service below what they are interested > in. They are lost as customers to the provider and the cost of the own > fiber is prohibitive, so nobody earns any extra money (but the > provider and 95% of the customers save some money; the division of the > spoils between the two is a matter of market power or choices made by > the regulator). > > (3) Heavy users are charged more, but significantly less than it would > cost to lay a separate fiber. Assuming that heavy users value the > service sufficiently to pay the extra charge, everybody gains: the > provider gets additional revenue with modest additional infrastructure > investment, the light user doesn't subsidize the heavy user and the > heavy user gets extra bandwidth. > > There is one core economics assumption here: The heavy user actually > values bandwidth more than the incremental charge. (This is the > classical problem in discussions of pirating: Many users would forego > the movie rather than pay full fare. It could well be that heavy users > don't value the extra bandwidth they use at what it costs to provide > it, but that's just a version of "there is no free lunch".) > > This is under the assumption that separating or charging heavy users > is feasible and worthwhile. At an "all you can eat" buffet, finite > stomach capacity and the prohibition against doggy-bagging make > counting trips to the salad bar not worth the hassle. With high-speed > Internet access, the consumption ratio between light and heavy users > is much larger than for other "flat-rate" services. Measuring isn't > much of an issue, but the fear of $1000 bill surprises might be. > > In an unregulated monopoly, the calculations are different since the > provider can potentially practice perfect market segmentation and > capture all the surplus. That's a discussion for a different day. > > Henning > > On Jun 8, 2008, at 5:29 PM, Robb Topolski wrote: >> >> And on that point, I only can say "I'm not sure." There certainly >> is an unmet demand, but I'm not sure if it rises to the status of >> unmet need. And perhaps these are Economics 101 terms that I do not >> fully understand. >> >> When I was gigging, I could spend every weekend doing birthday and >> anniversary parties for free. We weren't that good, but we decided >> to charge a small fee. When the price of getting four performers >> tuxedoed across town for an hour became $50-$100, things quickly >> struck a happy balance. In that case, it wasn't that there was an >> unmet need for barbershop quartet singers, it was more true that >> "free" was a very good price. >> >> In your opinion, or perhaps in the Econ. vernacular, is that an >> "unmet need" or something less? And is it important IETF business >> either way? >> >> -- >> Robb Topolski (robb@funchords.com) >> Hillsboro, Oregon USA >> http://www.funchords.com/ > > _______________________________________________ > p2pi mailing list > p2pi@ietf.org > https://www.ietf.org/mailman/listinfo/p2pi > -- Stanislav Shalunov http://shlang.com/ _______________________________________________ p2pi mailing list p2pi@ietf.org https://www.ietf.org/mailman/listinfo/p2pi From p2pi-bounces@ietf.org Mon Jun 9 05:41:26 2008 Return-Path: X-Original-To: p2pi-archive@ietf.org Delivered-To: ietfarch-p2pi-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0243E3A6BD4; Mon, 9 Jun 2008 05:41:26 -0700 (PDT) X-Original-To: p2pi@core3.amsl.com Delivered-To: p2pi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6C8AC3A6C56 for ; Mon, 9 Jun 2008 05:41:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.258 X-Spam-Level: X-Spam-Status: No, score=-6.258 tagged_above=-999 required=5 tests=[AWL=0.341, 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 ugGS-JAJqajI for ; Mon, 9 Jun 2008 05:41:20 -0700 (PDT) Received: from fruitcake.ICSI.Berkeley.EDU (fruitcake.ICSI.Berkeley.EDU [192.150.186.11]) by core3.amsl.com (Postfix) with ESMTP id 2DD893A6BD4 for ; Mon, 9 Jun 2008 05:41:20 -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 m59CfSS2015372; Mon, 9 Jun 2008 05:41:28 -0700 (PDT) Message-Id: <1621FECD-ED33-4BF2-88D0-199D6FA75993@ICSI.Berkeley.EDU> From: Nicholas Weaver To: Joe Touch In-Reply-To: <484CC2A5.6050105@isi.edu> Mime-Version: 1.0 (Apple Message framework v924) Date: Mon, 9 Jun 2008 05:41:30 -0700 References: <06BEE447-3D17-45D0-A73B-E248C3141F51@ICSI.Berkeley.EDU> <484C1958.2010900@isi.edu> <8719C03C-9EC9-482B-9536-1784F95DC8A8@ICSI.Berkeley.EDU> <484CC2A5.6050105@isi.edu> X-Mailer: Apple Mail (2.924) Cc: p2pi@ietf.org, Nicholas Weaver Subject: Re: [p2pi] One more proposed definition of fairness... X-BeenThere: p2pi@ietf.org X-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 Jun 8, 2008, at 10:41 PM, Joe Touch wrote: > ... >> EG, the ISP can at a single bidirectional point in the network >> (admittedly keeping lots of state, but...) for a large group of >> users infer the congestion on each TCP flow,... > > That's the point, however, where things stop when someone uses > encrypted transport layers. As long as the end point address is NOT encrypted, it doesn't matter. > ... >> Yes, this is a LOT of engineering work to get right [1], but I >> believe it is doable, and could accomplish the stated definition of >> fairness (or something very close to it). > > A key question is whether it's worth the state it will take to get > right. An endpoint might open a few thousand flows just to help > overload your system ;-) a) A few thousand is nothing. You have to be talking tens of thousands to start with before I should start caring. b) There are some really nice structures that work for cheating. EG, a 256k entry flow cache is probably sufficient, if you have a LRU policy, for even large networks since you are measuring short duration properties (to determine loss). Looking at Berkeley's access network, I think a 256k entry or 512k entry cache would be sufficient to effectively never have evictions of flows in less than 2 seconds, and you could easily structure things so that if you lose a little precision through cache evictions, it doesn't matter. Yes, tracking EXACTLY is very problematic. But tracking approximately is far far easier. c) If a single host or small group of hosts starts doing behavior designed to disrupt the flow cache deliberately (eg, >10k ACTIVE TCP flows), I think the ISPs device can start doing some rate limiting on flow creation as well, as there is a strong case that such is suspicious behavior. d) "State is cheap, its ACCESSING state is expensive" if you look at modern memory technology. DRAM is slow. DRAM has awful latency. But assuming a reasonable median packet size of about ~200B, you can still access one or maby two locations in DRAM even on a 10 GigE device. Thus if you can have your algorithm so that it may have 1 GB of memory, but only needs to access one location (say a cache line) for a read/update, you can probably manage things. > > >> Furthermore, you can resist the attacks you mentioned. Because the >> ISP can prevent the user from minting new IP addresses (as they >> control the point of attachment), this prevents address forging. > > Sure - the local ISP can prevent that. You can't prevent someone > accessing multiple ISPs (cable, DSL, etc.), but presumably you don't > care about that? > Yeah, why should the ISP care? Its because common congestion pretty much only occurs within the ISP, so it is the ISP's problem to mitigate, and in the ISP's interest to mitigate. Someone who's using multiple ISPs to transfer more bits is paying for those extra bits, and it doesn't really matter. _______________________________________________ p2pi mailing list p2pi@ietf.org https://www.ietf.org/mailman/listinfo/p2pi From p2pi-bounces@ietf.org Mon Jun 9 06:03:46 2008 Return-Path: X-Original-To: p2pi-archive@ietf.org Delivered-To: ietfarch-p2pi-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4158A3A6BA2; Mon, 9 Jun 2008 06:03:46 -0700 (PDT) X-Original-To: p2pi@core3.amsl.com Delivered-To: p2pi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 14B823A6C56 for ; Mon, 9 Jun 2008 06:03:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.227 X-Spam-Level: X-Spam-Status: No, score=-3.227 tagged_above=-999 required=5 tests=[AWL=0.372, 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 xyHOBDBIijIu for ; Mon, 9 Jun 2008 06:03:45 -0700 (PDT) Received: from brinza.cc.columbia.edu (brinza.cc.columbia.edu [128.59.29.8]) by core3.amsl.com (Postfix) with ESMTP id 24E123A6BA2 for ; Mon, 9 Jun 2008 06:03:44 -0700 (PDT) Received: from [192.168.0.61] (pool-71-250-59-79.nwrknj.east.verizon.net [71.250.59.79]) (user=hgs10 mech=PLAIN bits=0) by brinza.cc.columbia.edu (8.14.1/8.14.1) with ESMTP id m59D3RV6004628 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Mon, 9 Jun 2008 09:03:28 -0400 (EDT) Message-Id: <8B41AFE5-C1CF-4E9A-9975-57C6B81864C1@cs.columbia.edu> From: Henning Schulzrinne To: Stanislav Shalunov In-Reply-To: Mime-Version: 1.0 (Apple Message framework v924) Date: Mon, 9 Jun 2008 09:03:27 -0400 References: <215A468E-603E-486F-A544-D9CC0AF7C243@cs.columbia.edu> <3efc39a60806081429k3a2d2df7u861b400e9188850e@mail.gmail.com> X-Mailer: Apple Mail (2.924) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.63 on 128.59.29.8 Cc: p2pi@ietf.org Subject: Re: [p2pi] For those who think "User Fairness/Cost Fairness" is unacceptable... X-BeenThere: p2pi@ietf.org X-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 > > Users are prepared to pay a premium for consistent month-to-month > pricing. ISPs are happy to take this premium. If usage mix changes, > they can change the pricing plans, but consumers will continue to be > prepared to pay a premium for consistent month-to-month spending, and > many ISPs will likely choose to continue to take this premium, > offering different plans to different types of users. In general, this is indeed an empirically well-founded observation. The problem is that this holds only if the penalty for predictability is reasonably small. The old model of differentiating by access speed no longer works and is counter-productive (just makes uploading my photos a royal pain), so I'm unclear what you mean by "different plans" except volume-based tiering. Just to take the cell phone example: We have both, quite successfully, all-you-can-talk plans at around $80 to $100/month, but also, at the other end, low-volume prepay plans that work out to roughly $10/month for minimal usage. (Less in Europe and Asia for reasons not worth discussing here.) It is very unlikely that those on the prepay plan would want to switch to the Sprint $99 all-inclusive plan just for predictability, or vice versa. I suspect that there will always be all-you-can-send plans for data, but they'll be more akin to the $99 cell phone plans than your average family $29.95 cell phone plan. (Monthly ARPU in the US for cell is around $50.) The "bucket-of-minutes model" with roll over seems likely a reasonable model. You don't worry about every byte, but you get segmentation. Henning _______________________________________________ p2pi mailing list p2pi@ietf.org https://www.ietf.org/mailman/listinfo/p2pi From p2pi-bounces@ietf.org Mon Jun 9 06:20:32 2008 Return-Path: X-Original-To: p2pi-archive@ietf.org Delivered-To: ietfarch-p2pi-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 467CC3A6C53; Mon, 9 Jun 2008 06:20:32 -0700 (PDT) X-Original-To: p2pi@core3.amsl.com Delivered-To: p2pi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8C00E3A699D for ; Mon, 9 Jun 2008 06:20:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[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 aZyNnlmi1Loh for ; Mon, 9 Jun 2008 06:20:27 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by core3.amsl.com (Postfix) with ESMTP id 917933A6C63 for ; Mon, 9 Jun 2008 06:20:26 -0700 (PDT) Received: from [127.0.0.1] (c3-vpn2.isi.edu [128.9.176.73] (may be forged)) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id m59DJaOk023630 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 9 Jun 2008 06:19:39 -0700 (PDT) Message-ID: <484D2DE8.7020407@isi.edu> Date: Mon, 09 Jun 2008 06:19:36 -0700 From: Joe Touch User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: Nicholas Weaver References: <06BEE447-3D17-45D0-A73B-E248C3141F51@ICSI.Berkeley.EDU> <484C1958.2010900@isi.edu> <8719C03C-9EC9-482B-9536-1784F95DC8A8@ICSI.Berkeley.EDU> <484CC2A5.6050105@isi.edu> <1621FECD-ED33-4BF2-88D0-199D6FA75993@ICSI.Berkeley.EDU> In-Reply-To: <1621FECD-ED33-4BF2-88D0-199D6FA75993@ICSI.Berkeley.EDU> X-Enigmail-Version: 0.95.6 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: p2pi@ietf.org Subject: Re: [p2pi] One more proposed definition of fairness... X-BeenThere: p2pi@ietf.org X-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="===============1785161936==" Sender: p2pi-bounces@ietf.org Errors-To: p2pi-bounces@ietf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============1785161936== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig8B5141D757C1B570EE15AEE6" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig8B5141D757C1B570EE15AEE6 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Nicholas Weaver wrote: >=20 > On Jun 8, 2008, at 10:41 PM, Joe Touch wrote: >> ... >>> EG, the ISP can at a single bidirectional point in the network=20 >>> (admittedly keeping lots of state, but...) for a large group of users= =20 >>> infer the congestion on each TCP flow,... >> >> That's the point, however, where things stop when someone uses=20 >> encrypted transport layers. >=20 > As long as the end point address is NOT encrypted, it doesn't matter. How might I infer the congestion on each TCP flow when I can't see TCP=20 connections, e.g.? >> ... >>> Yes, this is a LOT of engineering work to get right [1], but I=20 >>> believe it is doable, and could accomplish the stated definition of=20 >>> fairness (or something very close to it). >> >> A key question is whether it's worth the state it will take to get=20 >> right. An endpoint might open a few thousand flows just to help=20 >> overload your system ;-) =2E.. =2E.. > c) If a single host or small group of hosts starts doing behavior=20 > designed to disrupt the flow cache deliberately (eg, >10k ACTIVE TCP=20 > flows), I think the ISPs device can start doing some rate limiting on=20 > flow creation as well, as there is a strong case that such is suspiciou= s=20 > behavior. How can you infer that >10K flows from a host is deliberate disruption?=20 If I buy an Internet connection from an ISP, I get as many flows as I=20 can connect to. Or have you decided that "the Internet" is now only as many flows as you = can track efficiently? (see below) >>> Furthermore, you can resist the attacks you mentioned. Because the=20 >>> ISP can prevent the user from minting new IP addresses (as they=20 >>> control the point of attachment), this prevents address forging. >> >> Sure - the local ISP can prevent that. You can't prevent someone=20 >> accessing multiple ISPs (cable, DSL, etc.), but presumably you don't=20 >> care about that? >=20 > Yeah, why should the ISP care? Its because common congestion pretty=20 > much only occurs within the ISP, so it is the ISP's problem to mitigate= ,=20 > and in the ISP's interest to mitigate. >=20 > Someone who's using multiple ISPs to transfer more bits is paying for=20 > those extra bits, and it doesn't really matter. Maybe I'm missing something, but if I have one ISP, I paid for THOSE=20 bits too. How I use them is up to me, not the ISP. Joe --------------enig8B5141D757C1B570EE15AEE6 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFITS3oE5f5cImnZrsRAuRcAJ9+0MaClfAfEGHFs+SdXFzC+FsUlgCgr6mR +LrAq4WZjtrJVnwwEwTukUs= =gsZW -----END PGP SIGNATURE----- --------------enig8B5141D757C1B570EE15AEE6-- --===============1785161936== 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 --===============1785161936==-- From p2pi-bounces@ietf.org Mon Jun 9 07:43: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 4E4CE3A67EA; Mon, 9 Jun 2008 07:43: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 C86AA3A6C93 for ; Mon, 9 Jun 2008 07:43:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.282 X-Spam-Level: X-Spam-Status: No, score=-6.282 tagged_above=-999 required=5 tests=[AWL=0.317, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JLBlBrZ5ZSNY for ; Mon, 9 Jun 2008 07:43: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 C08683A6C7C for ; Mon, 9 Jun 2008 07:43: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 m59EhV3r010018; Mon, 9 Jun 2008 07:43:31 -0700 (PDT) Message-Id: <4D7FB692-F754-4DD7-A63C-BA96C5FF5E05@ICSI.Berkeley.EDU> From: Nicholas Weaver To: Joe Touch In-Reply-To: <484D2DE8.7020407@isi.edu> Mime-Version: 1.0 (Apple Message framework v924) Date: Mon, 9 Jun 2008 07:43:31 -0700 References: <06BEE447-3D17-45D0-A73B-E248C3141F51@ICSI.Berkeley.EDU> <484C1958.2010900@isi.edu> <8719C03C-9EC9-482B-9536-1784F95DC8A8@ICSI.Berkeley.EDU> <484CC2A5.6050105@isi.edu> <1621FECD-ED33-4BF2-88D0-199D6FA75993@ICSI.Berkeley.EDU> <484D2DE8.7020407@isi.edu> X-Mailer: Apple Mail (2.924) Cc: p2pi@ietf.org, Nicholas Weaver Subject: Re: [p2pi] One more proposed definition of fairness... X-BeenThere: p2pi@ietf.org X-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 Jun 9, 2008, at 6:19 AM, Joe Touch wrote: > > > Nicholas Weaver wrote: >> On Jun 8, 2008, at 10:41 PM, Joe Touch wrote: >>> ... >>>> EG, the ISP can at a single bidirectional point in the network >>>> (admittedly keeping lots of state, but...) for a large group of >>>> users infer the congestion on each TCP flow,... >>> >>> That's the point, however, where things stop when someone uses >>> encrypted transport layers. >> As long as the end point address is NOT encrypted, it doesn't matter. > > How might I infer the congestion on each TCP flow when I can't see > TCP connections, e.g.? > As long as there is SOME fraction that is TCP, I can still infer the common congestion, using it as a canary. And since such a device is part of the ISP's infrastructure, it could also get the ISP's internal routing table, so you can use some TCP flows to sample where common congestion occurs, and routing information to determine what is affected by common congestion. It also doesn't matter if ECN is enabled, at least for the upstream congestion. ECN signals congestion in the IP layer, which means that even for encrypted tunnels, the ECN data is available to make decisions on detecting congestion. Re-ECN would allow you to see both upstream and downstream congestion. >>> ... >>>> Yes, this is a LOT of engineering work to get right [1], but I >>>> believe it is doable, and could accomplish the stated definition >>>> of fairness (or something very close to it). >>> >>> A key question is whether it's worth the state it will take to get >>> right. An endpoint might open a few thousand flows just to help >>> overload your system ;-) > ... > > ... >> c) If a single host or small group of hosts starts doing behavior >> designed to disrupt the flow cache deliberately (eg, >10k ACTIVE >> TCP flows), I think the ISPs device can start doing some rate >> limiting on flow creation as well, as there is a strong case that >> such is suspicious behavior. > > How can you infer that >10K flows from a host is deliberate > disruption? If I buy an Internet connection from an ISP, I get as > many flows as I can connect to. > > Or have you decided that "the Internet" is now only as many flows as > you can track efficiently? (see below) Actually, many users have a practical limit of <8K flows due to their NAT boxes anyway (and some have <1K flows). Furthermore, depending on how you cache things, since it is only MONITORING that needs to be done per-flow (policing needs to be per- user anyway), if someone tries to blow out the flow-cache, well, so what? Track some subset of their flows, don't use their flows to evict other flows (but if there is cache space, you still cache them), and be happy: you can always subsample and still get the information you need, albeit with a bit of degradation in accuracy. Thats the other beauty of just monitoring flows (but acting on users), you can easily tolerate not being able to monitor all flows. >>>> Furthermore, you can resist the attacks you mentioned. Because >>>> the ISP can prevent the user from minting new IP addresses (as >>>> they control the point of attachment), this prevents address >>>> forging. >>> >>> Sure - the local ISP can prevent that. You can't prevent someone >>> accessing multiple ISPs (cable, DSL, etc.), but presumably you >>> don't care about that? >> Yeah, why should the ISP care? Its because common congestion >> pretty much only occurs within the ISP, so it is the ISP's problem >> to mitigate, and in the ISP's interest to mitigate. >> Someone who's using multiple ISPs to transfer more bits is paying >> for those extra bits, and it doesn't really matter. > > Maybe I'm missing something, but if I have one ISP, I paid for THOSE > bits too. How I use them is up to me, not the ISP. I don't see what our disagreement is. Users paying for multiple accounts get more bandwidth, and as ISP A doesnt' see the packets going through ISP-B, it doesn't matter to A what they are doing elsewhere. _______________________________________________ p2pi mailing list p2pi@ietf.org https://www.ietf.org/mailman/listinfo/p2pi From p2pi-bounces@ietf.org Mon Jun 9 07:47:26 2008 Return-Path: X-Original-To: p2pi-archive@ietf.org Delivered-To: ietfarch-p2pi-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E8C513A6C3D; Mon, 9 Jun 2008 07:47:26 -0700 (PDT) X-Original-To: p2pi@core3.amsl.com Delivered-To: p2pi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B38113A67EA for ; Mon, 9 Jun 2008 07:47:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.499 X-Spam-Level: X-Spam-Status: No, score=-2.499 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sYhvYZh7Na6B for ; Mon, 9 Jun 2008 07:47:24 -0700 (PDT) Received: from av-tac-bru.cisco.com (odd-brew.cisco.com [144.254.15.119]) by core3.amsl.com (Postfix) with ESMTP id D6C6A3A6AFC for ; Mon, 9 Jun 2008 07:47:23 -0700 (PDT) X-TACSUNS: Virus Scanned Received: from strange-brew.cisco.com (localhost [127.0.0.1]) by av-tac-bru.cisco.com (8.11.7p3+Sun/8.11.7) with ESMTP id m59Eleq23252; Mon, 9 Jun 2008 16:47:40 +0200 (CEST) Received: from [144.254.189.71] (dhcp-rom2-144-254-189-71.cisco.com [144.254.189.71]) by strange-brew.cisco.com (8.11.7p3+Sun/8.11.7) with ESMTP id m59ElZA11431; Mon, 9 Jun 2008 16:47:35 +0200 (CEST) User-Agent: Microsoft-Entourage/11.4.0.080122 Date: Mon, 09 Jun 2008 16:47:22 +0200 From: stefano previdi To: Enrico Marocco , Ted Hardie Message-ID: Thread-Topic: [p2pi] Thoughts on how IETF standards can help P2P/ISPs Thread-Index: AcjKP7lD967lIjYyEd2nAQAX8vOM8g== In-Reply-To: <484502EF.5030609@telecomitalia.it> Mime-version: 1.0 Cc: "ramit@pando.com" , "p2pi@ietf.org" , "p4pwg@yahoogroups.com" Subject: Re: [p2pi] Thoughts on how IETF standards can help P2P/ISPs X-BeenThere: p2pi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: P2P Infrastructure Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: p2pi-bounces@ietf.org Errors-To: p2pi-bounces@ietf.org > From: Enrico Marocco > > Ted Hardie wrote: >> At 3:15 PM -0700 6/2/08, Enrico Marocco wrote: >>> It seems to me that this turned out to be a two-sided problem. On the >>> one hand, it is clear that applications on the endpoints are in the >>> worst position to make optimal network decisions; a first part of the >>> solution should thus consist of a mechanism to defer such decisions to >>> external entities >> >> Of course you can recast this as "So we should make sure that >> there are mechanisms that allow them to make more optimal decisions. >> The facilities which provide this information need not be controlled >> by the ISPs, but might be third party services which indicate >> cost/topology/congestion or some profile mix of the three." > > Existing systems today used (or proposed) for optimizing peer selection > use different methods to make their choices. While it would be easy to > define a common interface such systems could expose to p2p applications, > it would be probably hard to standardize cost/topology/congestion/policy > notification mechanisms in order to accommodate all different approaches > adopted by existing and foreseeable solutions. I agree with the addition that ietf could work on standardization of extensions/enhancements of existing routing protocols that could be leveraged by any localization/proximity implementation. I know at least one implementation that goes towards that direction... s. > > Examples of existing systems are Vivaldi and Ono, embedded in 10^5~10^6 > Azureus clients out there, P4P, iPlane, PIC and many others, simulated > and emulated in friendly environments. > >> To my way of thinking, that makes it easier to consider the API >> design, as it is not so much an API that says "What's the best >> choice right now?" but "What's the best X (flow pattern, topology, >> price)". The second set of questions is sufficiently more modular >> that it is both easier to get right and, at least in my opinion, >> more interesting. > > Well, I'd probably prefer a compromise between the two, something like > "What's the best choice for downloading X Mb of delay-sensitive data?". > And, just to be clear, available options must be provided by the > application which, at the end of the day, will be also in charge of > making the final decision (including ignoring the answer if for some > reason it doesn't like it). > > -- > Ciao, > Enrico > _______________________________________________ > p2pi mailing list > p2pi@ietf.org > https://www.ietf.org/mailman/listinfo/p2pi _______________________________________________ p2pi mailing list p2pi@ietf.org https://www.ietf.org/mailman/listinfo/p2pi From p2pi-bounces@ietf.org Mon Jun 9 08:04:33 2008 Return-Path: X-Original-To: p2pi-archive@ietf.org Delivered-To: ietfarch-p2pi-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 180613A6AFC; Mon, 9 Jun 2008 08:04:33 -0700 (PDT) X-Original-To: p2pi@core3.amsl.com Delivered-To: p2pi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9F8D03A6A94 for ; Mon, 9 Jun 2008 08:04:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[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 AFyhHvsRwr8g for ; Mon, 9 Jun 2008 08:04:30 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by core3.amsl.com (Postfix) with ESMTP id BD9CA3A6784 for ; Mon, 9 Jun 2008 08:04:30 -0700 (PDT) Received: from [127.0.0.1] (c3-vpn2.isi.edu [128.9.176.73] (may be forged)) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id m59EwNfI001958 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 9 Jun 2008 07:58:25 -0700 (PDT) Message-ID: <484D450E.4060806@isi.edu> Date: Mon, 09 Jun 2008 07:58:22 -0700 From: Joe Touch User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: Nicholas Weaver References: <06BEE447-3D17-45D0-A73B-E248C3141F51@ICSI.Berkeley.EDU> <484C1958.2010900@isi.edu> <8719C03C-9EC9-482B-9536-1784F95DC8A8@ICSI.Berkeley.EDU> <484CC2A5.6050105@isi.edu> <1621FECD-ED33-4BF2-88D0-199D6FA75993@ICSI.Berkeley.EDU> <484D2DE8.7020407@isi.edu> <4D7FB692-F754-4DD7-A63C-BA96C5FF5E05@ICSI.Berkeley.EDU> In-Reply-To: <4D7FB692-F754-4DD7-A63C-BA96C5FF5E05@ICSI.Berkeley.EDU> X-Enigmail-Version: 0.95.6 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: p2pi@ietf.org Subject: Re: [p2pi] One more proposed definition of fairness... X-BeenThere: p2pi@ietf.org X-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="===============0841487153==" Sender: p2pi-bounces@ietf.org Errors-To: p2pi-bounces@ietf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============0841487153== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigA9253B88633F55425C208A5A" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigA9253B88633F55425C208A5A Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Nicholas Weaver wrote: =2E.. >>>>> Furthermore, you can resist the attacks you mentioned. Because the= =20 >>>>> ISP can prevent the user from minting new IP addresses (as they=20 >>>>> control the point of attachment), this prevents address forging. >>>> >>>> Sure - the local ISP can prevent that. You can't prevent someone=20 >>>> accessing multiple ISPs (cable, DSL, etc.), but presumably you don't= =20 >>>> care about that? >>> Yeah, why should the ISP care? Its because common congestion pretty = >>> much only occurs within the ISP, so it is the ISP's problem to=20 >>> mitigate, and in the ISP's interest to mitigate. >>> Someone who's using multiple ISPs to transfer more bits is paying for= =20 >>> those extra bits, and it doesn't really matter. >> >> Maybe I'm missing something, but if I have one ISP, I paid for THOSE=20 >> bits too. How I use them is up to me, not the ISP. >=20 > I don't see what our disagreement is. Users paying for multiple=20 > accounts get more bandwidth, and as ISP A doesnt' see the packets going= =20 > through ISP-B, it doesn't matter to A what they are doing elsewhere. We agree on that. We agree that if I pay two ISPs for BW, I get to use=20 both. Do you agree that if I pay one ISP for BW, I get to use it - all=20 of it? (i.e., if this is about ISP internal congestion, then the ISP is=20 at fault for underprovisioning, not the user) I get the impression that if an ISP has upstream congestion, you think=20 it gets to limit the number of flows I send; I think that my packets can = get dropped due to congestion, but it's not useful for the ISP to have a = different notion of 'fairness' than the endpoint. Joe --------------enigA9253B88633F55425C208A5A Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFITUUPE5f5cImnZrsRAjZ0AJwN73mAeugXGxdsh4DPQfXx4/a8OwCfUpqq M24P8lG452MigDnwUgXD/x8= =mJT0 -----END PGP SIGNATURE----- --------------enigA9253B88633F55425C208A5A-- --===============0841487153== 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 --===============0841487153==-- From p2pi-bounces@ietf.org Mon Jun 9 08:36:49 2008 Return-Path: X-Original-To: p2pi-archive@ietf.org Delivered-To: ietfarch-p2pi-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E761A28C16C; Mon, 9 Jun 2008 08:36:49 -0700 (PDT) X-Original-To: p2pi@core3.amsl.com Delivered-To: p2pi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CB0583A6A32 for ; Mon, 9 Jun 2008 08:36:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.303 X-Spam-Level: X-Spam-Status: No, score=-6.303 tagged_above=-999 required=5 tests=[AWL=0.296, 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 utlkmnCPe-Ug for ; Mon, 9 Jun 2008 08:36:48 -0700 (PDT) Received: from fruitcake.ICSI.Berkeley.EDU (fruitcake.ICSI.Berkeley.EDU [192.150.186.11]) by core3.amsl.com (Postfix) with ESMTP id EBDA23A69C5 for ; Mon, 9 Jun 2008 08:36:47 -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 m59Fb6FN019765; Mon, 9 Jun 2008 08:37:06 -0700 (PDT) Message-Id: <86DEA620-3C64-4C5D-A2A6-C4CD064B5AE1@ICSI.Berkeley.EDU> From: Nicholas Weaver To: Joe Touch In-Reply-To: <484D450E.4060806@isi.edu> Mime-Version: 1.0 (Apple Message framework v924) Date: Mon, 9 Jun 2008 08:37:06 -0700 References: <06BEE447-3D17-45D0-A73B-E248C3141F51@ICSI.Berkeley.EDU> <484C1958.2010900@isi.edu> <8719C03C-9EC9-482B-9536-1784F95DC8A8@ICSI.Berkeley.EDU> <484CC2A5.6050105@isi.edu> <1621FECD-ED33-4BF2-88D0-199D6FA75993@ICSI.Berkeley.EDU> <484D2DE8.7020407@isi.edu> <4D7FB692-F754-4DD7-A63C-BA96C5FF5E05@ICSI.Berkeley.EDU> <484D450E.4060806@isi.edu> X-Mailer: Apple Mail (2.924) Cc: p2pi@ietf.org, Nicholas Weaver Subject: Re: [p2pi] One more proposed definition of fairness... X-BeenThere: p2pi@ietf.org X-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 Jun 9, 2008, at 7:58 AM, Joe Touch wrote: >>>> >>> >>> Maybe I'm missing something, but if I have one ISP, I paid for >>> THOSE bits too. How I use them is up to me, not the ISP. >> I don't see what our disagreement is. Users paying for multiple >> accounts get more bandwidth, and as ISP A doesnt' see the packets >> going through ISP-B, it doesn't matter to A what they are doing >> elsewhere. > > We agree on that. We agree that if I pay two ISPs for BW, I get to > use both. Do you agree that if I pay one ISP for BW, I get to use it > - all of it? (i.e., if this is about ISP internal congestion, then > the ISP is at fault for underprovisioning, not the user) > > I get the impression that if an ISP has upstream congestion, you > think it gets to limit the number of flows I send; I think that my > packets can get dropped due to congestion, but it's not useful for > the ISP to have a different notion of 'fairness' than the endpoint. Actually, I disagree here, for the following reason: a: The endpoints have a proven in practice bad notion of fairness: They have TCP flow fairness (which can and is abused by some users, who eg, transfer on many torrents simultaneously), or (with crap like Joost) no fairness at all. Why should someone who's playing by the "rules" (a few TCP streams) have to compete against users who aren't (many TCP streams or UDP based volume protocols without congestion control)? Flow rate fairness is not user fairness. b: More importantly, in the flat rate pricing world, if a fairness mechanism which allocates traffic between users is such that 90% of the users DON'T experience significant long-term congestion, the ISP is actually properly provisioned, not underprovisioned. It does not make economic sense to up capacity to serve just 5-10% heavy-tail of the users, as those 5-10% of the users aren't paying any more than the 90%. If this is the case, ISPs need to either prevent the heavy-tailed users from affecting the rest (fairness, app-discrimination, usage caps) or charge the heavy users more (usage-based pricing) to justify the cost of an expansion which only benefits these users. _______________________________________________ p2pi mailing list p2pi@ietf.org https://www.ietf.org/mailman/listinfo/p2pi From p2pi-bounces@ietf.org Mon Jun 9 08:53:34 2008 Return-Path: X-Original-To: p2pi-archive@ietf.org Delivered-To: ietfarch-p2pi-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 71B9A3A6C51; Mon, 9 Jun 2008 08:53:34 -0700 (PDT) X-Original-To: p2pi@core3.amsl.com Delivered-To: p2pi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B936A3A6C3D for ; Mon, 9 Jun 2008 08:53:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.999 X-Spam-Level: X-Spam-Status: No, score=-3.999 tagged_above=-999 required=5 tests=[BAYES_50=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wQTTPi049CNQ for ; Mon, 9 Jun 2008 08:53:30 -0700 (PDT) Received: from www.cdt.org (www.cdt.org [72.3.253.41]) by core3.amsl.com (Postfix) with ESMTP id C3EC83A6C11 for ; Mon, 9 Jun 2008 08:53:29 -0700 (PDT) Received: from [10.0.1.43] (66.safeclick.net [63.119.245.66]) (authenticated bits=0) by www.cdt.org (8.12.11.20060308/8.12.11) with ESMTP id m59Frl3M005671 for ; Mon, 9 Jun 2008 11:53:47 -0400 Message-Id: From: Alissa Cooper To: p2pi@ietf.org Mime-Version: 1.0 (Apple Message framework v919.2) Date: Mon, 9 Jun 2008 11:53:48 -0400 X-Mailer: Apple Mail (2.919.2) Subject: [p2pi] More workshop notes X-BeenThere: p2pi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: P2P Infrastructure Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="windows-1252" Content-Transfer-Encoding: quoted-printable Sender: p2pi-bounces@ietf.org Errors-To: p2pi-bounces@ietf.org This is a bit late in coming, but I also took notes at the workshop on = May 28 and wanted to share them with the list (my colleague John = Morris was on the program committee). I tried to capture anything that = wasn't on a slide (and some of what was on the slides if it was = necessary to understand the rest), so my notes ended up quite a bit = longer than Spencer's. I grouped paragraphs and back-and-forths by topic, so a blank line = between paragraphs indicates a shift in the topic of conversation. Being somewhat unfamiliar with the IETF community, there were several = speakers whose names I didn't catch. They are listed simply as = "Speaker" (or "Speaker 1" and "Speaker 2" where they might be confused = for the same person within a back-and-forth). Cheers, Alissa IETF p2pi Workshop May 28, 2008 Cambridge, MA 3.1 Welcome/Note Well/Intro Slides =96 Cullen Jennings Goals for the meeting: 1) Understand the technical problem behind Comcast/BitTorrent 2) Understand what IETF could do about the problem =95 figure out where in IETF this could happen =95 tasks that are feasible to finish =95 engineering, not research or politics =95 applicable to the entire Internet We=92re not dealing with illegal traffic. Jessop (RIAA): We should deal in an engineering sense with illegal = traffic. Cullen: We have a congestion problem either way, and since we=92re = international, illegal/legal distinctions are tricky. 3.2 Comcast - Jason Livingood/Rich Woundy [16] Livingood: Apps providers learning they need to be more friendly, networks = learning they need to be more apps friendly. Comcast=92s commitments: 1) protocol-agnostic network management 2) new focuses on transparency, disclosure, openness, fairness 3) DOCSIS 3.0 roll out Woundy =96 What the Comcast network looks like: In 2005-06 Comcast was getting lots of complaints about Vonage, other = VoIP, some gaming. There was a congested link between Comcast = transport provider and Vonage transport provider in Chicago area. At = the same time, p2p traffic was growing, as was the correlation between = heavy p2p and packet loss. Comcast started managing traffic in 2006 (not an early adopter among = ISPs). Customer complaints dropped as a result. Last official = communication from Vonage was March 2006. DOCSIS architecture: CPE --> CM --> HFC --> CMTS --> onward. CMTS = allocates slots to transmit upstream. A single CMTS serves thousands = of homes, has multiple DOCSIS domains. Usually a domain is single = downstream with a number of upstream links. Limiting resource is typically bandwidth. That=92s what Comcast measures = for capacity planning. CMTS has a notion of mini-slots. Large packets = take up a lot of mini-slots. It=92s not like ATM cells, or like WiFi = where dominant cost is acquiring the link. Some discussion about size = of mini-slots =96 answers offered are 6.25 microseconds worth of time, = 64 bytes (minimum Ethernet MTU), or 16 bytes (according to Google). Any cable modem can make a request to CMTS, with requests randomized = to minimize collisions. CM may piggyback next request in data PDU = (next request is attached to previous data getting sent). CMTS sees = these requests in reliable manner With many CMs trying to do upstream requests, they collide, resulting = in delays. Packet could be queued up to be next packet to CMTS for a = full second. Stanislav: Some motorola cable modems have a 4-second buffer Speaker: If you measure capacity and speed, buffer size is always 32 = or 64 KB. Back to Woundy: It=92s vendor-dependent. DOCSIS specification does not specify. How TCP flow fairness applies in upstream direction is unclear. CMTS = sees a bunch of service flows =96 could be many TCP flows or one (or = UDP). CMTS doesn=92t know source IP, dest IP, etc. until it arrives at = the port, at which point flow has already been transmitted upstream. Key point: With a lot of upstream traffic, piggybacking happens more, = which sends heavy upstream users to front of line, over top of = interactive but less-heavy apps. For example: With MAPs coming down = between 1 and 3 ms, all requests are going through. If we assume = packetization delay for a Vonage customer is 20-30 ms, the queue gets = cleared out. Then when you go back to the request process, you get = back into contention mode. This could explain how heavy users dominate = upstream traffic more than interactive users. A particular cable modem can have multiple service flows. Inbound = traffic can be classified to particular service flow. Take the example = of CM which is also a VoIP endpoint (e.g., for Comcast voice). You can = have a service flow provisioned for voice so that it wouldn=92t go = through the upstream process just described =96 it wouldn=92t need to keep = requesting upstream space. There would be a separate service flow for = regular best efforts. Henning: How can Vonage request to be put in that service flow for VoIP? Woundy: A cable company in Canada lets people pay extra for a service = and it will provision a separate service flow for it (could be used = for Vonage). The other way is to create a service flow on the fly, but = Comcast doesn=92t do this. Cullen: Would looking at the DiffServ bits coming up from the CPE = equipment be enough to classify into two different flows? Woundy: Yes. Speaker: Does Comcast voice service get affected by upstream = congestion? What about for emergency calls? Woundy: Each time transmissions are allowed, we will provision a = reserved lane in next frame for voice. Clark: Can you distinguish between interfering with yourself and = interfering with your neighbor? Which problem do you think you have? = Priority bits solve the first problem, not the second problem. Woundy: We have the neighbor problem. Livingood: Engineering Activities 1) Congestion Management Improvements 2) P2P optimizations =95 near-term: tracker optimizations, caching, p2p client optimizations =95 long-term: signaling from network to clients (increase = localization), signaling from clients to network (can declare yourself = a scavenger service), improved resource allocation 3) DOCSIS 3.0 Speaker 1: We already have ECN and no one uses it. We also could = resurrect scavenger class work. Speaker 2: Woundy said problem is on access link, but tracker = optimizations are for backhaul. And caching only helps on upstream. Woundy: Yes, tracker optimizations are only for backhaul, but we still = have to pay for transit. Caching could improve either upstream or = downstream. Robb: I=92m worried about caching and physical network capacity. Peak-to- = trough ratios will be higher with caches, and there=92s more likelihood = for contention with caches. If contention is from HFC and you=92re = trying to get timeslots on RF network, contention will be greater = because you have caching. Back to Livingood: Will begin rolling out protocol-agnostic network management very soon. = With this new net management, all traffic will be marked =93priority.=94 = When reaching =93near congestion state,=94 we will start marking traffic = down to best efforts. Threshold will be based on usage over certain = length of time (=93Long Duration Bulk Consumption State=94). Length will = be varied in trial. =93Near congestion state=94 can occur on upstream or = downstream. Speaker: What feedback will users get? Anything a user can do to find = out his/her traffic has been marked down to best efforts? Livingood: There=92s no mechanism for feedback right now. Cullen: How do you get out of the penalty box? Livingood: People come out of it quickly, but this is part of what we = want to discover in trial. Henning: I can see how this can be done for downstream. But how do you = lower priority on upstream? Woundy: We=92re creating a new default DOCSIS service flow that has same = provisioned bandwidth but lower priority. Bob: This was an interesting decision to change QoS rather than vary = bandwidth. BT is varying bandwidth allocation on its DSL network. Why = did you chose QoS over reducing bandwidth? Livingood: Reducing bandwidth is perceived negatively by users to = reduce bandwidth. Bob: But with your system, if an app wants to set its own priority, it = has lost that ability, whereas reducing bandwidth doesn=92t affect that. Woundy: If congestion works itself out in 5 or 7 minutes it won=92t be a = problem. Speaker: Will you factor in the subscriber=92s tier? Livingood: If you have 8 Mbit/s downstream service, you=92ll have a = different thresholds than lower service tiers. Henning: So many tweakable parameters! There=92s a lot of work in = autonomic networking, using control theory approaches to adjust = parameters based on feedback. Lots of people want to do this kind of = traffic research, but problem is often unavailability of traffic load = data. Livingood: We want to work with research community on these things. Oran: Does my VPN traffic not get marked down to best efforts when my = son is using p2p upstairs? Woundy: That is a desirable angle, but not something that we will do = this year. DiffServ would be helpful with this. 3.3 BitTorrent - Stanislav Shalunov [22] Most important problem is increased end-user latency. Uplink is = 250-500 KB/s. Buffer is 32-64KB. Cheap devices don=92t do active queue = management (AQM). So TCP fills the buffer, and you end up with a 1-4 = second delay, which is a catastrophe from end-user standpoint. Mostly = you=92re interfering with yourself, but on cable you might affect the = neighborhood. BitTorrent peer selection is very random by design. =93Rarest first=94 is = useful because if original seed goes away, swarm will be able to = continue; max amount of capacity can be registered away from original = seed; and the rarer the pieces you get, the more likely you=92ll have = pieces somebody wants. Tracker doesn=92t track global piece distribution. =93Rarest=94 is out of = the peers that you=92re talking to. The best approximation of global = rarest first is an unbiased random sample. Having a large selection of peers averages out problems. Best peers = can be far away (connect to Japan or campus network). Solving the problem of =93RTT in Seconds:=94 We won=92t get rid of the 4- = second buffer, practically speaking. We won=92t upgrade every end node = in the Internet. But there are practical things that can be done 1) congestion control that avoids filling the buffer 2) scavenger service 3) more explicit congestion notification (not necessarily the two-bit = ECN in IP header) There=92s a good reason to make peer selection random, so everyone = should realize that not doing rarest first is a trade-off. But if we = want to make overlays more efficient, the simplest way would be to = prefer peers in same AS. Since they=92re close, they might be faster. We = have already added the IP to AS mapping table to our client. Not sure = how useful this will be. Could also prefer peers in a set of ASes (ISP could have multiple = ASes), or prefer peers in list of IP prefixes. For both of these, client needs = to know the lists. Could also run a cost minimization algorithm, but we need to know the = costs to do this. We did a case study with the four most popular torrents. With >=3D 20 = peers in an AS, they can just trade with each other. 50% of peers were = in ASes like this. Two thirds of interdomain traffic went away. Note = that user experience could get worse if ASes are asymmetric = (inequality of upload/download) and there=92s a flash crowd. Since the most popular swarm size we had was 9984, the probability of = two peers being in same neighborhood is so low that there=92s no point = in trying out localization on the neighborhood level first. Simple = theories of localization should be tried first, and there should be = substantial gains for doing this kind of localization. Henning: Do you know the swarm size distributions? Stanislav: Looks like polynomial distribution. Straight line on log- = log scale. Not sure about what the tail looks like. Stanislav: If last mile uplink is most expensive part, caching reduces = uplink utilization. Henning: Caches only help if they=92re not part of the HFC, outside the = access network. They can be run by anybody except someone who is on a = cable modem. Back to Stanislav: For 30% hit rate inside 1 AS, cache need to be 1 TB; for 80% hit rate = inside 1 AS, 100 TB. Oran: What=92s the bandwidth on and off the cache? We may not be storage- = limited, we may be hotspot limited. You can=92t just plunk down a 100 TB = cache. BitTorrent congestion control is already in 7 million clients in the = wild. Using delay instead of loss as the metric. Continuously estimate = one-way delay, separating propagation from queuing delay. Ramps up = faster than TCP, but will yield to anything else that is not delay- = based. Approximates scavenger service class with end-to-end congestion = control. Laird: Do you see congestion control as a best practice or standard = technique? Stanislav: It may be useful to standardize an experimental framework = where things are not proprietary. Doesn=92t make sense to standardize = particular settings. Lars: We already have an area in IETF for new congestion control = protocols, this could be presented there. Back to Stanislav: Lower-hanging fruit for this group is DNS-based cache discovery = protocol. Also getting information about the network for smarter peer = selection =96 perhaps an export of something from BGP communities, or = anything that can give clients cost information about different paths. Clark: Back to question of whether you interfere with your neighbors. = CMTS is involved in deciding whether to hand out slots to you or your = neighbor. BitTorrent only works on certain slot allocation algorithms. Oran: I=92d like to know how this looks to a 10x under provisioned DSL = network. Bob: We run a DSL network that doesn=92t have the same problems as cable. Back to Stanislav: IETF could also standardize a way for applications to find cache that = provider might have installed. BitTorrent Engineering Proposal (BEP) = 22, which came out last week, is an attempt to sketch a way of how = this could be done. We want better ideas of how to do it without DNS, = without rewriting packets on the fly. 3.4 Lightning Talks 3.4.1 Robb Topolski [10] P2P doesn=92t really open hundreds of active connections or trick = congestion control. It=92s not designed to take up all bandwidth. We should not rush to solutions before we understand the problems -- = why are networks so congested? Where is the problem? How bad is it, = how often does it occur, how long does it last, what are the trends? = What are the effects and deeper root causes? Can we leverage prior = experiences and insight from the history of the Internet? Quick fixes will only solve a problem for a particular application, = but we should fix problems as close to root as possible. 3.4.2 Nick Weaver [1] P2P does cost-shifting, not cost savings, and it does so = inefficiently. P2P has as much data crossing ISP boundaries as = uncached HTTP traffic, and for unpopular files you always have 2x bits = crossing a boundary as HTTP because of uploading. Caches are not the solution because of legal liability. ISPs also have = no incentive to build caches to help someone shifting costs onto them. 3.4.3 Leslie Daigle [18] We want continued creativity and innovation on the Internet. This = conversation is not strictly about p2p. There is an assumption that a network operator has no incentive to = adjust network to meet demand. We need to leave today understanding what problem we need to solve: =95 Make p2p work better? =95 Is it enough? Or what happens with next kind of app that comes =95 along? =95 Make networks and p2p apps aware of each others=92 requirements? =95 General case of bandwidth-intensive apps, beyond p2p networks? =95 Deal with in-network issues, or impact of cross-network traffic? 3.5 Localization 3.5.1 P4P - Laird Popkin, Haiyong Xie [13/14] Haiyong: Caveats: P4P is not just for p2p. Localization is just a by-product of = p4p, not a goal. It=92s also not a tracker optimization approach. Traditional feedback to apps is limited =96 routing is limited, rate = control through TCP is coarse. At application level, TCP hides = everything except success, failure and responsiveness. We want to = expose more of what=92s going on to apps. Bob: But TCP hides it because it takes care of it. Laird: If I=92m trying to pick peers this might be useful information. P4P Control Plane consists of an iTracker with interfaces for static = topology, policy, provider capability, virtual costs, others (it=92s = extensible). iTracker can be identified through DNS SRV, or run by third parties. Virtual costs are provided by ISPs. Can reflect network status and = policy (OSPF weights, higher costs on links with higher utilization, = etc.). Bob: How dynamic are costs expected to be? Haiyong: We can compute costs by querying the router SNMP database, so = can be very dynamic, or can be more static, it=92s up to the ISP. Laird: One ISP is instrumenting in real time (every 5 minutes). Others = have precomputed daytime vs. nighttime distributions. Communication = channel can update very frequently. Laird: Ran a test with Verizon and another ISP (missed the name?). With = regular p2p, 98% of traffic is from sources external to ISP. With P4P: = 29% local, 21% more internal, 50% external, where =93internal=94 means IP = for both source and dest were within AS of Verizon. =93Local=94 vs. = =93internal=94 was based on map of IPs provided by Verizon. This was a = large swarm =96 35,000 nodes global peak, 1000 nodes after that. 300-500 = peers internally on Verizon. Nick: Would transit across border be same volume as uncached HTTP? Laird: Yes, but nobody pays for transit that way. Back to Laird: P4P is a trade group, not a standards group, so it=92s looking at ways = to extend IETF protocols. A few ideas: =95 trackerless p2p: some mechanism (DNS?) to find iTrackers =95 tracker-based p2p: mechanism for peers to find their ASNs more = easily than IP-lookup mechanism =95 enable p2p to =93play nice=94 =95 enable apps to determine ISP usage policies and consumption against = quota (like cell phone minutes) Jon: Does P4P have its own DNS resource records? Haiyong: It=92s only a proposal. Jon: What about your own TCP header? Anything else you=92re doing with = IETF standards? Laird: The TCP header is for flagging information as being not-time- = sensitive. Henning: The peer discovery aspect relates to many other things (STUN, = geo-location). If we discover things in one way, it makes sense to = leverage that. We shouldn=92t rush to deploy solutions. Laird: We=92re validating the premise, but turning it into a standard = requires a lot more consensus. All we=92ve proved is that localizing = traffic improves performance and reduces cost. 3.5.2 Microsoft - Yu-Shun Wang [12] Localization is useful for several reasons: =95 shifting costs to where we can get comfortable with current = capacity of network =95 mitigate asymmetric capacity provisioning =95 limit traffic within an administrative scope =96 QoS, throttling, = admission control However, localization provides a non-uniform user experience (depends = on your scope or location). Designed a Multi-Layer Tracker-Based Architecture. Global tracker can = delegate or redirect a peer to a local tracker. Provision local caches = among seeds and peers. Nothing to prevent operator from setting up = further sub-trackers. Content server and tracker could sit at same = place (could be a hybrid CDN). Good work for IETF to do may be tracker redirection/delegation. Could = standardize a generic tracker format =96 can think of it in the abstract = as going from global entity to local entity. Haiyong: Don=92t ISPs want to dump traffic off to other ISPs? Why would = they localize? Yu-Shun: What I=92m hearing today is that localization could help. Jon: Localization would not be the sole factor, just something to = balance against other considerations. Speaker: Everyone has a disincentive to do this kind of protocol. Jon: Yu-Shun chopped it up into workable pieces. IETF is not going to = take everything on. The tracker formats look like a good piece. Henning: This is as much an economics problem. If there are incentive = mechanisms available, then we don=92t have to pick one =96 customer care = is a good example. These won=92t be the same everywhere, but there are = plausible incentives out there. Bob: Difficult decision for IETF =96 ISP won=92t want to use this if you = pick all the swarm hosts and work out the costs between them, because = then the ISP is complicit in copyright infringement. Speaker: Is merely answering a localization request about an IP = address a legal issue? Without knowing who requests what? Bob: We need a lawyer. 3.5.3 Vinay Aggrawal [28] P2P is doing what link layer should have been doing (except at app = layer). To us this means we need better ISP-P2P cooperation. ISP knows = bandwidth, geography, service class, OSPF/BGP metrics, distance to = peers, routing policy, etc. Instead of trying to reverse-engineer = these, P2P should be able to find out some of this information. Oracle service is hosted by ISP at known location. It gets list of IPs = from each p2p node, sorts the list, and gives list back to node. = Criteria is up to the ISP. Henning: It would be in the interest of an ISP with upstream problems = is to offload all of them onto Columbia University, and Oracle could = facilitate that. Also, with oracle list mechanism, tracker gives list = of randomly selected nodes =96 swarm can be large but tracker only picks = a small handful to give to oracle. 10 out of 1000s, and you can=92t send = 1000s of IPs to be sorted. Oran: By rooting source at each individual swarm, result is not close = to optimal Steiner tree for entire swarm. Input could instead be = everyone else=92s maps. Laird: What are the scaling properties of this approach? In large = swarm every peer will need a unique recommended list. Vinay: Perhaps tracker could come to Oracle instead of peers dealing = with Oracle. Scaling may need some DNS help for look-ups. Oracle is = designed to be app-independent =96 helps ISPs remain outside copyright = liability. Consulting Oracle also does not imply participation in file- = sharing. Speaker: Need to focus on scalability in light of growth of legal = content. 9000 is not the top end of swarm size. Stanislav: When you first join a swarm you would need to rank about = 200 peers, and once you=92re established (within 1 minute), you will = know of 2500 peers. Jon: Modularity and application-independence are the appeal here. If = IETF can leverage that, there may be a lot we can do. The computation = that an Oracle does would not necessarily be an IETF focus. Speaker: With localization built into routing layer already, this kind = of system can scale even with very large lists. Vinay: One possibility is to standardize the interface for the kinds = of messages that could be sent between ISPs, peers, trackers. Speaker: US and EU both have legal regimes that say caching is = acceptable, as long as it looks just like Web caching. Bob: It=92s not about whether you supply the caching service, but if = you=92re pointing to content, that may be illegal even if you=92re not the = one caching it. Haiyong: Peer ranking is a special case of virtual cost. Could use = virtual cost to rank on the peers. How to handle interdomain ranking? Vinay: Two ways. ISP could rank its own peers first, or could base = ranking on AS number. Or, you could get multiple ISPs working = together, have Oracles send lists to each other. Speaker: When ISP is supposed to expect that clients will magically = follow their guidance, that seems too much to expect. Why would = clients do it? Jon: There is an argument that there is an incentive to do this. 3.5.4 Cullen =96 What could IETF do on localization? [Summary slide from = the morning] Leslie: What problem are we trying to solve? Stanislav: Finding AS numbers is not as valuable as other things that = are on the slide because we already know how to do that. Others: We don=92t know how to do it. Speaker: We=92ve heard about three kinds of things: making clients less = aggressive in bandwidth usage, moving data into caches so it=92s not = consuming uplink and downlink, and variety of ways to open up consumer = backhaul capacity. It=92s important to ask which of these three general = approaches is worthwhile to do. Reducing backhaul doesn=92t seem to be = the highest priority. I=92m terrified of legal issues with caching. Robb: AS number discovery seems like a good idea. Speaker: AS doesn=92t help mobile IP and mobile =96 AS has nothing to do = with where you actually are in the world. Henning: Suggest that we follow the do-no-harm principle. Not = everybody is going to be upstanding. If we provide info that cannot be = verified by end user, can lead to undesirable behavior (hot potato = routing magnified). Don=92t want to provide info to users that gets them = into trouble either. Cullen: What interest is there in standardized tracker formats? Stanislav: Don=92t understand the notion of global tracker. Whatever = local trackers there could be would be in addition to global = (original) tracker? Yu: Take current tracker format and make it recursive, to make = selection easier. Stay within the local tracker once you=92re there (can = fall back to global tracker if necessary). Lisa: HTTP servers often build their own indexes of mirrors in = completely non-standard human-readable formats. This seems like = another use case for this kind of solution. Lars: Don=92t need to do anything new, just deploy what we have. Robb: This is very application-specific. Stanislav: Would be cool to consult another tracker to find other = peers, but for most tracker operators redirecting to other peers/ = trackers is not going to happen. Greg: Why don=92t we consider the mechanism as a whole as being = standardized? IM was successful, but there were boundaries about = interoperability, so we brought it into the IETF. Jon: The manner in which we brought IM into IETF was by modularizing. = We brought in core pieces first to foster interoperability. Lars: Transport area is doing some related stuff, like AQM schemes to = help create shorter queues. Hasn=92t been deployed yet because long = queues weren=92t a problem. Did DiffServ but no incentive to mark stuff = if network doesn=92t respond, and no incentive to respond if end points = don=92t mark. Experimental congestion control for high-speed long-delay = networks is in the works, but nothing stops us from doing friendlier- = than-TCP congestion control. Incentives are better for those sorts of = protocols because they don=92t require network to change with it. Jon: A lot of people in industry talk about localization as a help to = ISPs. People are going to be doing this regardless. Are people = refuting the claim that localization is useful? Speaker: It=92s possible that localization has value, but we had a = specific concern about a particular traffic management practice. Jon: We=92re looking for incrementally beneficial solutions. Livingood: Next month Comcast is starting a localization trial and = will be willing to share a great deal of data. Jon: We need data. Speaker: We have a localization implementation. We need to know who is = requesting localization and who is delivering. Henning: Alternative is to guess at data when we don=92t have data. = Lying about your own AS is detectable. Lying about which IP addr is = closer is hard to detect. Not purely a problem related to p2p, we will = be facing this is p2psip =96 how to find relay nodes so I don=92t go to = Australia to make a call to NY. Bob: Network cannot say what costs are in other networks. Overlay can = talk about costs in whole paths. Shouldn=92t necessarily assume that = network is source of information =96 overlay may be able to furnish that = data across networks. Lisa: Some things are feasible until you try to standardize them. = Localization may be one of them. Some things work when you constrain = it to one ISP and one kind of modem, but not more broadly. Problems = with trust, motivation, and accuracy =96 how could oracles share lists = even when they trust each other? 3.6 Congestion 3.6.1 Bob Briscoe [32] Compare DiffServ and weighted congestion control. IETF shouldn=92t judge = balance of control between network and hosts =96 there is a role for = this to be done on hosts if we get it right DiffServ =95 APIs =95 DiffServ is done without APIs, not done on hosts. =95 App would need to know what the class choices are. =95 Control =95 Need API for apps to be able to do this, otherwise it=92s network- = controlled. =95 Even with APIs, how to know network is complying? =95 Policing =95 Wasn=92t designed to work down to granularity of individual users =95 Could be done by volume? time of day? on-net vs. off-net? =95 But the whole problem is that peak period will shift once it=92s = declared. =95 Totally sender-based, but in p2p world people talk about limiting = download, which is on receiver side. =95 Interconnect =95 if two networks work out deal, and I=92m a light user sending to a = heavy user, I use up my budget to be brought down in their network = because the recipient is getting reduced priority. =95 Moving the problem: with heavy hitters in each class, you end up = with class for every sort of traffic. Weighted Congestion Control =95 APIs =95 Just a matter of setting the weight =96 extension of socket API. =95 Need consensus for it to be portable across OSes. =95 IETF doesn=92t standardize socket APIs typically. =95 Control =95 Unambiguously with the host. =95 Policing =95 Why not always set weight to max? how to deal with this? =95 Don=92t want light traffic bursts to puncture real-time apps. =95 Sender-based issue just life DiffServ. There are a few features of good solutions. ISP should not have to = fiddle around inside the user=92s envelope (but this doesn=92t mean ISPs = can=92t offer optional prioritization). There should also be no =93wriggle- = room=94 for suspicion about what ISP is doing. We can view congestion as a harm (cost) metric, where the cost equals = the amount of data that wasn=92t served to its destination. This follows = =93no wriggle-room=94 =96 cost is greatest when peaks are greatest. Using = this metric can allow for a policy that says not to send too much data = during congestion, without specifying exactly how much. Danny: Can you relate this metric to Comcast=92s metric? Part of = thinking about what is important to do from standardization = perspective has to take into account what is going to be done by ISPs. Bob: Two ways of looking at it. One is to set volume limits = arbitrarily, but other is to set limits based on lengths of queues. ISPs can=92t limit what the can=92t see. Need to give information about = gaps to the network. This is the idea behind re-ECN, which makes it in = sender=92s interest to reveal the congestion it knows about. Quick fixes need to be compatible with long-term goals. IETF/IRTF = should setup longer-term design team to asses the general resource = sharing problem and the long-term effects of any proposed quick fixes. Lars: You did not mention p2p, which suggests that the problems that = we have are with massive uses of bandwidth, not just p2p. 3.6.2 Marcin Matuszewski Interviewed 20 ISPs. Their profit margins are low, with acquisition = cost higher than monthly revenue. Cost structure varies (fixed vs. = mobile). Heavy users are a perceived problem. Tools available to ISPs (though none widely used): volume-based = accounting, fixed price up to certain volume, shaping/blocking/ = charging for excessive traffic, higher priority assigned to new flows, = DPI, adding capacity, limiting subscriber flows, banning servers from = residential access, superpeers/content caches, blocking heavy users. Bob: BT=92s retail department uses DPI and they=92re open about it, and = they think it=92s 10x more cost effective than adding bandwidth. Conclusion: heavy hitters are a business/marketing problem, not a = technical problem. 3.7 QoS 3.7.1 Mary Barnes [24] DPI and traffic analysis are not viable in long term. DiffServ Code = Points (DSCP) could be helpful. DS devices at edges mark packets so nodes don=92t need to remember. This = could support charging based on usage, which would be helpful. Peterson: How does DSCP particularly lend itself to the p2p problem = space? Bob: P2P traffic is less than it used to be, relative to stream = traffic. Problem has been around for 7 years, why the rush to solve it = now? Jon: Because of what happened last year. Clark: Academics have done a lot of hand-wringing about lack of DS = deployment, but DS is used in 50% of Cisco enterprise customers. We = have an economic problem to solve on the broader internet. Oran: Actually it=92s larger than that now because VoIP is so popular. = But some DSL networks are just not ready for DS. There are not a lot = of layer 2 people in the room, but there are severe problems in layer = 2 networks. How do you trust the markings for DS? That issue will = cause everything to come to a screeching to a halt. Mary: That=92s a common problem to a lot of these solutions. Robb: Incentive for a host to do the right thing needs to be because = it will benefit him to do the right thing. 3.7.2 Henning Schulzrinne [25] Just minimizing cost to network provider while maximizing cost to = content provider doesn=92t help because content provider will just move = networks. It=92s most useful to talk about total cost of delivery, including cost = of media storage, media server bandwidth, and delivery bandwidth. Do = you re-use existing components or use new components (e.g., personal = DVR vs. cache)? Rational cost shifting exists where people who can save the money = funnel savings to those who can=92t save the money. Rentable caches are = an example =96 ISPs get paid to lend storage area so they are incented = to keep caches. In some versions this is the Akamai model. Transit bandwidth has flattened out, is no longer getting cheaper. = Cost of providing content must take into account different costs on = different links (costs look like a step function). Bob: Cost of empty links is different than cost with traffic on the = links. Whether you use long link or short link if it=92s empty you pay = the same. Henning: Assume an end-user centric model where you buy bandwidth by = the bit. The price that is charged to the customer and the price you = pay for transit are not the same. In a fixed-price market there is not = incremental cost. Each additional bit costs nothing until you reach = capacity. Congestion doesn=92t play a factor in cost today =96 you pay the = same amount of money regardless of congestion on the link. Bob: That is only true in the US. Back to Henning: One question is whether localization matters with long tails. One = percent of the U.S. population saw Superbad on one weekend. If this = was VoD, each neighborhood would have a copy. With diurnal variations on some networks, average verses peak times = doesn=92t leave much left to shift demand around. On Columbia network = only trough is in early morning. There=92s a general discovery problem for things like STUN, HELD, LoST, = SIP local network config. These could all be informed by ISP. There = are a number of discovery mechanisms: DHCP, DNS (SRV, NAPTR), anycast. Scavenger service helps avoid self-interference and requires no = admission control =96 can only do worse than you were doing before. The = missing piece is to define the code point -- don=92t want to hand code = for each network. For volume-based pricing, we need application-visible charging = indicator. App could offer to defer a data transfer until later when = bandwidth gets cheaper. Perhaps IETF could help here? Although = business models are infinite. Also, charging or rate-limiting exposes = users to risk of malware running up your traffic bill. Conclusion: simple mechanisms are needed that help prevent self- = interference and work for both symmetric and asymmetric. We also need = more data about content distribution. 3.8 Conclusion and Wrap-Up Jon: This idea of a generalized way to talk to your local network = keeps coming up. Henning: It would be useful to be able to ask a node how close I am to = the limit. Speaker: VoD costs or the quality of a VoIP call are all application- = specific. Too hard to create generic transport-layer framework. Henning: The ability to query local network provider to be able to = detect what I=92m getting myself into can be generic. Right now service = providers cannot easily add metered services that are observable by a = user (like electricity). Without a meter, you have no scalable way to = built apps. Jon: Even in P4P, ability for service providers to express policy is = at the root of this. We want to extract out where the policies come = from, interconnection charges, etc. Abstract it into a black box or = express it as a consequence. Speaker: Network can say it=92s expensive or not, but not sure how much = more granular we can get. Cullen: We heard people saying there would be bandwidth caps. = Scavenger class might be worth implementing if it doesn=92t count = against your bandwidth limit. Robb: Two issues: congestion and cost. Congestion in last mile is a = technical issue. Cost issue is a choice or decision not to part with = your money. Jon: But they=92re related. Robb: But the root cause matters. No reasonable amount of money will = solve the congestion problem. But the existence of available bandwidth = that is unused is a cost issue. Congestion control doesn=92t fix the = cost issue. When we don=92t continue to grow the network, we=92re just = deciding how to order the packets at a gateway. IETF should decide = what is strictly within business purview. IETF should focus on = congestion issues. Jon: This does not all fall into one bucket. People have raised the = problem of how to make inelastic traffic compete reasonably with = elastic traffic. Danny: Big divide here in design areas to work in =96 pricing/signaling = about what things cost and signaling about congestion and fairness = behavior. There=92s a long history of failure to match up network = protocols with economic terms, so I=92m wary of the first bucket. Skype = figured it out, but it=92s very hard to get it right (think = micropayments). P3P tried to get between social and economic = interactions and we didn=92t get it right. More modest task of signaling = fairness is more realistic. Jon: Where does scavenger class fall? Danny: If marking is related to action ISP will take, it=92s in the = first category. If it=92s proposed as a currency, it=92s in second category. Clark: I=92m uncomfortable with division between cost and congestion. = Congestion which arises when there=92s a scarcity needs to be resolved = through some cost mechanism. People seem to be making value judgments = that a p2p person will suffer less than other people. If in times of = congestion I get to use the network and you don=92t, you paid because = you didn=92t get to use it (exclusion). Can push back by asking users to = pay, or slow down. Distinction between cost and congestion is false. = ISPs are adding more capacity =96 they=92re paying to relieve congestion. = Many cost propositions haven=92t worked, but that doesn=92t mean they = won=92t in the future. Danny: There=92s a relationship between congestion and cost. We don=92t = understand it or how to communicate it in a transparent manner, and = that=92s the challenge. Cost questions may get worked out out-of-band = from here. Bob: If congestion isn=92t limited, then cost and congestion aren=92t the = same thing. When congestion becomes part of the contract of what = you=92re not meant to do, then they become the same thing. Because an = operator can=92t see congestion, it can=92t make it part of the contract. = Can=92t see congestion that user is causing elsewhere. Speaker: An IRTF workgroup should go back to economics. In economics = pricing is a protocol. It indicates when we should spend money. The = problem we have is that people have discovered the Internet =96 = assumption was that grandma would get a big web page back, but now she = has a server. Greg: There are a decent number of people interested in looking at = caching, at least as a superpeer. Optimizing peer selection is = something IETF could look at. I also encourage us to look at bringing = the entire thing in, like with SSL and Jabber. As a vendor, DSCP is = costly because whatever is in provider edge box has to do application = identification in order to trust DS markings. Cullen: Latest Windows Vista API is one where voice traffic is marked = CS7, above priority reserve for router traffic. Every switch is going = to have to remark all traffic from all Windows boxes, which means = every box because you can=92t distinguish a Windows box. Nick: We might end up in a situation where every party is not = necessarily happy. Instead the question is how to minimize damage in = war between ISPs and p2p. Notions towards user fairness enforced in = the network are where IETF should focus. That seems to be the least = unpleasant for users who aren=92t heavy users. Bandwidth caps, etc. = cause those people harm. Other Danny (not Weitzner): I agree with Nick. IETF might want to = consider application employment of transport layer functions =96 apps = opening all those TCP connections isn=92t necessarily a good thing. IETF = could say something about that. Mentality on mobile side =96 nights, = weekends, distances for billing. All of this is transparent on = network, but it costs more to deliver bits further away, and some ISPs = are thinking about pricing based on some of these factors. Lars: RFC 2914 explains what congestion control is good for. 1) Back = off and, 2) being sort of fair to other users. Much of what we brought = up today is not specific to p2p. If you=92re a heavy user and you build = up a queue, you will have delay =96 same for IPTV. I wonder if we can = isolate these problems away from p2p. Also fairness =96 need to deal = with heavy vs. light whether you=92re using p2p or not. Jon: Coming back to modularity and how to unify the modules. All the = components we=92ve talked about add up to p2p system. Lars: No, the current cause is p2p. In the future the cause could be = other things. Solving them for p2p might not solve them for next thing. Laird: Issue of p2p opening lots of connections should end up in = summary notes. Stanislav: Multiple connections is not the cause of the problems. If = you open one connection, you will get same delay that=92s equal to = buffer size in bottleneck link divided by bitrate of bottleneck link. = Caused by Facebook photo uploader in same way as BitTorrent. Nick: That is only true if you are the only person the link. With = multiple users sharing one link, TCP flow fairness gives people with = multiple open connections a larger portion of the bandwidth. Users = with multiple torrents open can saturate the network. Cullen: Gmail, Gmaps, Mosaic browser use 4-5 TCP connections. It=92s not = specific to BitTorrent. Nick: How BitTorrent is commonly used by users is 4 flows per torrent = with multiple torrents. Oran: There are non-evil reasons to open multiple connections and you = can=92t tell the difference. Stanislav: Piece dissipation is the reason for opening multiple = connections. If you only trade with one person you end up with = disjoint pairs. Your graph looks better with 3-4 peers. Livingood: Ted Hardie talked about unattended apps =96 it=92s not just = p2p. P2P is as important as all the other apps out there. Bob: I=92m not saying multiple flows is a problem =96 the internet is a = problem because it can=92t judge how many flows people are using. Jon: If we do not solve the problem for p2p, then we have not solved = the problem. _______________________________________________ p2pi mailing list p2pi@ietf.org https://www.ietf.org/mailman/listinfo/p2pi From p2pi-bounces@ietf.org Mon Jun 9 09:00:26 2008 Return-Path: X-Original-To: p2pi-archive@ietf.org Delivered-To: ietfarch-p2pi-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 96E5C3A6917; Mon, 9 Jun 2008 09:00:26 -0700 (PDT) X-Original-To: p2pi@core3.amsl.com Delivered-To: p2pi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 522D13A68E3 for ; Mon, 9 Jun 2008 09:00:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M23RsT8yG4jL for ; Mon, 9 Jun 2008 09:00:19 -0700 (PDT) Received: from voxeo.com (mmail.voxeo.com [66.193.54.208]) by core3.amsl.com (Postfix) with ESMTP id 38E773A6C98 for ; Mon, 9 Jun 2008 09:00:19 -0700 (PDT) Received: from [66.65.228.203] (account dyork HELO pc-00144.lodestar2.dyndns.org) by voxeo.com (CommuniGate Pro SMTP 5.1.14) with ESMTPSA id 31650756; Mon, 09 Jun 2008 16:00:37 +0000 Message-Id: From: Dan York To: Alissa Cooper In-Reply-To: Mime-Version: 1.0 (Apple Message framework v924) Date: Mon, 9 Jun 2008 12:00:35 -0400 References: X-Mailer: Apple Mail (2.924) Cc: p2pi@ietf.org Subject: Re: [p2pi] More workshop notes X-BeenThere: p2pi@ietf.org X-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 Alissa, On Jun 9, 2008, at 11:53 AM, Alissa Cooper wrote: > This is a bit late in coming, but I also took notes at the workshop on > May 28 and wanted to share them with the list (my colleague John > Morris was on the program committee). I tried to capture anything that > wasn't on a slide (and some of what was on the slides if it was > necessary to understand the rest), so my notes ended up quite a bit > longer than Spencer's. Wow! MANY thanks for sharing such detailed notes. For those of us who could not attend the actual meeting this is extremely useful. Thank you! 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 Mon Jun 9 09:21: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 786483A6A9A; Mon, 9 Jun 2008 09:21: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 882013A6976 for ; Mon, 9 Jun 2008 09:21:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Fv8ZK5Urplp5 for ; Mon, 9 Jun 2008 09:21:15 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by core3.amsl.com (Postfix) with ESMTP id 7760E3A69FA for ; Mon, 9 Jun 2008 09:21:15 -0700 (PDT) Received: from [127.0.0.1] (87.sub-75-215-153.myvzw.com [75.215.153.87]) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id m59GKvp5008495 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 9 Jun 2008 09:21:00 -0700 (PDT) Message-ID: <484D5868.9000209@isi.edu> Date: Mon, 09 Jun 2008 09:20:56 -0700 From: Joe Touch User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: Nicholas Weaver References: <06BEE447-3D17-45D0-A73B-E248C3141F51@ICSI.Berkeley.EDU> <484C1958.2010900@isi.edu> <8719C03C-9EC9-482B-9536-1784F95DC8A8@ICSI.Berkeley.EDU> <484CC2A5.6050105@isi.edu> <1621FECD-ED33-4BF2-88D0-199D6FA75993@ICSI.Berkeley.EDU> <484D2DE8.7020407@isi.edu> <4D7FB692-F754-4DD7-A63C-BA96C5FF5E05@ICSI.Berkeley.EDU> <484D450E.4060806@isi.edu> <86DEA620-3C64-4C5D-A2A6-C4CD064B5AE1@ICSI.Berkeley.EDU> In-Reply-To: <86DEA620-3C64-4C5D-A2A6-C4CD064B5AE1@ICSI.Berkeley.EDU> X-Enigmail-Version: 0.95.6 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: p2pi@ietf.org Subject: Re: [p2pi] One more proposed definition of fairness... X-BeenThere: p2pi@ietf.org X-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="===============1569279017==" Sender: p2pi-bounces@ietf.org Errors-To: p2pi-bounces@ietf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============1569279017== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigDC0B0F7D32C4F0F7AFCC9316" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigDC0B0F7D32C4F0F7AFCC9316 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Nicholas Weaver wrote: >=20 > On Jun 9, 2008, at 7:58 AM, Joe Touch wrote: >>>>> >>>> >>>> Maybe I'm missing something, but if I have one ISP, I paid for THOSE= =20 >>>> bits too. How I use them is up to me, not the ISP. >>> I don't see what our disagreement is. Users paying for multiple=20 >>> accounts get more bandwidth, and as ISP A doesnt' see the packets=20 >>> going through ISP-B, it doesn't matter to A what they are doing=20 >>> elsewhere. >> >> We agree on that. We agree that if I pay two ISPs for BW, I get to use= =20 >> both. Do you agree that if I pay one ISP for BW, I get to use it - all= =20 >> of it? (i.e., if this is about ISP internal congestion, then the ISP=20 >> is at fault for underprovisioning, not the user) >> >> I get the impression that if an ISP has upstream congestion, you think= =20 >> it gets to limit the number of flows I send; I think that my packets=20 >> can get dropped due to congestion, but it's not useful for the ISP to = >> have a different notion of 'fairness' than the endpoint. >=20 > Actually, I disagree here, for the following reason: >=20 > a: The endpoints have a proven in practice bad notion of fairness: =20 > They have TCP flow fairness (which can and is abused by some users, who= =20 > eg, transfer on many torrents simultaneously), or (with crap like Joost= )=20 > no fairness at all. Why should someone who's playing by the "rules" (a= =20 > few TCP streams) have to compete against users who aren't (many TCP=20 > streams or UDP based volume protocols without congestion control)? >=20 > Flow rate fairness is not user fairness. Right. But what is enforced depends on what the user paid for... > b: More importantly, in the flat rate pricing world, if a fairness=20 > mechanism which allocates traffic between users is such that 90% of the= =20 > users DON'T experience significant long-term congestion, the ISP is=20 > actually properly provisioned, not underprovisioned. >=20 > It does not make economic sense to up capacity to serve just 5-10%=20 > heavy-tail of the users, as those 5-10% of the users aren't paying any = > more than the 90%. I don't care what "economic sense" it made for the ISP. If it sold me X=20 Mbps, it had better provide that. If there's upstream congestion, that's = another issue, of course. But if not, if you sell me X Mbps, I had=20 better get it. > If this is the case, ISPs need to either prevent the heavy-tailed users= =20 > from affecting the rest (fairness, app-discrimination, usage caps) or=20 > charge the heavy users more (usage-based pricing) to justify the cost o= f=20 > an expansion which only benefits these users. AND define what they're selling better. Don't sell me a gallon of gas=20 which is a gallon UNLESS there's a run on gasoline. I don't care about=20 *your* economic implications of heavy-tails on your provisioning model.=20 I care about getting what I paid for. Once I pay for X Mbps, you can throttle ALL my stuff, but not just TCP,=20 and not per-flow or anything else. If you do, you're not selling me=20 Internet access, you're selling me a single TCP connection or somesuch,=20 and nobody would buy that. Joe --------------enigDC0B0F7D32C4F0F7AFCC9316 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFITVhpE5f5cImnZrsRAoUeAJ9csKQ6yqItsjI2z5xw24mlBylPqgCcCKLM JDw1Vn0qe3qgaPIgAMWArxo= =AMN1 -----END PGP SIGNATURE----- --------------enigDC0B0F7D32C4F0F7AFCC9316-- --===============1569279017== 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 --===============1569279017==-- From p2pi-bounces@ietf.org Mon Jun 9 09:49: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 6471B3A6B22; Mon, 9 Jun 2008 09:49: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 7E7CA3A6B22 for ; Mon, 9 Jun 2008 09:49:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.322 X-Spam-Level: X-Spam-Status: No, score=-6.322 tagged_above=-999 required=5 tests=[AWL=0.277, 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 HMUHA8jBRuww for ; Mon, 9 Jun 2008 09:49:46 -0700 (PDT) Received: from fruitcake.ICSI.Berkeley.EDU (fruitcake.ICSI.Berkeley.EDU [192.150.186.11]) by core3.amsl.com (Postfix) with ESMTP id 73E0D3A68D7 for ; Mon, 9 Jun 2008 09:49:43 -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 m59Go0Cf003778; Mon, 9 Jun 2008 09:50:00 -0700 (PDT) Message-Id: <5C7D6FCF-4CF7-425E-8A17-A60DB8F07272@ICSI.Berkeley.EDU> From: Nicholas Weaver To: Joe Touch In-Reply-To: <484D5868.9000209@isi.edu> Mime-Version: 1.0 (Apple Message framework v924) Date: Mon, 9 Jun 2008 09:50:00 -0700 References: <06BEE447-3D17-45D0-A73B-E248C3141F51@ICSI.Berkeley.EDU> <484C1958.2010900@isi.edu> <8719C03C-9EC9-482B-9536-1784F95DC8A8@ICSI.Berkeley.EDU> <484CC2A5.6050105@isi.edu> <1621FECD-ED33-4BF2-88D0-199D6FA75993@ICSI.Berkeley.EDU> <484D2DE8.7020407@isi.edu> <4D7FB692-F754-4DD7-A63C-BA96C5FF5E05@ICSI.Berkeley.EDU> <484D450E.4060806@isi.edu> <86DEA620-3C64-4C5D-A2A6-C4CD064B5AE1@ICSI.Berkeley.EDU> <484D5868.9000209@isi.edu> X-Mailer: Apple Mail (2.924) Cc: p2pi@ietf.org, Nicholas Weaver Subject: Re: [p2pi] One more proposed definition of fairness... X-BeenThere: p2pi@ietf.org X-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 Jun 9, 2008, at 9:20 AM, Joe Touch wrote: >>> >> Actually, I disagree here, for the following reason: >> a: The endpoints have a proven in practice bad notion of >> fairness: They have TCP flow fairness (which can and is abused by >> some users, who eg, transfer on many torrents simultaneously), or >> (with crap like Joost) no fairness at all. Why should someone >> who's playing by the "rules" (a few TCP streams) have to compete >> against users who aren't (many TCP streams or UDP based volume >> protocols without congestion control)? >> Flow rate fairness is not user fairness. > > Right. But what is enforced depends on what the user paid for... > >> b: More importantly, in the flat rate pricing world, if a fairness >> mechanism which allocates traffic between users is such that 90% of >> the users DON'T experience significant long-term congestion, the >> ISP is actually properly provisioned, not underprovisioned. >> It does not make economic sense to up capacity to serve just 5-10% >> heavy-tail of the users, as those 5-10% of the users aren't paying >> any more than the 90%. > > I don't care what "economic sense" it made for the ISP. If it sold > me X Mbps, it had better provide that. If there's upstream > congestion, that's another issue, of course. But if not, if you sell > me X Mbps, I had better get it. Fairness only needs to be enforced when there is congestion. So what's the problem? No congestion, you get your X Mbps. Your bits flow and you are happy. With congestion, you get a defined fair allocation, averaged out over say, 1 second to 1 hour. >> If this is the case, ISPs need to either prevent the heavy-tailed >> users from affecting the rest (fairness, app-discrimination, usage >> caps) or charge the heavy users more (usage-based pricing) to >> justify the cost of an expansion which only benefits these users. > > AND define what they're selling better. Don't sell me a gallon of > gas which is a gallon UNLESS there's a run on gasoline. I don't care > about *your* economic implications of heavy-tails on your > provisioning model. I care about getting what I paid for. > > Once I pay for X Mbps, you can throttle ALL my stuff, but not just > TCP, and not per-flow or anything else. If you do, you're not > selling me Internet access, you're selling me a single TCP > connection or somesuch, and nobody would buy that. If you want X no matter what anyone else is doing, you buy business grade service with an SLA and lose statistical multiplexing. Just be prepared for sticker shock. There is a reason such a product is not sold to consumers: statistical multiplexing is a huge win in cost-savings, but it means you can only guarentee a number much MUCH smaller than X. EG, Lariat is very open about their pricing and does provide such guarentees. Going from a guarenteed 256 Kbps to a guarenteed 512 Kbps doubles your cost from $40 to $80 [1]! If, instead, you REQUIRE that an ISP allocate a 16 Mbps channel for your exclusive usage, you would see the bill jump by 5x-10x easily. So yes, you should care about your ISP's cost and business model. Even if they have a 50% profit margin, any change which would up their costs by a factor of 10, and they only passed on the actual costs, would see your bill jump by 5x! Also, with all the pushback against fairness, I see way the ISPs want to go to bandwidth caps and bill-released bandwidth caps instead: Rather than trying to make the network work with the 5%ers, just cut off the 5%ers! If it happens to disrupt video-on-demand services (which it will, bigtime), consider it a bonus. [1] And its not like thats pure profit either. Brett Glass is open about his own prices, and claims that it costs him $100/Mbps-month, so the MINIMUM price difference for the differentiation in service has to be at least $25. _______________________________________________ p2pi mailing list p2pi@ietf.org https://www.ietf.org/mailman/listinfo/p2pi From p2pi-bounces@ietf.org Mon Jun 9 10:23:52 2008 Return-Path: X-Original-To: p2pi-archive@ietf.org Delivered-To: ietfarch-p2pi-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 26F173A6ADA; Mon, 9 Jun 2008 10:23:52 -0700 (PDT) X-Original-To: p2pi@core3.amsl.com Delivered-To: p2pi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B9B063A6ADA for ; Mon, 9 Jun 2008 10:23:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2XA90phHsn8z for ; Mon, 9 Jun 2008 10:23:50 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by core3.amsl.com (Postfix) with ESMTP id D0D703A6A83 for ; Mon, 9 Jun 2008 10:23:50 -0700 (PDT) Received: from [127.0.0.1] (176.sub-75-214-131.myvzw.com [75.214.131.176]) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id m59HNLTl001741 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 9 Jun 2008 10:23:24 -0700 (PDT) Message-ID: <484D6704.7050208@isi.edu> Date: Mon, 09 Jun 2008 10:23:16 -0700 From: Joe Touch User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: Nicholas Weaver References: <06BEE447-3D17-45D0-A73B-E248C3141F51@ICSI.Berkeley.EDU> <484C1958.2010900@isi.edu> <8719C03C-9EC9-482B-9536-1784F95DC8A8@ICSI.Berkeley.EDU> <484CC2A5.6050105@isi.edu> <1621FECD-ED33-4BF2-88D0-199D6FA75993@ICSI.Berkeley.EDU> <484D2DE8.7020407@isi.edu> <4D7FB692-F754-4DD7-A63C-BA96C5FF5E05@ICSI.Berkeley.EDU> <484D450E.4060806@isi.edu> <86DEA620-3C64-4C5D-A2A6-C4CD064B5AE1@ICSI.Berkeley.EDU> <484D5868.9000209@isi.edu> <5C7D6FCF-4CF7-425E-8A17-A60DB8F07272@ICSI.Berkeley.EDU> In-Reply-To: <5C7D6FCF-4CF7-425E-8A17-A60DB8F07272@ICSI.Berkeley.EDU> X-Enigmail-Version: 0.95.6 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: p2pi@ietf.org Subject: Re: [p2pi] One more proposed definition of fairness... X-BeenThere: p2pi@ietf.org X-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="===============0969707214==" Sender: p2pi-bounces@ietf.org Errors-To: p2pi-bounces@ietf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============0969707214== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigB7B01D7A66C998F66B91FEC7" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigB7B01D7A66C998F66B91FEC7 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Nicholas Weaver wrote: =2E.. > With congestion, you get a defined fair allocation, averaged out over=20 > say, 1 second to 1 hour. =2E.. > If you want X no matter what anyone else is doing, you buy business=20 > grade service with an SLA and lose statistical multiplexing. Just be=20 > prepared for sticker shock. That was the telco's argument in the 1980s when modems shot 50+ years of = erlang analysis out the window; in the end, they *reprovisioned* to=20 accommodate the reality of what they were selling - and the prices=20 didn't change all that much. IMO, ISPs are headed down this path too. I don't care much that the=20 current realities don't match their outdated provisioning models, any=20 more than I care that the cable co's initially mis-guessed the ratio of=20 uplink to downlink BW. Joe --------------enigB7B01D7A66C998F66B91FEC7 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFITWcIE5f5cImnZrsRAhb3AJ40X3i+sM0H2kkSOW+MnYULBrwx4ACgx4ra 1hjXRiUzJrOWxOUQVOR4ZtQ= =G4Vj -----END PGP SIGNATURE----- --------------enigB7B01D7A66C998F66B91FEC7-- --===============0969707214== 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 --===============0969707214==-- From p2pi-bounces@ietf.org Mon Jun 9 10:35:56 2008 Return-Path: X-Original-To: p2pi-archive@ietf.org Delivered-To: ietfarch-p2pi-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 773DC3A69B5; Mon, 9 Jun 2008 10:35:56 -0700 (PDT) X-Original-To: p2pi@core3.amsl.com Delivered-To: p2pi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 64B7B3A67FB for ; Mon, 9 Jun 2008 10:35:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.338 X-Spam-Level: X-Spam-Status: No, score=-6.338 tagged_above=-999 required=5 tests=[AWL=0.261, 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 yNzYEiLGmfnC for ; Mon, 9 Jun 2008 10:35:54 -0700 (PDT) Received: from fruitcake.ICSI.Berkeley.EDU (fruitcake.ICSI.Berkeley.EDU [192.150.186.11]) by core3.amsl.com (Postfix) with ESMTP id 317983A68C1 for ; Mon, 9 Jun 2008 10:35:54 -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 m59HaAtc013402; Mon, 9 Jun 2008 10:36:10 -0700 (PDT) Message-Id: From: Nicholas Weaver To: Joe Touch In-Reply-To: <484D6704.7050208@isi.edu> Mime-Version: 1.0 (Apple Message framework v924) Date: Mon, 9 Jun 2008 10:36:08 -0700 References: <06BEE447-3D17-45D0-A73B-E248C3141F51@ICSI.Berkeley.EDU> <484C1958.2010900@isi.edu> <8719C03C-9EC9-482B-9536-1784F95DC8A8@ICSI.Berkeley.EDU> <484CC2A5.6050105@isi.edu> <1621FECD-ED33-4BF2-88D0-199D6FA75993@ICSI.Berkeley.EDU> <484D2DE8.7020407@isi.edu> <4D7FB692-F754-4DD7-A63C-BA96C5FF5E05@ICSI.Berkeley.EDU> <484D450E.4060806@isi.edu> <86DEA620-3C64-4C5D-A2A6-C4CD064B5AE1@ICSI.Berkeley.EDU> <484D5868.9000209@isi.edu> <5C7D6FCF-4CF7-425E-8A17-A60DB8F07272@ICSI.Berkeley.EDU> <484D6704.7050208@isi.edu> X-Mailer: Apple Mail (2.924) Cc: p2pi@ietf.org, Nicholas Weaver Subject: Re: [p2pi] One more proposed definition of fairness... X-BeenThere: p2pi@ietf.org X-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 Jun 9, 2008, at 10:23 AM, Joe Touch wrote: > > IMO, ISPs are headed down this path too. I don't care much that the > current realities don't match their outdated provisioning models, > any more than I care that the cable co's initially mis-guessed the > ratio of uplink to downlink BW. And if that is the case, a fairness discipline doesn't work, and will tell you empirically that you actually are underprovisioned for the majority of your users, not just the 5% heavy-tail. _______________________________________________ p2pi mailing list p2pi@ietf.org https://www.ietf.org/mailman/listinfo/p2pi From p2pi-bounces@ietf.org Mon Jun 9 10:46:33 2008 Return-Path: X-Original-To: p2pi-archive@ietf.org Delivered-To: ietfarch-p2pi-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4789228C1A1; Mon, 9 Jun 2008 10:46:33 -0700 (PDT) X-Original-To: p2pi@core3.amsl.com Delivered-To: p2pi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F049528C19C for ; Mon, 9 Jun 2008 10:46:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[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 olfncjSoZDKg for ; Mon, 9 Jun 2008 10:46:30 -0700 (PDT) Received: from mout.perfora.net (mout.perfora.net [74.208.4.194]) by core3.amsl.com (Postfix) with ESMTP id D631C28C1A0 for ; Mon, 9 Jun 2008 10:46:29 -0700 (PDT) Received: from viceroy (natint3.juniper.net [66.129.224.36]) by mrelay.perfora.net (node=mrus1) with ESMTP (Nemesis) id 0MKpCa-1K5lS90ygA-0004D3; Mon, 09 Jun 2008 13:46:48 -0400 From: "Stas Khirman" To: "'Nicholas Weaver'" , "'Joe Touch'" References: <06BEE447-3D17-45D0-A73B-E248C3141F51@ICSI.Berkeley.EDU><484C1958.2010900@isi.edu><8719C03C-9EC9-482B-9536-1784F95DC8A8@ICSI.Berkeley.EDU><484CC2A5.6050105@isi.edu><1621FECD-ED33-4BF2-88D0-199D6FA75993@ICSI.Berkeley.EDU><484D2DE8.7020407@isi.edu><4D7FB692-F754-4DD7-A63C-BA96C5FF5E05@ICSI.Berkeley.EDU><484D450E.4060806@isi.edu> <86DEA620-3C64-4C5D-A2A6-C4CD064B5AE1@ICSI.Berkeley.EDU> Date: Mon, 9 Jun 2008 10:46:44 -0700 Message-ID: <008a01c8ca58$cacf3890$710d11ac@jnpr.net> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <86DEA620-3C64-4C5D-A2A6-C4CD064B5AE1@ICSI.Berkeley.EDU> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Thread-Index: AcjKRq4/djiuenQ8RESRYp5mfHqdhAACf8NQ X-Provags-ID: V01U2FsdGVkX1/qLp9L+8t9hR/+D430Kw7lNkgVnlj5w9d+vC8 h1Y10eyYP7QH4PccIxu9Z2SSCiIU65dKc9qJ/SBQkZrvCj/1FB rB2knIJI/JQZG3NXaisNQ== Cc: p2pi@ietf.org Subject: Re: [p2pi] One more proposed definition of fairness... X-BeenThere: p2pi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: P2P Infrastructure Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: p2pi-bounces@ietf.org Errors-To: p2pi-bounces@ietf.org > From: p2pi-bounces@ietf.org [mailto:p2pi-bounces@ietf.org] On Behalf Of > > It does not make economic sense to up capacity to serve just 5-10% > heavy-tail of the users, as those 5-10% of the users aren't paying any > more than the 90%. > > If this is the case, ISPs need to either prevent the heavy-tailed > users from affecting the rest (fairness, app-discrimination, usage > caps) or charge the heavy users more (usage-based pricing) to justify > the cost of an expansion which only benefits these users. > [Stas Khirman] As matter of fact, ANY flat rate resource sharing system will have 5% of "heavy" users consuming 50% of shared resource - it is just a special case of famous 20/80 Pareto observation. It is observed in any kinds of flat-rate/free services - from broadband ISP, dial-up , local phone service, NetFlix down to local library or "all-you-can-eat" buffet. Serving those 5% of "heavy users" is a part of economical sense of flat-rate - their overuse of shared resource is well sponsored by the monthly fee of the 95% "light users". And certainly, it is not "fair" - flat-rate can't be fair on any level as charges are not reflecting your specific use of the service. BTW, I do not see ISP are suggesting to give back some discounts to 80% of "light users" who use less then 20% of total resources - it will certainly make no economical sense to ISP despite obvious fairness . As long as service providers use flat-rate pricing model they have to plan servicing 5% of "heavy" users - they ALWAYS have this group in population mix. Another question, what will be maximum resource consumption by this group. In case of buffet or library, maximum consumption is limited by natural constrains - you can "eat" and "read" only limited amount of service. And what is more important - maximum consumed service is fixed per user and not changed significantly over time. So whatever resources you provisioned for given population today , it will be enough for tomorrow service as well. In case of flat-rate ISP dynamics is different - similarly to "all-you-can-eat" buffet, "heavy" user can download/watch so much movies per day, but... (a) ISPs are not provisioned for those kind of content - like "all-you-eat" buffet plan to serve a light breakfast, but serving lunch for a football team (b) Video quality demand increased rapidly - and so traffic per movie download. As result - 5%+95% of users are consuming more resources then provisioned or make economical sense. And it is not because of those 5% - it is result of changes in ALL user trends that probably break current technological or economical assumptions. And, btw - let's not "blame" this on P2P only. P2P just accelerated the common trend - availability of the high-quality video content. Non-P2P video downloads (mostly HTTP based) are accounted for about 20% of broadband ISP traffic - second place after 40% associated with P2P. As more professional content providers are coming into the play with legal content downloads, proportion on non-P2P video expected to grow as well. And, btw, if P2P traffic consumption can be shifted in time and space using some sort of BW throttling and P4P routing, HTTP-based streaming do not provide such flexibility as content has to be delivered NOW and from a single source. So even if we remove P2P from equations, ISPs will face the same problems in just 1-3 years due other forms of OTT video delivery. Bottom line: 1.) flat-rate is not fair at any speed 2.) Any flat rate/free service have 5% of users consuming 50% of resources. 3.) As long as consumer Internet is a "dumb-pipe" with no ability to differentiate on protocol/content, ISPs have to plan to over-provision up to satisfy top 5% of users or , alternatively move to usage-based pricing ( which has its own economical and technological problems - separate discussion) IMHO, considering cost and problems of usage-based billing, I do not believe that ISPs will move in mass to this new/old model. Probably, the better bet is in direction of the making network more "smart" - and it is where IETF is major driving force. _______________________________________________ p2pi mailing list p2pi@ietf.org https://www.ietf.org/mailman/listinfo/p2pi From p2pi-bounces@ietf.org Mon Jun 9 11:42:40 2008 Return-Path: X-Original-To: p2pi-archive@ietf.org Delivered-To: ietfarch-p2pi-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B0F1B3A6AD9; Mon, 9 Jun 2008 11:42:40 -0700 (PDT) X-Original-To: p2pi@core3.amsl.com Delivered-To: p2pi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0EC413A6CA6 for ; Mon, 9 Jun 2008 11:42:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.979 X-Spam-Level: X-Spam-Status: No, score=-2.979 tagged_above=-999 required=5 tests=[AWL=-0.620, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, SARE_LWSHORTT=1.24] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PSTbNHjg1VHT for ; Mon, 9 Jun 2008 11:42:38 -0700 (PDT) Received: from brinza.cc.columbia.edu (brinza.cc.columbia.edu [128.59.29.8]) by core3.amsl.com (Postfix) with ESMTP id 30BF13A6CA3 for ; Mon, 9 Jun 2008 11:42:38 -0700 (PDT) Received: from ice.cs.columbia.edu (ice.cs.columbia.edu [128.59.18.177]) (user=hgs10 mech=PLAIN bits=0) by brinza.cc.columbia.edu (8.14.1/8.14.1) with ESMTP id m59IgjOS006585 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Mon, 9 Jun 2008 14:42:45 -0400 (EDT) Message-Id: From: Henning Schulzrinne To: Nicholas Weaver In-Reply-To: <5C7D6FCF-4CF7-425E-8A17-A60DB8F07272@ICSI.Berkeley.EDU> Mime-Version: 1.0 (Apple Message framework v924) Date: Mon, 9 Jun 2008 14:42:47 -0400 References: <06BEE447-3D17-45D0-A73B-E248C3141F51@ICSI.Berkeley.EDU> <484C1958.2010900@isi.edu> <8719C03C-9EC9-482B-9536-1784F95DC8A8@ICSI.Berkeley.EDU> <484CC2A5.6050105@isi.edu> <1621FECD-ED33-4BF2-88D0-199D6FA75993@ICSI.Berkeley.EDU> <484D2DE8.7020407@isi.edu> <4D7FB692-F754-4DD7-A63C-BA96C5FF5E05@ICSI.Berkeley.EDU> <484D450E.4060806@isi.edu> <86DEA620-3C64-4C5D-A2A6-C4CD064B5AE1@ICSI.Berkeley.EDU> <484D5868.9000209@isi.edu> <5C7D6FCF-4CF7-425E-8A17-A60DB8F07272@ICSI.Berkeley.EDU> X-Mailer: Apple Mail (2.924) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.63 on 128.59.29.8 Cc: p2pi@ietf.org, Joe Touch Subject: Re: [p2pi] One more proposed definition of fairness... X-BeenThere: p2pi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: P2P Infrastructure Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: p2pi-bounces@ietf.org Errors-To: p2pi-bounces@ietf.org I don't see how short term (second to hour) fairness is all that interesting to users. If I'm a light user overall, but want to watch a movie on-demand (p2p or CDN) during the "busy hour", why should I not be able to do this? How can you explain this "fairness" to a user? Users pay a monthly fee, so they probably expect rough value-for-money on that general timescale. Henning _______________________________________________ p2pi mailing list p2pi@ietf.org https://www.ietf.org/mailman/listinfo/p2pi From p2pi-bounces@ietf.org Mon Jun 9 12:00: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 628EF28C210; Mon, 9 Jun 2008 12:00: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 0EB0228C1E3 for ; Mon, 9 Jun 2008 12:00:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.281 X-Spam-Level: X-Spam-Status: No, score=-1.281 tagged_above=-999 required=5 tests=[AWL=-0.256, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, SARE_LWSHORTT=1.24] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YiipK7C5o5mr for ; Mon, 9 Jun 2008 12:00:12 -0700 (PDT) Received: from outbound-mail-156.bluehost.com (outbound-mail-156.bluehost.com [67.222.39.36]) by core3.amsl.com (Postfix) with SMTP id 0800228C1D5 for ; Mon, 9 Jun 2008 12:00:09 -0700 (PDT) Received: (qmail 15508 invoked by uid 0); 9 Jun 2008 19:00:28 -0000 Received: from unknown (HELO host46.hostmonster.com) (74.220.202.46) by outboundproxy5.bluehost.com with SMTP; 9 Jun 2008 19:00:28 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=bennett.com; h=Received:Message-ID:Date:From:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding:X-Identified-User:DomainKey-Status; b=pgm3pSUx9xuJJoS/wcsgvmPGRXj7Nxy74HEcgaC7vXxW7P+NZyee8lOkIgQJ4DN8dhoLHjkOM5Ht4jwShY+0C0h/fo6LVa/736AqmQ9sFgjttLIzaEFM98NPJNCcr0A2; Received: from c-67-169-90-32.hsd1.ca.comcast.net ([67.169.90.32] helo=[192.168.0.12]) by host46.hostmonster.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.68) (envelope-from ) id 1K5mbU-0003CK-10; Mon, 09 Jun 2008 13:00:28 -0600 Message-ID: <484D7DC6.1020207@bennett.com> Date: Mon, 09 Jun 2008 12:00:22 -0700 From: Richard Bennett User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: Henning Schulzrinne References: <06BEE447-3D17-45D0-A73B-E248C3141F51@ICSI.Berkeley.EDU> <484C1958.2010900@isi.edu> <8719C03C-9EC9-482B-9536-1784F95DC8A8@ICSI.Berkeley.EDU> <484CC2A5.6050105@isi.edu> <1621FECD-ED33-4BF2-88D0-199D6FA75993@ICSI.Berkeley.EDU> <484D2DE8.7020407@isi.edu> <4D7FB692-F754-4DD7-A63C-BA96C5FF5E05@ICSI.Berkeley.EDU> <484D450E.4060806@isi.edu> <86DEA620-3C64-4C5D-A2A6-C4CD064B5AE1@ICSI.Berkeley.EDU> <484D5868.9000209@isi.edu> <5C7D6FCF-4CF7-425E-8A17-A60DB8F07272@ICSI.Berkeley.EDU> In-Reply-To: X-Identified-User: {842:host46.hostmonster.com:bennett1:bennett.com} {sentby:smtp auth 67.169.90.32 authed with richard+bennett.com} DomainKey-Status: no signature Cc: p2pi@ietf.org, Nicholas Weaver , Joe Touch Subject: Re: [p2pi] One more proposed definition of fairness... X-BeenThere: p2pi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: P2P Infrastructure Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: p2pi-bounces@ietf.org Errors-To: p2pi-bounces@ietf.org I don't think there's anything in the notion of per-second end-user fairness that should preclude the use of P2P or CDN downloads during peak usage periods. It should only become an issue for you if you were watching a live stream and also peering some heavy P2P loads at the same time, and in this case you need to be able to communicate stream priorities to your ISP. If you can't communicate this information, then it will probably be OK for you to have the ISP do enough DPI to figure it out for you. As others (most notably Nick) have pointed out, value-for-money in a residential broadband contract doesn't automatically equate to Committed Information Rate. These are statistical systems, where you get less than you pay for at some times and more than you pay for at others. Accepting statistical multiplexing as a design constraint from the get-go will help this group make faster progress. RB Henning Schulzrinne wrote: > I don't see how short term (second to hour) fairness is all that > interesting to users. If I'm a light user overall, but want to watch a > movie on-demand (p2p or CDN) during the "busy hour", why should I not > be able to do this? How can you explain this "fairness" to a user? > Users pay a monthly fee, so they probably expect rough value-for-money > on that general timescale. > > Henning > _______________________________________________ > 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 Jun 9 12:00: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 E41EB28C1CD; Mon, 9 Jun 2008 12:00: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 3A10F28C204 for ; Mon, 9 Jun 2008 12:00:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OxDG6RH2us7m for ; Mon, 9 Jun 2008 12:00:39 -0700 (PDT) Received: from yw-out-2324.google.com (yw-out-2324.google.com [74.125.46.30]) by core3.amsl.com (Postfix) with ESMTP id 258E228C1BD for ; Mon, 9 Jun 2008 12:00:31 -0700 (PDT) Received: by yw-out-2324.google.com with SMTP id 3so1205806ywj.49 for ; Mon, 09 Jun 2008 12:00:41 -0700 (PDT) Received: by 10.151.114.7 with SMTP id r7mr6808593ybm.191.1213038041433; Mon, 09 Jun 2008 12:00:41 -0700 (PDT) Received: by 10.150.148.13 with HTTP; Mon, 9 Jun 2008 12:00:41 -0700 (PDT) Message-ID: Date: Mon, 9 Jun 2008 12:00:41 -0700 From: "Stanislav Shalunov" To: "Henning Schulzrinne" In-Reply-To: <8B41AFE5-C1CF-4E9A-9975-57C6B81864C1@cs.columbia.edu> MIME-Version: 1.0 Content-Disposition: inline References: <215A468E-603E-486F-A544-D9CC0AF7C243@cs.columbia.edu> <3efc39a60806081429k3a2d2df7u861b400e9188850e@mail.gmail.com> <8B41AFE5-C1CF-4E9A-9975-57C6B81864C1@cs.columbia.edu> X-Google-Sender-Auth: 293f4106d4e6f2ef Cc: p2pi@ietf.org Subject: Re: [p2pi] For those who think "User Fairness/Cost Fairness" is unacceptable... X-BeenThere: p2pi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: P2P Infrastructure Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: p2pi-bounces@ietf.org Errors-To: p2pi-bounces@ietf.org On Mon, Jun 9, 2008 at 6:03 AM, Henning Schulzrinne wrote: >> offering different plans to different types of users. > It is very unlikely that those on the prepay plan would want to switch to the > Sprint $99 all-inclusive plan just for predictability, or vice versa. Well, duh. We send this for consideration for the usage section of the slang dictionary, entry "violent agreement", right? -- Stanislav Shalunov http://shlang.com/ _______________________________________________ p2pi mailing list p2pi@ietf.org https://www.ietf.org/mailman/listinfo/p2pi From p2pi-bounces@ietf.org Mon Jun 9 12:03:46 2008 Return-Path: X-Original-To: p2pi-archive@ietf.org Delivered-To: ietfarch-p2pi-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0DD2928C1D5; Mon, 9 Jun 2008 12:03:46 -0700 (PDT) X-Original-To: p2pi@core3.amsl.com Delivered-To: p2pi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F257C28C1D3 for ; Mon, 9 Jun 2008 12:03:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.289 X-Spam-Level: X-Spam-Status: No, score=-3.289 tagged_above=-999 required=5 tests=[AWL=0.310, 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 vO+v2DGiFJPN for ; Mon, 9 Jun 2008 12:03:44 -0700 (PDT) Received: from jalapeno.cc.columbia.edu (jalapeno.cc.columbia.edu [128.59.29.5]) by core3.amsl.com (Postfix) with ESMTP id 030F528C1D1 for ; Mon, 9 Jun 2008 12:03:43 -0700 (PDT) Received: from ice.cs.columbia.edu (ice.cs.columbia.edu [128.59.18.177]) (user=hgs10 mech=PLAIN bits=0) by jalapeno.cc.columbia.edu (8.14.1/8.14.1) with ESMTP id m59J3wjE017032 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Mon, 9 Jun 2008 15:03:58 -0400 (EDT) Message-Id: <64378741-7169-4FEE-84F9-9FF632C865B6@cs.columbia.edu> From: Henning Schulzrinne To: Richard Bennett In-Reply-To: <484D7DC6.1020207@bennett.com> Mime-Version: 1.0 (Apple Message framework v924) Date: Mon, 9 Jun 2008 15:03:59 -0400 References: <06BEE447-3D17-45D0-A73B-E248C3141F51@ICSI.Berkeley.EDU> <484C1958.2010900@isi.edu> <8719C03C-9EC9-482B-9536-1784F95DC8A8@ICSI.Berkeley.EDU> <484CC2A5.6050105@isi.edu> <1621FECD-ED33-4BF2-88D0-199D6FA75993@ICSI.Berkeley.EDU> <484D2DE8.7020407@isi.edu> <4D7FB692-F754-4DD7-A63C-BA96C5FF5E05@ICSI.Berkeley.EDU> <484D450E.4060806@isi.edu> <86DEA620-3C64-4C5D-A2A6-C4CD064B5AE1@ICSI.Berkeley.EDU> <484D5868.9000209@isi.edu> <5C7D6FCF-4CF7-425E-8A17-A60DB8F07272@ICSI.Berkeley.EDU> <484D7DC6.1020207@bennett.com> X-Mailer: Apple Mail (2.924) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.63 on 128.59.29.5 Cc: p2pi@ietf.org, Nicholas Weaver Subject: Re: [p2pi] One more proposed definition of fairness... X-BeenThere: p2pi@ietf.org X-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 Jun 9, 2008, at 3:00 PM, Richard Bennett wrote: > I don't think there's anything in the notion of per-second end-user > fairness that should preclude the use of P2P or CDN downloads during > peak usage periods. It should only become an issue for you if you > were watching a live stream and also peering some heavy P2P loads at > the same time, and in this case you need to be able to communicate > stream priorities to your ISP. If you can't communicate this > information, then it will probably be OK for you to have the ISP do > enough DPI to figure it out for you. The statement above implies a committed information rate, namely that of a single video stream. That's a reasonable service definition, to be sure. > > > As others (most notably Nick) have pointed out, value-for-money in a > residential broadband contract doesn't automatically equate to > Committed Information Rate. These are statistical systems, where you > get less than you pay for at some times and more than you pay for at > others. This has nothing to do with CIR, simply that fairness would argue, for example, that during peak periods, those who have already used "their fair share" of network resources this month get lower priority. > > > Accepting statistical multiplexing as a design constraint from the > get-go will help this group make faster progress. The problem is that we'll get systems that are not going to work as advertised, from a user perspective. _______________________________________________ p2pi mailing list p2pi@ietf.org https://www.ietf.org/mailman/listinfo/p2pi From p2pi-bounces@ietf.org Mon Jun 9 12:31:46 2008 Return-Path: X-Original-To: p2pi-archive@ietf.org Delivered-To: ietfarch-p2pi-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B006428C1BC; Mon, 9 Jun 2008 12:31:46 -0700 (PDT) X-Original-To: p2pi@core3.amsl.com Delivered-To: p2pi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E043728C1BA for ; Mon, 9 Jun 2008 12:31:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.442 X-Spam-Level: X-Spam-Status: No, score=0.442 tagged_above=-999 required=5 tests=[AWL=0.904, 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 MNeZVmp51Oqk for ; Mon, 9 Jun 2008 12:31:44 -0700 (PDT) Received: from pacdcimo01.cable.comcast.com (PacdcIMO01.cable.comcast.com [24.40.8.145]) by core3.amsl.com (Postfix) with ESMTP id 767CD28C1B1 for ; Mon, 9 Jun 2008 12:31:44 -0700 (PDT) Received: from ([10.52.116.31]) by pacdcimo01.cable.comcast.com with ESMTP id 5503620.4966802; Mon, 09 Jun 2008 15:31:48 -0400 Received: from PACDCEXCMB04.cable.comcast.com ([24.40.15.86]) by PAOAKEXCSMTP02.cable.comcast.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 9 Jun 2008 15:31:48 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 9 Jun 2008 15:31:47 -0400 Message-ID: <45AEC6EF95942140888406588E1A6602050F899B@PACDCEXCMB04.cable.comcast.com> In-Reply-To: <3efc39a60806081410i340fc5c2mf27da8eefebbc0cf@mail.gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [p2pi] ietf mandate ... Thread-Index: AcjJrCG+WzrapE3UTLiVB+h51QI/NQAuiZoQ References: <3efc39a60806081410i340fc5c2mf27da8eefebbc0cf@mail.gmail.com> From: "Livingood, Jason" To: "Robb Topolski" , "Don Bowman" X-OriginalArrivalTime: 09 Jun 2008 19:31:48.0193 (UTC) FILETIME=[75819D10:01C8CA67] Cc: p2pi@ietf.org Subject: Re: [p2pi] ietf mandate ... X-BeenThere: p2pi@ietf.org X-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="===============1482330576==" Sender: p2pi-bounces@ietf.org Errors-To: p2pi-bounces@ietf.org This is a multi-part message in MIME format. --===============1482330576== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C8CA67.75A2E3AA" This is a multi-part message in MIME format. ------_=_NextPart_001_01C8CA67.75A2E3AA Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Replies inline below. Took me an extra moment to type this, as I fell out of my chair when I saw Robb suggest he supported using DPI below. ;-) =20 Jason Instead of a scavenger class, why couldn't "best-effort" or undesignated traffic be the scavenger class traffic, and allow consumers to designate some relatively tiny amount (either by monthly allocation or daily percentage or whatever) for Expedited Forwarding. (The EF quota would be an amount definitely enough to make VOIP and head-to-head games work -- since that's the practical example that we have today -- but the choice of what to prioritize is the users' and not the ISP's purview.) =20 =20 =09 Users (through their applications) could identify which packets are which. To prevent abuse, the network should ignore the markings if the user is above their quota for that DSCP. =20 =20 So, best effort is best effort today, and you have a priority class (that you call EF). In this imagined priority class, what quota would you attach to it? 64Kbps, 96Kbps, etc.? I am guessing in this case that you would need user devices and/or software to designate the use of such a class, therefore delegating priority selection to these users and/or their software/devices. =20 =09 An opt-in DPI device at the carrier could help consumers get on board without further configuration. It would feature a one-size-fits-most preset that applies for most users. Otherwise, consumers could enable or upgrade their applications and equipment to enable packet marking to fit their own desires. =20 =20 So you are suggesting the ISP deploys DPI, so I have marked this day in history. ;-) In all seriousness, though, can you explain what you mean by 'help consumers get on board without further configuration?' I am not sure I understand how the DPI function would work in your suggestion. Are you saying that it be used in some kind of policy enforcement function, or to ensure that what is marked as say priority really 'should' be or 'should not' be priority? Appreciate any thoughts you have to expand on what you mean to suggest.=20 =09 --=20 Robb Topolski (robb@funchords.com) Hillsboro, Oregon USA http://www.funchords.com/=20 ------_=_NextPart_001_01C8CA67.75A2E3AA Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Replies inline below.  Took me an extra = moment to=20 type this, as I fell out of my chair when I saw Robb suggest he = supported using=20 DPI below.  ;-)
 
Jason

Instead of a scavenger class, why couldn't "best-effort" or = undesignated=20 traffic be the scavenger class traffic, and allow = consumers to=20 designate some relatively tiny amount (either by monthly allocation or = daily=20 percentage or whatever) for Expedited Forwarding.  (The EF quota = would be=20 an amount definitely enough to make VOIP and head-to-head games work = -- since=20 that's the practical example that we have today -- but the choice of = what to=20 prioritize is the users' and not the ISP's purview.)   
 
Users (through their applications) could identify which packets = are=20 which.  To prevent abuse, the network should ignore the markings = if the=20 user is above their quota for that DSCP.   
 
So, best effort is best = effort today, and=20 you have a priority class (that you call EF).  In = this imagined=20 priority class, what quota would you attach to it?  64Kbps,=20 96Kbps, etc.?  I am guessing in this case that you would = need user=20 devices and/or software to designate the use of such a class, = therefore=20 delegating priority selection to these users and/or their=20 software/devices.  

An opt-in = DPI device=20 at the carrier could help consumers get on board without further=20 configuration.  It would feature a one-size-fits-most preset that = applies=20 for most users. Otherwise, consumers could enable or upgrade their=20 applications and equipment to enable packet marking to fit their own=20 desires.  
 
So=20 you are suggesting the ISP deploys DPI, so I have marked this day in=20 history.  ;-)  In all seriousness, though, can you explain = what you=20 mean by 'help consumers get on board without further = configuration?'  I=20 am not sure I understand how the DPI function would work in your=20 suggestion.  Are you saying that it be used in some kind of=20 policy enforcement function, or to ensure that what is marked as = say=20 priority really 'should' be or 'should not' be priority?  = Appreciate any=20 thoughts you have to expand on what you mean to=20 suggest. 

--
Robb Topolski = (robb@funchords.com)
Hillsboro, = Oregon=20 USA
http://www.funchords.com/=20
------_=_NextPart_001_01C8CA67.75A2E3AA-- --===============1482330576== 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 --===============1482330576==-- From p2pi-bounces@ietf.org Mon Jun 9 12:46: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 55D413A69E6; Mon, 9 Jun 2008 12:46: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 EFE343A6AF4 for ; Mon, 9 Jun 2008 12:46:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.352 X-Spam-Level: X-Spam-Status: No, score=-6.352 tagged_above=-999 required=5 tests=[AWL=0.247, 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 w9L+GkkdcCcr for ; Mon, 9 Jun 2008 12:46:41 -0700 (PDT) Received: from fruitcake.ICSI.Berkeley.EDU (fruitcake.ICSI.Berkeley.EDU [192.150.186.11]) by core3.amsl.com (Postfix) with ESMTP id 299CD3A69E6 for ; Mon, 9 Jun 2008 12:46:41 -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 m59Jkr44010655; Mon, 9 Jun 2008 12:46:53 -0700 (PDT) Message-Id: <8F1E3198-50DF-40C7-9BB4-7D0B17AE85A6@icsi.berkeley.edu> From: Nicholas Weaver To: "Livingood, Jason" In-Reply-To: <45AEC6EF95942140888406588E1A6602050F899B@PACDCEXCMB04.cable.comcast.com> Mime-Version: 1.0 (Apple Message framework v924) Date: Mon, 9 Jun 2008 12:46:53 -0700 References: <3efc39a60806081410i340fc5c2mf27da8eefebbc0cf@mail.gmail.com> <45AEC6EF95942140888406588E1A6602050F899B@PACDCEXCMB04.cable.comcast.com> X-Mailer: Apple Mail (2.924) Cc: p2pi@ietf.org, Nicholas Weaver , Don Bowman Subject: Re: [p2pi] ietf mandate ... X-BeenThere: p2pi@ietf.org X-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 Jun 9, 2008, at 12:31 PM, Livingood, Jason wrote: > Replies inline below. Took me an extra moment to type this, as I > fell out of my chair when I saw Robb suggest he supported using DPI > below. ;-) ... Actually, it makes sense, but DPI is largely overkill (traffic analysis will suffice). If an ISP needs to make a shaping decision on a user to reduce their traffic under a threshhold T (or a subsection of their traffic. This could include just the access link in the absence of a smarter end- user attachment device), random allocation doesn't actually make sense. Absent explicit user guidance through QoS or related packet-marking, there are several IMPLICIT classes: 1: VoIP and other realtime 2: Interactive TCP (web surfing) 3: Streaming TCP [1] 4: Bulk-data P2P Which can be easily distinguished by the ISP through traffic analysis heuristics, and there is a simple ranking of priority which will suffice for almost all users, because this ordering directly reflects the usual urgency of the packets. I believe that such classification BETWEEN users is bad, but within a single user's flows, can greatly improve their perceived service, and whether opt-in, opt-out, or mandatory in the absence of packet marking, would result in a large benefit. [1] This is about the only case where DPI rather than traffic analysis could be a win. YouTube and others seem to operate in two modes: underbuffered and overbuffered. Thus if there is insufficient bandwidth, you get pausing and stuttering. But if there is oversufficient bandwidth, it can get way ahead of the actual point of viewing. Unless the user does a seek to much later in the video, this traffic could have easily been throttled back without affecting the user's experience, and will significantly reduce the traffic the user received if the user stops watching midway through the RickRolling. Ideally, the Flash-based players should just buffer the right amount, but unless they do, DPI could fix this "bug" when congestion is an issue for that user. _______________________________________________ p2pi mailing list p2pi@ietf.org https://www.ietf.org/mailman/listinfo/p2pi From p2pi-bounces@ietf.org Mon Jun 9 12:49:47 2008 Return-Path: X-Original-To: p2pi-archive@ietf.org Delivered-To: ietfarch-p2pi-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 907CF3A6AAC; Mon, 9 Jun 2008 12:49:47 -0700 (PDT) X-Original-To: p2pi@core3.amsl.com Delivered-To: p2pi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9B34D28C0F2 for ; Mon, 9 Jun 2008 12:49:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.561 X-Spam-Level: X-Spam-Status: No, score=0.561 tagged_above=-999 required=5 tests=[AWL=0.423, BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, HTML_MESSAGE=0.001, J_CHICKENPOX_82=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nFgTeh9dSIvy for ; Mon, 9 Jun 2008 12:49:44 -0700 (PDT) Received: from paoakoavas09.cable.comcast.com (paoakoavas09.cable.comcast.com [208.17.35.58]) by core3.amsl.com (Postfix) with ESMTP id D2FD23A6AAC for ; Mon, 9 Jun 2008 12:49:43 -0700 (PDT) Received: from ([10.52.116.31]) by paoakoavas09.cable.comcast.com with ESMTP id KP-NTF18.56278479; Mon, 09 Jun 2008 15:49:41 -0400 Received: from PACDCEXCMB04.cable.comcast.com ([24.40.15.86]) by PAOAKEXCSMTP02.cable.comcast.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 9 Jun 2008 15:49:41 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 9 Jun 2008 15:49:40 -0400 Message-ID: <45AEC6EF95942140888406588E1A6602050F89B5@PACDCEXCMB04.cable.comcast.com> In-Reply-To: <3efc39a60806081448x7499519brbef093888d7ee29d@mail.gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [p2pi] Fwd: For those who think "User Fairness/Cost Fairness"is unacceptable... Thread-Index: AcjJsZ2IUDiOH0oRQmCksj/xGXKCBAAts1JA References: <3efc39a60806080822l575c83c1p2a370bbb20a41bd6@mail.gmail.com><3efc39a60806080825yc1261ddmf2ce3da4b308a722@mail.gmail.com><7DFBDD81-6551-42AD-9E8F-6B3E00EDF254@icsi.berkeley.edu> <3efc39a60806081448x7499519brbef093888d7ee29d@mail.gmail.com> From: "Livingood, Jason" To: "Robb Topolski" , "Nicholas Weaver" X-OriginalArrivalTime: 09 Jun 2008 19:49:41.0040 (UTC) FILETIME=[F4F91300:01C8CA69] Cc: p2pi@ietf.org Subject: Re: [p2pi] Fwd: For those who think "User Fairness/Cost Fairness"is unacceptable... X-BeenThere: p2pi@ietf.org X-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="===============0133089848==" Sender: p2pi-bounces@ietf.org Errors-To: p2pi-bounces@ietf.org This is a multi-part message in MIME format. --===============0133089848== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C8CA69.F517F097" This is a multi-part message in MIME format. ------_=_NextPart_001_01C8CA69.F517F097 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable One question inline below. -Jason ________________________________ From: p2pi-bounces@ietf.org [mailto:p2pi-bounces@ietf.org] On Behalf Of Robb Topolski =09 =09 The only way to win "The Lifeboat Game " is to assume that = your particular values are better than anyone elses values. And, odds are, you're right. However, you are also probably in the minority of lifeboat passengers who hold that opinion. =20 =09 So while you're busy deciding who its okay to throw overboard, know that I'm stubbornly going to remain convinced that a person who has paid their bill, who has not hacked their modem, who is using applications who have not behaved nefariously, and who is acting within the law has every right to the next bit of bandwidth as I do. I also believe that truly abusive users should not be handled through probability guesses enabled by packet inspection and throttling, but with evidence, due process, and the entire termination of their service. =20 So here's a technical operations question for you then. What do you do with the users of a network who may have "hacked their modem" (using your terms) or who is using apps that are behaving "nefariously," and who may not be "acting within the law?" It sounds like you are suggesting that these are some specific and reasonable corner cases when applying reasonable network management may well be appropriate, provided a due and open process for determining and communicating this. And that in some extreme cases (perhaps the "acting within the law" parameter you suggested), that this may result in termination of service. To follow this logic you have suggested, it would not be reasonable to apply such policies unless a user essentially knew such limits or whatever beforehand (transparency needed in advance). =20 ------_=_NextPart_001_01C8CA69.F517F097 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
One question inline below.
-Jason

From: p2pi-bounces@ietf.org=20 [mailto:p2pi-bounces@ietf.org] On Behalf Of Robb=20 Topolski

The only way to win "The Lifeboat = Game" is=20 to assume that your particular values are better than anyone elses=20 values.  And, odds are, you're right.  However, you are also = probably in the minority of lifeboat passengers who hold that = opinion. =20

So while you're busy deciding who its okay to throw overboard, = know=20 that I'm stubbornly going to remain convinced that a person who has = paid=20 their bill, who has not hacked their modem, who is using applications = who have=20 not behaved nefariously, and who is acting within the law has every = right to=20 the next bit of bandwidth as I do.  I also believe that truly = abusive=20 users should not be handled through probability guesses enabled by = packet=20 inspection and throttling, but with evidence, due process, and the = entire=20 termination of their service. 
 
So=20 here's a technical operations question for you then.  What do you = do with=20 the users of a network who may have "hacked their modem" (using your = terms) or=20 who is using apps that are behaving "nefariously," and who may = not be=20 "acting within the law?"  It sounds like you are suggesting that = these=20 are some specific and reasonable corner cases when applying reasonable = network=20 management may well be appropriate, provided a due and open process = for=20 determining and communicating this.  And that in some = extreme cases=20 (perhaps the "acting within the law" parameter you suggested), that = this may=20 result in termination of service.  To follow this logic you have=20 suggested, it would not  be reasonable to apply such = policies=20 unless a user essentially knew such limits or whatever=20 beforehand (transparency needed in advance).  =20
------_=_NextPart_001_01C8CA69.F517F097-- --===============0133089848== 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 --===============0133089848==-- From p2pi-bounces@ietf.org Mon Jun 9 13:02:11 2008 Return-Path: X-Original-To: p2pi-archive@ietf.org Delivered-To: ietfarch-p2pi-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 657ED3A6A48; Mon, 9 Jun 2008 13:02:11 -0700 (PDT) X-Original-To: p2pi@core3.amsl.com Delivered-To: p2pi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0F64E3A6A48 for ; Mon, 9 Jun 2008 13:02:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.49 X-Spam-Level: * X-Spam-Status: No, score=1.49 tagged_above=-999 required=5 tests=[AWL=-0.647, BAYES_50=0.001, 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 FPiIYAlaS4ga for ; Mon, 9 Jun 2008 13:02:08 -0700 (PDT) Received: from paoakoavas10.cable.comcast.com (paoakoavas10.cable.comcast.com [208.17.35.59]) by core3.amsl.com (Postfix) with ESMTP id 317CA3A6840 for ; Mon, 9 Jun 2008 13:02:08 -0700 (PDT) Received: from ([24.40.15.92]) by paoakoavas10.cable.comcast.com with ESMTP id KP-TDCH7.46668725; Mon, 09 Jun 2008 16:02:12 -0400 Received: from PACDCEXCMB04.cable.comcast.com ([24.40.15.86]) by PACDCEXCSMTP03.cable.comcast.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 9 Jun 2008 16:02:11 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 9 Jun 2008 16:02:10 -0400 Message-ID: <45AEC6EF95942140888406588E1A6602050F89D1@PACDCEXCMB04.cable.comcast.com> In-Reply-To: <3efc39a60806080825yc1261ddmf2ce3da4b308a722@mail.gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [p2pi] Fwd: For those who think "User Fairness/Cost Fairness" isunacceptable... Thread-Index: AcjJe/j1q2mmGBVTTY2DyqmH5ieNbAA7l3KQ References: <3efc39a60806080822l575c83c1p2a370bbb20a41bd6@mail.gmail.com> <3efc39a60806080825yc1261ddmf2ce3da4b308a722@mail.gmail.com> From: "Livingood, Jason" To: "Robb Topolski" , X-OriginalArrivalTime: 09 Jun 2008 20:02:11.0827 (UTC) FILETIME=[B47A1430:01C8CA6B] Subject: Re: [p2pi] Fwd: For those who think "User Fairness/Cost Fairness" isunacceptable... X-BeenThere: p2pi@ietf.org X-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="===============0065041702==" Sender: p2pi-bounces@ietf.org Errors-To: p2pi-bounces@ietf.org This is a multi-part message in MIME format. --===============0065041702== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C8CA6B.B43C5CCD" This is a multi-part message in MIME format. ------_=_NextPart_001_01C8CA6B.B43C5CCD Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Replies inline below. Sorry I am still catching up on all this email from the weekend. =20 Jason ________________________________ From: p2pi-bounces@ietf.org [mailto:p2pi-bounces@ietf.org] On Behalf Of Robb Topolski =09 =09 All: I become increasingly frustrated by being the negative guy -- I'm an optimist. I do believe that Comcast made strides toward more transparency. But simply advertising that they interfere with some users does not excuse it (see RFC 1087). When so plainly asked to take a position, the IETF as an engineering body answer Comcast and reject non-Standards conforming behaviors. =20 =20 I was a bit thrown off by your RFC 1087 reference, "Ethics and the Internet" from 1989. Perhaps that RFC is somewhat geared towards a non-commercial past, when as it says, the Internet is a "national facility" used mostly by researchers. Can you advise your specific technical areas of concern, as it relates to this RFC (see below)? =20 Network Working Group Internet Activities Board Request for Comments: 1087 January 1989 =09 =09 Ethics and the Internet =09 Status of this Memo =09 This memo is a statement of policy by the Internet Activities Board (IAB) concerning the proper use of the resources of the Internet. Distribution of this memo is unlimited. =09 Introduction =09 At great human and economic cost, resources drawn from the U.S. Government, industry and the academic community have been assembled into a collection of interconnected networks called the Internet. Begun as a vehicle for experimental network research in the mid- 1970's, the Internet has become an important national infrastructure supporting an increasingly widespread, multi-disciplinary community of researchers ranging, inter alia, from computer scientists and electrical engineers to mathematicians, physicists, medical researchers, chemists, astronomers and space scientists. =09 As is true of other common infrastructures (e.g., roads, water reservoirs and delivery systems, and the power generation and distribution network), there is widespread dependence on the Internet by its users for the support of day-to-day research activities. =09 The reliable operation of the Internet and the responsible use of its resources is of common interest and concern for its users, operators and sponsors. Recent events involving the hosts on the Internet and in similar network infrastructures underscore the need to reiterate the professional responsibility every Internet user bears to colleagues and to the sponsors of the system. Many of the Internet resources are provided by the U.S. Government. Abuse of the system thus becomes a Federal matter above and beyond simple professional ethics. =09 IAB Statement of Policy =09 The Internet is a national facility whose utility is largely a consequence of its wide availability and accessibility. Irresponsible use of this critical resource poses an enormous threat to its continued availability to the technical community. =09 The U.S. Government sponsors of this system have a fiduciary responsibility to the public to allocate government resources wisely =09 =09 =09 Internet Activities Board [Page 1] =20 RFC 1087 Ethics and the Internet January 1989 =09 =09 and effectively. Justification for the support of this system suffers when highly disruptive abuses occur. Access to and use of the Internet is a privilege and should be treated as such by all users of this system. =09 The IAB strongly endorses the view of the Division Advisory Panel of the National Science Foundation Division of Network, Communications Research and Infrastructure which, in paraphrase, characterized as unethical and unacceptable any activity which purposely: =09 (a) seeks to gain unauthorized access to the resources of the Internet, =09 (b) disrupts the intended use of the Internet, =09 (c) wastes resources (people, capacity, computer) through such actions, =09 (d) destroys the integrity of computer-based information, =09 and/or =09 (e) compromises the privacy of users. =09 The Internet exists in the general research milieu. Portions of it continue to be used to support research and experimentation on networking. Because experimentation on the Internet has the potential to affect all of its components and users, researchers have the responsibility to exercise great caution in the conduct of their work. Negligence in the conduct of Internet-wide experiments is both irresponsible and unacceptable. =09 The IAB plans to take whatever actions it can, in concert with Federal agencies and other interested parties, to identify and to set up technical and procedural mechanisms to make the Internet more resistant to disruption. Such security, however, may be extremely expensive and may be counterproductive if it inhibits the free flow of information which makes the Internet so valuable. In the final analysis, the health and well-being of the Internet is the responsibility of its users who must, uniformly, guard against abuses which disrupt the system and threaten its long-term viability. =09 =09 =09 =09 =09 =09 =09 =09 =09 =09 Internet Activities Board [Page 2] =09 =20 --=20 Robb Topolski (robb@funchords.com) Hillsboro, Oregon USA http://www.funchords.com/=20 ------_=_NextPart_001_01C8CA6B.B43C5CCD Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Replies inline below.  Sorry I am still=20 catching up on all this email from the weekend.
 
Jason

From: p2pi-bounces@ietf.org=20 [mailto:p2pi-bounces@ietf.org] On Behalf Of Robb=20 Topolski

All:  I become increasingly frustrated by being the = negative guy=20 -- I'm an optimist.  I do believe that Comcast made strides = toward more=20 transparency.  But simply advertising that they interfere with = some users=20 does not excuse it (see RFC 1087).  When so plainly asked to take = a=20 position, the IETF as an engineering body answer Comcast and reject=20 non-Standards conforming behaviors.  
 
I=20 was a bit thrown off by your RFC 1087 reference, "Ethics and the = Internet"=20 from 1989.  Perhaps that RFC is somewhat geared towards a = non-commercial=20 past, when as it says, the Internet is a "national facility" used = mostly by=20 researchers.  Can you advise your specific technical areas of = concern, as=20 it relates to this RFC (see below)?
 
Network = Working=20 = Group           &n= bsp;           &nb= sp; =20 Internet Activities Board
Request for Comments:=20 = 1087           &nb= sp;           &nbs= p;         =20 January=20 = 1989


         &nb= sp;           &nbs= p; =20 Ethics and the = Internet

Status=20 of this Memo

   This memo is a statement of policy by = the=20 Internet Activities Board
   (IAB) concerning the proper = use of=20 the resources of the Internet.
   Distribution of this = memo is=20 unlimited.

Introduction

   At great human and = economic=20 cost, resources drawn from the U.S.
   Government, = industry and=20 the academic community have been assembled
   into a = collection=20 of interconnected networks called the Internet.
   Begun = as a=20 vehicle for experimental network research in the mid-
   = 1970's,=20 the Internet has become an important national = infrastructure
  =20 supporting an increasingly widespread, multi-disciplinary=20 community
   of researchers ranging, inter alia, from = computer=20 scientists and
   electrical engineers to mathematicians, = physicists, medical
   researchers, chemists, astronomers = and=20 space scientists.

   As is true of other common=20 infrastructures (e.g., roads, water
   reservoirs and = delivery=20 systems, and the power generation and
   distribution = network),=20 there is widespread dependence on the Internet
   by its = users=20 for the support of day-to-day research activities.

   = The=20 reliable operation of the Internet and the responsible use of=20 its
   resources is of common interest and concern for = its users,=20 operators
   and sponsors.  Recent events involving = the=20 hosts on the Internet and
   in similar network = infrastructures=20 underscore the need to reiterate
   the professional=20 responsibility every Internet user bears to
   colleagues = and to=20 the sponsors of the system.  Many of the Internet
   = resources are provided by the U.S. Government.  Abuse of the=20 system
   thus becomes a Federal matter above and beyond = simple=20 professional
   ethics.

IAB Statement of=20 Policy

   The Internet is a national = facility=20 whose utility is largely a
   consequence of its wide=20 availability and accessibility.
   Irresponsible use of = this=20 critical resource poses an enormous threat
   to its = continued=20 availability to the technical community.

   The U.S.=20 Government sponsors of this system have a fiduciary
  =20 responsibility to the public to allocate government resources=20 wisely



Internet Activities=20 = Board           &n= bsp;           &nb= sp;           &nbs= p;  =20 [Page 1]
 =
RFC 1087         = ;      =20 Ethics and the=20 = Internet           = ; =20 January 1989


   and=20 effectively.  Justification for the support of this=20 system
   suffers when highly disruptive abuses = occur. =20 Access to and use of
   the Internet is a privilege and = should be=20 treated as such by all
   users of this=20 system.

   The IAB strongly endorses the view of the = Division=20 Advisory Panel of
   the National Science Foundation = Division of=20 Network, Communications
   Research and Infrastructure = which, in=20 paraphrase, characterized as
   unethical and = unacceptable any=20 activity which purposely:

      (a) = seeks to=20 gain unauthorized access to the resources of=20 the
         =20 Internet,

      (b) disrupts the = intended use=20 of the Internet,

      (c) wastes = resources=20 (people, capacity, computer) through=20 such
         =20 actions,

      (d) destroys the = integrity of=20 computer-based information,

  =20 and/or

      (e) compromises the = privacy of=20 users.

   The Internet exists in the general research = milieu.  Portions of it
   continue to be used to = support=20 research and experimentation on
   networking.  = Because=20 experimentation on the Internet has the
   potential to = affect=20 all of its components and users, researchers have
   the=20 responsibility to exercise great caution in the conduct of=20 their
   work.  Negligence in the conduct of = Internet-wide=20 experiments is both
   irresponsible and=20 unacceptable.

   The IAB plans to take whatever = actions it=20 can, in concert with
   Federal agencies and other = interested=20 parties, to identify and to set
   up technical and = procedural=20 mechanisms to make the Internet more
   resistant to=20 disruption.  Such security, however, may be = extremely
  =20 expensive and may be counterproductive if it inhibits the free=20 flow
   of information which makes the Internet so=20 valuable.  In the final
   analysis, the health and=20 well-being of the Internet is the
   responsibility of = its users=20 who must, uniformly, guard against abuses
   which = disrupt the=20 system and threaten its long-term=20 viability.










Internet = Activities=20 = Board           &n= bsp;           &nb= sp;           &nbs= p;  =20 [Page 2]
 
--=20
Robb Topolski (robb@funchords.com)
Hillsboro, Oregon USA
http://www.funchords.com/=20
------_=_NextPart_001_01C8CA6B.B43C5CCD-- --===============0065041702== 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 --===============0065041702==-- From p2pi-bounces@ietf.org Mon Jun 9 13:40: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 50F853A682B; Mon, 9 Jun 2008 13:40: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 34A1F3A6825; Mon, 9 Jun 2008 13:40:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.042 X-Spam-Level: X-Spam-Status: No, score=-2.042 tagged_above=-999 required=5 tests=[AWL=0.558, 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 hDrrjVJQcOJt; Mon, 9 Jun 2008 13:40:20 -0700 (PDT) Received: from neustar.com (ns6.neustar.com [156.154.16.88]) by core3.amsl.com (Postfix) with ESMTP id 170633A69A7; Mon, 9 Jun 2008 13:40:08 -0700 (PDT) DKIM-Signature: a=rsa-sha1; d=neustar.biz; s=neustarbiz; c=simple/simple; q=dns; t=1213044025; x=1213130425; h=From:Date:Subject:Message-ID:Content-class:Content-Type:Content-Transfer-Encod ing; b=dwJdtCD7x5eUJxKhjhn/Y6XcQI/GknfglX1+ReXMjdEcsCwS41wZl92FRGTw85A8AVaEqhp5FnqLiw aOrylcMw== Received: from ([10.31.13.50]) by stihiron2.va.neustar.com with ESMTP id 5202732.8481427; Mon, 09 Jun 2008 16:40:09 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 9 Jun 2008 16:40:07 -0400 Message-ID: In-Reply-To: <6E1603B0-7116-45F9-A510-DC5F9040298B@nokia.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: discussing P2PI-related standardization in Dublin thread-index: AcjH43bffDGFH0n+Rgau+bxH0sE75ACi40yQ References: <22F6A875-B548-4C65-AB68-B88E526CCA33@nokia.com> <6E1603B0-7116-45F9-A510-DC5F9040298B@nokia.com> From: "Peterson, Jon" To: "TSV Area" Cc: p2pi@ietf.org, iab@iab.org, p2prg@irtf.org, "IESG \(\(E-mail\)\)" , P2PSIP Mailing List Subject: Re: [p2pi] discussing P2PI-related standardization in Dublin X-BeenThere: p2pi@ietf.org X-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 proposal for the ALTO BoF (which roughly covers (3)) is now in the BoF tracker. You can read about it at its home page: http://alto.tilab.com/ ALTO proposes to explore a slightly broader space than merely P2P file-sharing applications, since discovery of nearby peers has equal applicability to many real-time communications protocols (for example, the discovery of a TURN server to assist the establishment of a VoIP session). Although RAI proposes to sponsor a BoF on this subject, we're not yet persuaded that RAI would be the optimal home for any ongoing work efforts related to this space - we hope that discussions surrounding the BoF could elucidate the proper division of labor and approach to this problem. I do believe this work effort is sufficiently distinct from the transport issues discussed in (1) and (2) of Lars' original mail to merit a separate effort. I do, however, whole-heartedly support TSV taking on (1) and (2) in a forum like TANA. Jon Peterson NeuStar, Inc. -----Original Message----- From: iesg-bounces@iesg.org [mailto:iesg-bounces@iesg.org] On Behalf Of Lars Eggert Sent: Friday, June 06, 2008 7:41 AM To: TSV Area Cc: p2prg@irtf.org; iab@iab.org IAB; p2pi@ietf.org; IESG ((E-mail)); P2PSIP Mailing List Subject: Re: discussing P2PI-related standardization in Dublin Hi, related to the work item below, I've just heard that some folks had already been discussing the submission of a more targeted BOF proposal. Depending on the details of that proposal (which I haven't seen yet), work item (3) might be subsumed by it. On 2008-6-6, at 15:58, Lars Eggert wrote: > (3) A mechanism that lets an application that can > transfer data from or to several potential peers (i.e., > servers, caches, end systems) select a subset of peers > for efficient transmission in a way that is aligned with > the dynamic interconnection structure of the network > operators that provide connectivity to those peers. > Application designers, network equipment vendors and > network operators will need to collaborate on this work > item to define what kinds of dynamic interconnection > information is useful to applications, how to obtain it, > and how to provide it to applications, resulting in a > generic mechanism that is broadly applicable to many > current and future applications. This work item has > obvious interactions with the IETF's Application, Routing > and Operations areas. In order to make this effort more > manageable, it may make sense to work out the > requirements for such a solution first, before discussing > individual proposals or breaking up the work into pieces > for specification in different areas or WGs. Lars _______________________________________________ p2pi mailing list p2pi@ietf.org https://www.ietf.org/mailman/listinfo/p2pi From p2pi-bounces@ietf.org Mon Jun 9 13:59:36 2008 Return-Path: X-Original-To: p2pi-archive@ietf.org Delivered-To: ietfarch-p2pi-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9E5A03A6A48; Mon, 9 Jun 2008 13:59:36 -0700 (PDT) X-Original-To: p2pi@core3.amsl.com Delivered-To: p2pi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 89FA13A6A48 for ; Mon, 9 Jun 2008 13:59:35 -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 KP2RbwC6GzSk for ; Mon, 9 Jun 2008 13:59:34 -0700 (PDT) Received: from pacdcimo01.cable.comcast.com (PacdcIMO01.cable.comcast.com [24.40.8.145]) by core3.amsl.com (Postfix) with ESMTP id 4F1D23A69A7 for ; Mon, 9 Jun 2008 13:59:34 -0700 (PDT) Received: from ([24.40.15.118]) by pacdcimo01.cable.comcast.com with ESMTP id 5503620.4980545; Mon, 09 Jun 2008 16:59:33 -0400 Received: from PACDCEXCMB06.cable.comcast.com ([24.40.15.22]) by PACDCEXCSMTP04.cable.comcast.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 9 Jun 2008 16:59:33 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 9 Jun 2008 16:58:34 -0400 Message-ID: <74CCBBDF76102846AFA7B29F3A98D3F60107BE32@PACDCEXCMB06.cable.comcast.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [p2pi] Follow-Up from Comcast Presentation thread-index: AcjKEootrlHZmUbTThqTM/OrNYZNVAAYIsBg References: <45AEC6EF95942140888406588E1A6602045CBA5E@PACDCEXCMB04.cable.comcast.com><3efc39a60806061909n11a65eafnce88df7c73c30639@mail.gmail.com><4CB75CEA-FE7E-4398-A1B3-A03DBF5063D3@icsi.berkeley.edu><3efc39a60806070852p49f6a066y27e804fd5d4cf989@mail.gmail.com><20080607173925.GJ8579@verdi> <484AC9EB.8060501@isi.edu><20080607175712.GK8579@verdi> <484ACEEC.9070705@joelhalpern.com> From: "Woundy, Richard" To: "Stanislav Shalunov" , "Lars Eggert" X-OriginalArrivalTime: 09 Jun 2008 20:59:33.0013 (UTC) FILETIME=[B7956450:01C8CA73] Cc: p2pi@ietf.org Subject: Re: [p2pi] Follow-Up 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 And RFC 4594 (e.g. section 4.10) introduces the term 'Low-Priority Data' -- which had been called Scavenger in the QBSS reference below. -----Original Message----- From: p2pi-bounces@ietf.org [mailto:p2pi-bounces@ietf.org] On Behalf Of Stanislav Shalunov Sent: Monday, June 09, 2008 5:24 AM To: Lars Eggert Cc: p2pi@ietf.org Subject: Re: [p2pi] Follow-Up from Comcast Presentation See also http://qos.internet2.edu/wg/wg-documents/qbss-definition.txt On Mon, Jun 9, 2008 at 2:15 AM, Lars Eggert wrote: > RFC3662? > > On 2008-6-7, at 20:09, ext Joel M. Halpern wrote: >> Several of the meeting presentations referred to "Scavenger service". >> >> As a definition, assuming I am allowed to define using diffserv, how >> about: >> >> Unmarked packets, and packets marked for better diffserv classes will >> receive preferential queueing treatment compared with those marked >> with >> Scavenger class service. To avoid starvatation, the Scavanger queue >> will be guaranteed a minimal percentage (10%?) of the data capacity >> even >> when normal and better services could consume all available bandwidth. >> >> That is basically the inverse of the simplified EF definition, for >> achieving essentially the opposite goal. > > _______________________________________________ > p2pi mailing list > p2pi@ietf.org > https://www.ietf.org/mailman/listinfo/p2pi > -- Stanislav Shalunov http://shlang.com/ _______________________________________________ p2pi mailing list p2pi@ietf.org https://www.ietf.org/mailman/listinfo/p2pi _______________________________________________ p2pi mailing list p2pi@ietf.org https://www.ietf.org/mailman/listinfo/p2pi From p2pi-bounces@ietf.org Mon Jun 9 14:01: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 233993A696A; Mon, 9 Jun 2008 14:01: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 EA29D3A697B; Mon, 9 Jun 2008 14:01:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.282 X-Spam-Level: X-Spam-Status: No, score=0.282 tagged_above=-999 required=5 tests=[AWL=0.746, 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 6ddiflQXGoyr; Mon, 9 Jun 2008 14:01:41 -0700 (PDT) Received: from paoakoavas09.cable.comcast.com (paoakoavas09.cable.comcast.com [208.17.35.58]) by core3.amsl.com (Postfix) with ESMTP id 9E7A33A689A; Mon, 9 Jun 2008 14:01:40 -0700 (PDT) Received: from ([10.52.116.30]) by paoakoavas09.cable.comcast.com with ESMTP id KP-NTF18.56283810; Mon, 09 Jun 2008 17:01:41 -0400 Received: from PACDCEXCMB04.cable.comcast.com ([24.40.15.86]) by PAOAKEXCSMTP01.cable.comcast.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 9 Jun 2008 17:01:41 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 9 Jun 2008 17:01:41 -0400 Message-ID: <45AEC6EF95942140888406588E1A6602050F8A1D@PACDCEXCMB04.cable.comcast.com> In-Reply-To: <22F6A875-B548-4C65-AB68-B88E526CCA33@nokia.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [p2pi] discussing P2PI-related standardization in Dublin Thread-Index: AcjH3ZarWE/N3E6+S32PcBHCWewT6QClYsMw References: <22F6A875-B548-4C65-AB68-B88E526CCA33@nokia.com> From: "Livingood, Jason" To: "TSV Area" X-OriginalArrivalTime: 09 Jun 2008 21:01:41.0790 (UTC) FILETIME=[045733E0:01C8CA74] Cc: p2prg@irtf.org, iab@iab.org, p2pi@ietf.org, "IESG \(\(E-mail\)\)" , P2PSIP Mailing List Subject: Re: [p2pi] discussing P2PI-related standardization in Dublin X-BeenThere: p2pi@ietf.org X-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 Exceptionally minor comments inline. > We'd be interested to hear from the community if we should > schedule a BOF in Dublin to discuss whether the IETF should > take on some or all of these, and if so, whether TSV would be > the right place for this work. A BoF or two would be good, IMHO. Some of this probably fits into TSV too, so confiming that this seems on the right track to me at least. > The working title for the BOF is "Techniques for Advanced > Networking Applications" or TANA. So far we have TANA and ALTO, plus referring some items into TSV, which again, seems appropriate and useful. I do not have anything else to add to this list for now; perhaps discussion @ IETF-72 will reveal further needs. Jason _______________________________________________ p2pi mailing list p2pi@ietf.org https://www.ietf.org/mailman/listinfo/p2pi From p2pi-bounces@ietf.org Mon Jun 9 14:19: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 75A373A6BC8; Mon, 9 Jun 2008 14:19: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 431A83A6BC8 for ; Mon, 9 Jun 2008 14:19:42 -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=[AWL=0.579, 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 f06JEAGU8Utc for ; Mon, 9 Jun 2008 14:19:41 -0700 (PDT) Received: from paoakoavas09.cable.comcast.com (paoakoavas09.cable.comcast.com [208.17.35.58]) by core3.amsl.com (Postfix) with ESMTP id EC8B63A6BB7 for ; Mon, 9 Jun 2008 14:19:40 -0700 (PDT) Received: from ([10.195.246.152]) by paoakoavas09.cable.comcast.com with ESMTP id KP-NTF18.56284914; Mon, 09 Jun 2008 17:19:44 -0400 Received: from PACDCEXCMB04.cable.comcast.com ([24.40.15.86]) by NJMDCEXCRLY01.cable.comcast.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 9 Jun 2008 17:19:44 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 9 Jun 2008 17:19:43 -0400 Message-ID: <45AEC6EF95942140888406588E1A6602050F8A31@PACDCEXCMB04.cable.comcast.com> In-Reply-To: <3efc39a60806071527x1460fdefg26226cbaa682c8f1@mail.gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [p2pi] Follow-Up from Comcast Presentation Thread-Index: AcjI7bO9ewL+ApGQRVeOFBJgUhw/ZABh5LRg References: <45AEC6EF95942140888406588E1A6602045CBA5E@PACDCEXCMB04.cable.comcast.com><3efc39a60806061909n11a65eafnce88df7c73c30639@mail.gmail.com><4CB75CEA-FE7E-4398-A1B3-A03DBF5063D3@icsi.berkeley.edu><3efc39a60806070852p49f6a066y27e804fd5d4cf989@mail.gmail.com><20080607173925.GJ8579@verdi> <3efc39a60806071527x1460fdefg26226cbaa682c8f1@mail.gmail.com> From: "Livingood, Jason" To: "Robb Topolski" , "John Leslie" , X-OriginalArrivalTime: 09 Jun 2008 21:19:44.0064 (UTC) FILETIME=[896D1C00:01C8CA76] Subject: Re: [p2pi] Follow-Up 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: multipart/mixed; boundary="===============1628840877==" Sender: p2pi-bounces@ietf.org Errors-To: p2pi-bounces@ietf.org This is a multi-part message in MIME format. --===============1628840877== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C8CA76.895B2AB5" This is a multi-part message in MIME format. ------_=_NextPart_001_01C8CA76.895B2AB5 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Then again, maybe it's not just luck. ;-) Maybe it is a combination of (among other factors) (1) good network capacity management, (2) regular course of business / ongoing network upgrades (often related to #1), (3) one form of network management that has been effective in some way, and (4) great local HFC network operations by our team in Oregon. I am glad that you describe your service as 'excellent' (even with the TCP RSTs that have obviously been performed in your area). I can't tell you how much I look forward to the day when we implement the new network management technique in Hillsboro, Oregon, and you can personally confirm the absence of TCP RSTs in your P2P use. :-) =20 Jason =20 Maybe I've just been plain lucky. Comcast in my area (AT&T Broadband, TCI prior to that) have been excellent. =20 =09 Robb Topolski --=20 Robb Topolski (robb@funchords.com) Hillsboro, Oregon USA http://www.funchords.com/=20 ------_=_NextPart_001_01C8CA76.895B2AB5 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Then again, maybe it's not just luck.  = ;-) =20 Maybe it is a combination of (among other factors) (1) good network = capacity=20 management, (2) regular course of business / ongoing network upgrades = (often=20 related to #1), (3) one form of network management that has been = effective in=20 some way, and (4) great local HFC network operations by our team in=20 Oregon.  I am glad that you describe your service as 'excellent' = (even with=20 the TCP RSTs that have obviously been performed in your area). =20 I can't tell you how much I look forward to = the day=20 when we implement the new network management technique in Hillsboro, = Oregon, and=20 you can personally confirm the absence of TCP RSTs in your P2P = use. =20 :-)
 
Jason
 
Maybe I've just been plain lucky.  Comcast in my area = (AT&T=20 Broadband, TCI prior to that) have been excellent. 

Robb=20 Topolski
--
Robb Topolski (robb@funchords.com)
Hillsboro, Oregon USA
http://www.funchords.com/=20
------_=_NextPart_001_01C8CA76.895B2AB5-- --===============1628840877== 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 --===============1628840877==-- From p2pi-bounces@ietf.org Mon Jun 9 16:32:42 2008 Return-Path: X-Original-To: p2pi-archive@ietf.org Delivered-To: ietfarch-p2pi-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EA1673A6A9B; Mon, 9 Jun 2008 16:32:42 -0700 (PDT) X-Original-To: p2pi@core3.amsl.com Delivered-To: p2pi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 452F63A6A9B for ; Mon, 9 Jun 2008 16:32:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.176 X-Spam-Level: X-Spam-Status: No, score=-1.176 tagged_above=-999 required=5 tests=[AWL=0.200, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_82=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7hHtkrap13kH for ; Mon, 9 Jun 2008 16:32:39 -0700 (PDT) Received: from wf-out-1314.google.com (wf-out-1314.google.com [209.85.200.168]) by core3.amsl.com (Postfix) with ESMTP id C8C063A695B for ; Mon, 9 Jun 2008 16:32:39 -0700 (PDT) Received: by wf-out-1314.google.com with SMTP id 27so2514844wfd.31 for ; Mon, 09 Jun 2008 16:32:58 -0700 (PDT) Received: by 10.142.238.9 with SMTP id l9mr1720276wfh.20.1213054377448; Mon, 09 Jun 2008 16:32:57 -0700 (PDT) Received: by 10.142.186.7 with HTTP; Mon, 9 Jun 2008 16:32:57 -0700 (PDT) Message-ID: <3efc39a60806091632t70772a1fm40c10338ac279d0d@mail.gmail.com> Date: Mon, 9 Jun 2008 16:32:57 -0700 From: "Robb Topolski" To: "Livingood, Jason" In-Reply-To: <45AEC6EF95942140888406588E1A6602050F89B5@PACDCEXCMB04.cable.comcast.com> MIME-Version: 1.0 References: <3efc39a60806080822l575c83c1p2a370bbb20a41bd6@mail.gmail.com> <3efc39a60806080825yc1261ddmf2ce3da4b308a722@mail.gmail.com> <7DFBDD81-6551-42AD-9E8F-6B3E00EDF254@icsi.berkeley.edu> <3efc39a60806081448x7499519brbef093888d7ee29d@mail.gmail.com> <45AEC6EF95942140888406588E1A6602050F89B5@PACDCEXCMB04.cable.comcast.com> Cc: p2pi@ietf.org Subject: Re: [p2pi] Fwd: For those who think "User Fairness/Cost Fairness"is unacceptable... X-BeenThere: p2pi@ietf.org X-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="===============0767328802==" Sender: p2pi-bounces@ietf.org Errors-To: p2pi-bounces@ietf.org --===============0767328802== Content-Type: multipart/alternative; boundary="----=_Part_7535_2177227.1213054377433" ------=_Part_7535_2177227.1213054377433 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline On Mon, Jun 9, 2008 at 12:49 PM, Livingood, Jason < Jason_Livingood@cable.comcast.com> wrote: > One question inline below. > -Jason > > ------------------------------ > *From:* p2pi-bounces@ietf.org [mailto:p2pi-bounces@ietf.org] *On Behalf Of > *Robb Topolski > > The only way to win "The Lifeboat Game" > is to assume that your particular values are better than anyone elses > values. And, odds are, you're right. However, you are also probably in the > minority of lifeboat passengers who hold that opinion. > > So while you're busy deciding who its okay to throw overboard, know that *I'm > stubbornly going to remain convinced that a person who has paid their bill, > who has not hacked their modem, who is using applications who have not > behaved nefariously, and who is acting within the law has every right to the > next bit of bandwidth as I do. *I also believe that truly abusive users > should not be handled through probability guesses enabled by packet > inspection and throttling, but with evidence, due process, and the entire > termination of their service. > > So here's a technical operations question for you then. What do you do > with the users of a network who may have "hacked their modem" (using your > terms) or who is using apps that are behaving "nefariously," and who may * > not* be "acting within the law?" It sounds like you are suggesting that > these are some specific and reasonable corner cases when applying reasonable > network management may well be appropriate, provided a due and open process > for determining and communicating this. And that in some extreme cases > (perhaps the "acting within the law" parameter you suggested), that this may > result in termination of service. To follow this logic you have suggested, > it would *not* be reasonable to apply such policies *unless *a user > essentially knew such limits or whatever *beforehand* (transparency needed > in advance). > > I was talking about network abuse and the commission of acts that ought not require policies prohibiting them. I was also talking about the wedge tactic that pits one user against another in an effort to create "sides" in a debate. As to how Comcast should respond to a user innocently exceeding clearly communicated service limits in an agreement is another subject. -- Robb Topolski (robb@funchords.com) Hillsboro, Oregon USA http://www.funchords.com/ ------=_Part_7535_2177227.1213054377433 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline

On Mon, Jun 9, 2008 at 12:49 PM, Livingood, Jason <Jason_Livingood@cable.comcast.com> wrote:
One question inline below.
-Jason

From: p2pi-bounces@ietf.org [mailto:p2pi-bounces@ietf.org] On Behalf Of Robb Topolski

The only way to win "The Lifeboat Game" is to assume that your particular values are better than anyone elses values.  And, odds are, you're right.  However, you are also probably in the minority of lifeboat passengers who hold that opinion. 

So while you're busy deciding who its okay to throw overboard, know that I'm stubbornly going to remain convinced that a person who has paid their bill, who has not hacked their modem, who is using applications who have not behaved nefariously, and who is acting within the law has every right to the next bit of bandwidth as I do.  I also believe that truly abusive users should not be handled through probability guesses enabled by packet inspection and throttling, but with evidence, due process, and the entire termination of their service. 
 
So here's a technical operations question for you then.  What do you do with the users of a network who may have "hacked their modem" (using your terms) or who is using apps that are behaving "nefariously," and who may not be "acting within the law?"  It sounds like you are suggesting that these are some specific and reasonable corner cases when applying reasonable network management may well be appropriate, provided a due and open process for determining and communicating this.  And that in some extreme cases (perhaps the "acting within the law" parameter you suggested), that this may result in termination of service.  To follow this logic you have suggested, it would not  be reasonable to apply such policies unless a user essentially knew such limits or whatever beforehand (transparency needed in advance).  
I was talking about network abuse and the commission of acts that ought not require policies prohibiting them.  I was also talking about the wedge tactic that pits one user against another in an effort to create "sides" in a debate. 

As to how Comcast should respond to a user innocently exceeding clearly communicated service limits in an agreement is another subject. 


--
Robb Topolski (robb@funchords.com)
Hillsboro, Oregon USA
http://www.funchords.com/ ------=_Part_7535_2177227.1213054377433-- --===============0767328802== 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 --===============0767328802==-- From p2pi-bounces@ietf.org Mon Jun 9 16:38:55 2008 Return-Path: X-Original-To: p2pi-archive@ietf.org Delivered-To: ietfarch-p2pi-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3B5C73A6879; Mon, 9 Jun 2008 16:38:55 -0700 (PDT) X-Original-To: p2pi@core3.amsl.com Delivered-To: p2pi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5E1FD3A6879 for ; Mon, 9 Jun 2008 16:38:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.494 X-Spam-Level: X-Spam-Status: No, score=-1.494 tagged_above=-999 required=5 tests=[AWL=0.482, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tmlVOfusA2Bk for ; Mon, 9 Jun 2008 16:38:50 -0700 (PDT) Received: from wf-out-1314.google.com (wf-out-1314.google.com [209.85.200.172]) by core3.amsl.com (Postfix) with ESMTP id 916AF3A67D4 for ; Mon, 9 Jun 2008 16:38:50 -0700 (PDT) Received: by wf-out-1314.google.com with SMTP id 27so2517156wfd.31 for ; Mon, 09 Jun 2008 16:39:10 -0700 (PDT) Received: by 10.142.52.9 with SMTP id z9mr1718640wfz.70.1213054750607; Mon, 09 Jun 2008 16:39:10 -0700 (PDT) Received: by 10.142.186.7 with HTTP; Mon, 9 Jun 2008 16:39:10 -0700 (PDT) Message-ID: <3efc39a60806091639t3ff649a3i6421b1a334e458b7@mail.gmail.com> Date: Mon, 9 Jun 2008 16:39:10 -0700 From: "Robb Topolski" To: "Livingood, Jason" In-Reply-To: <45AEC6EF95942140888406588E1A6602050F89D1@PACDCEXCMB04.cable.comcast.com> MIME-Version: 1.0 References: <3efc39a60806080822l575c83c1p2a370bbb20a41bd6@mail.gmail.com> <3efc39a60806080825yc1261ddmf2ce3da4b308a722@mail.gmail.com> <45AEC6EF95942140888406588E1A6602050F89D1@PACDCEXCMB04.cable.comcast.com> Cc: p2pi@ietf.org Subject: Re: [p2pi] Fwd: For those who think "User Fairness/Cost Fairness" isunacceptable... X-BeenThere: p2pi@ietf.org X-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="===============0226440792==" Sender: p2pi-bounces@ietf.org Errors-To: p2pi-bounces@ietf.org --===============0226440792== Content-Type: multipart/alternative; boundary="----=_Part_7564_17071146.1213054750588" ------=_Part_7564_17071146.1213054750588 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline On Mon, Jun 9, 2008 at 1:02 PM, Livingood, Jason < Jason_Livingood@cable.comcast.com> wrote: > > I was a bit thrown off by your RFC 1087 reference, "Ethics and the > Internet" from 1989. Perhaps that RFC is somewhat geared towards a > non-commercial past, when as it says, the Internet is a "national facility" > used mostly by researchers. > > The reference is historical, relating to "*Recent events involving the hosts on the Internet and in similar network infrastructures underscore the need to reiterate the professional responsibility every Internet user bears to colleagues ..."* > Can you advise your specific technical areas of concern, as it relates to > this RFC (see below)? > > They are these acts, which Comcast's current RST method and proposed "Protocol Agnostic" method violate. * (b) disrupts the intended use of the Internet,* * (c) wastes resources (people, capacity, computer) through such* * actions,* * (d) destroys the integrity of computer-based information,* * (e) compromises the privacy of users.* -- Robb Topolski (robb@funchords.com) Hillsboro, Oregon USA http://www.funchords.com/ ------=_Part_7564_17071146.1213054750588 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline

On Mon, Jun 9, 2008 at 1:02 PM, Livingood, Jason <Jason_Livingood@cable.comcast.com> wrote:

I was a bit thrown off by your RFC 1087 reference, "Ethics and the Internet" from 1989.  Perhaps that RFC is somewhat geared towards a non-commercial past, when as it says, the Internet is a "national facility" used mostly by researchers. 
The reference is historical, relating to "Recent events involving the hosts on the Internet and
   in similar network infrastructures underscore the need to reiterate
   the professional responsibility every Internet user bears to
   colleagues ..."
 
Can you advise your specific technical areas of concern, as it relates to this RFC (see below)?

They are these acts, which Comcast's current RST method and proposed "Protocol Agnostic" method violate.
 
      (b) disrupts the intended use of the Internet,

      (c) wastes resources (people, capacity, computer) through such
          actions,

      (d) destroys the integrity of computer-based information,

      (e) compromises the privacy of users.


--
Robb Topolski (robb@funchords.com)
Hillsboro, Oregon USA
http://www.funchords.com/ ------=_Part_7564_17071146.1213054750588-- --===============0226440792== 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 --===============0226440792==-- From p2pi-bounces@ietf.org Mon Jun 9 16:41:31 2008 Return-Path: X-Original-To: p2pi-archive@ietf.org Delivered-To: ietfarch-p2pi-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 50B883A681D; Mon, 9 Jun 2008 16:41:31 -0700 (PDT) X-Original-To: p2pi@core3.amsl.com Delivered-To: p2pi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9C69A3A681D for ; Mon, 9 Jun 2008 16:41:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.534 X-Spam-Level: X-Spam-Status: No, score=-1.534 tagged_above=-999 required=5 tests=[AWL=0.442, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dQzPLUp7QLDI for ; Mon, 9 Jun 2008 16:41:29 -0700 (PDT) Received: from wf-out-1314.google.com (wf-out-1314.google.com [209.85.200.168]) by core3.amsl.com (Postfix) with ESMTP id AEDF33A67E4 for ; Mon, 9 Jun 2008 16:41:29 -0700 (PDT) Received: by wf-out-1314.google.com with SMTP id 27so2518057wfd.31 for ; Mon, 09 Jun 2008 16:41:50 -0700 (PDT) Received: by 10.142.255.14 with SMTP id c14mr1704233wfi.296.1213054910108; Mon, 09 Jun 2008 16:41:50 -0700 (PDT) Received: by 10.142.186.7 with HTTP; Mon, 9 Jun 2008 16:41:50 -0700 (PDT) Message-ID: <3efc39a60806091641s131f0c80lf61f3b488c449b20@mail.gmail.com> Date: Mon, 9 Jun 2008 16:41:50 -0700 From: "Robb Topolski" To: "Don Bowman" In-Reply-To: MIME-Version: 1.0 References: <3efc39a60806081410i340fc5c2mf27da8eefebbc0cf@mail.gmail.com> Cc: p2pi@ietf.org Subject: Re: [p2pi] ietf mandate ... X-BeenThere: p2pi@ietf.org X-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="===============1698513391==" Sender: p2pi-bounces@ietf.org Errors-To: p2pi-bounces@ietf.org --===============1698513391== Content-Type: multipart/alternative; boundary="----=_Part_7569_9431625.1213054910112" ------=_Part_7569_9431625.1213054910112 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Thanks for that explanation, Don! That was awesome! ------=_Part_7569_9431625.1213054910112 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Thanks for that explanation, Don!  That was awesome! 
------=_Part_7569_9431625.1213054910112-- --===============1698513391== 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 --===============1698513391==-- From p2pi-bounces@ietf.org Mon Jun 9 17:03:53 2008 Return-Path: X-Original-To: p2pi-archive@ietf.org Delivered-To: ietfarch-p2pi-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 38AF23A6AB8; Mon, 9 Jun 2008 17:03: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 CEC483A6A3F for ; Mon, 9 Jun 2008 17:03:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.568 X-Spam-Level: X-Spam-Status: No, score=-1.568 tagged_above=-999 required=5 tests=[AWL=0.408, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cgEeXhaX69Zn for ; Mon, 9 Jun 2008 17:03:17 -0700 (PDT) Received: from wf-out-1314.google.com (wf-out-1314.google.com [209.85.200.172]) by core3.amsl.com (Postfix) with ESMTP id 47C013A6879 for ; Mon, 9 Jun 2008 16:55:24 -0700 (PDT) Received: by wf-out-1314.google.com with SMTP id 27so2523091wfd.31 for ; Mon, 09 Jun 2008 16:55:42 -0700 (PDT) Received: by 10.142.252.11 with SMTP id z11mr1717059wfh.232.1213055742339; Mon, 09 Jun 2008 16:55:42 -0700 (PDT) Received: by 10.142.186.7 with HTTP; Mon, 9 Jun 2008 16:55:42 -0700 (PDT) Message-ID: <3efc39a60806091655s4da16594w4c58e3a92c062651@mail.gmail.com> Date: Mon, 9 Jun 2008 16:55:42 -0700 From: "Robb Topolski" To: "Nicholas Weaver" In-Reply-To: <8F1E3198-50DF-40C7-9BB4-7D0B17AE85A6@icsi.berkeley.edu> MIME-Version: 1.0 References: <3efc39a60806081410i340fc5c2mf27da8eefebbc0cf@mail.gmail.com> <45AEC6EF95942140888406588E1A6602050F899B@PACDCEXCMB04.cable.comcast.com> <8F1E3198-50DF-40C7-9BB4-7D0B17AE85A6@icsi.berkeley.edu> Cc: p2pi@ietf.org, "Livingood, Jason" , Don Bowman Subject: Re: [p2pi] ietf mandate ... X-BeenThere: p2pi@ietf.org X-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="===============0808477047==" Sender: p2pi-bounces@ietf.org Errors-To: p2pi-bounces@ietf.org --===============0808477047== Content-Type: multipart/alternative; boundary="----=_Part_7629_22412678.1213055742333" ------=_Part_7629_22412678.1213055742333 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline On Mon, Jun 9, 2008 at 12:46 PM, Nicholas Weaver wrote: > Actually, it makes sense, but DPI is largely overkill (traffic analysis > will suffice). > > If an ISP needs to make a shaping decision on a user to reduce their > traffic under a threshhold T (or a subsection of their traffic. This could > include just the access link in the absence of a smarter end-user attachment > device), random allocation doesn't actually make sense. Either way, I don't want to lose the fact that OPT-IN are operative words in turning control of TOS/DSCP/XYZ Service Flow classification to the ISP. Otherwise, its just another violation of Standards and its an awfully lot of power to put in the hands of a service provider who might be working in the best interests of their users today but might be "monetizing" them for cheap tomorrow.. . -- Robb Topolski (robb@funchords.com) Hillsboro, Oregon USA http://www.funchords.com/ ------=_Part_7629_22412678.1213055742333 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline

On Mon, Jun 9, 2008 at 12:46 PM, Nicholas Weaver <nweaver@icsi.berkeley.edu> wrote:
Actually, it makes sense, but DPI is largely overkill (traffic analysis will suffice).

If an ISP needs to make a shaping decision on a user to reduce their traffic under a threshhold T (or a subsection of their traffic.  This could include just the access link in the absence of a smarter end-user attachment device), random allocation doesn't actually make sense.

Either way, I don't want to lose the fact that OPT-IN are operative words in turning control of  TOS/DSCP/XYZ Service Flow classification to the ISP.  Otherwise, its just another violation of Standards and its an awfully lot of power to put in the hands of a service provider who might be working in the best interests of their users today but might be "monetizing" them for cheap tomorrow..  . 

--
Robb Topolski (robb@funchords.com)
Hillsboro, Oregon USA
http://www.funchords.com/ ------=_Part_7629_22412678.1213055742333-- --===============0808477047== 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 --===============0808477047==-- From p2pi-bounces@ietf.org Mon Jun 9 17:12:59 2008 Return-Path: X-Original-To: p2pi-archive@ietf.org Delivered-To: ietfarch-p2pi-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9453528C144; Mon, 9 Jun 2008 17:12:59 -0700 (PDT) X-Original-To: p2pi@core3.amsl.com Delivered-To: p2pi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E40B63A67D7 for ; Mon, 9 Jun 2008 17:12:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.597 X-Spam-Level: X-Spam-Status: No, score=-1.597 tagged_above=-999 required=5 tests=[AWL=0.379, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NMUzGilJlpui for ; Mon, 9 Jun 2008 17:12:56 -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 7264F3A6BC2 for ; Mon, 9 Jun 2008 17:04:04 -0700 (PDT) Received: by wf-out-1314.google.com with SMTP id 27so2526282wfd.31 for ; Mon, 09 Jun 2008 17:04:25 -0700 (PDT) Received: by 10.142.237.20 with SMTP id k20mr1721999wfh.225.1213056264801; Mon, 09 Jun 2008 17:04:24 -0700 (PDT) Received: by 10.142.186.7 with HTTP; Mon, 9 Jun 2008 17:04:24 -0700 (PDT) Message-ID: <3efc39a60806091704t771b2e4ak8ef6c820abd15e80@mail.gmail.com> Date: Mon, 9 Jun 2008 17:04:24 -0700 From: "Robb Topolski" To: "Livingood, Jason" In-Reply-To: <3efc39a60806091639t3ff649a3i6421b1a334e458b7@mail.gmail.com> MIME-Version: 1.0 References: <3efc39a60806080822l575c83c1p2a370bbb20a41bd6@mail.gmail.com> <3efc39a60806080825yc1261ddmf2ce3da4b308a722@mail.gmail.com> <45AEC6EF95942140888406588E1A6602050F89D1@PACDCEXCMB04.cable.comcast.com> <3efc39a60806091639t3ff649a3i6421b1a334e458b7@mail.gmail.com> Cc: p2pi@ietf.org Subject: Re: [p2pi] Fwd: For those who think "User Fairness/Cost Fairness" isunacceptable... X-BeenThere: p2pi@ietf.org X-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="===============1230315961==" Sender: p2pi-bounces@ietf.org Errors-To: p2pi-bounces@ietf.org --===============1230315961== Content-Type: multipart/alternative; boundary="----=_Part_7671_15638233.1213056264795" ------=_Part_7671_15638233.1213056264795 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline (Adding to my own message) On Mon, Jun 9, 2008 at 4:39 PM, Robb Topolski wrote: > > > On Mon, Jun 9, 2008 at 1:02 PM, Livingood, Jason < > Jason_Livingood@cable.comcast.com> wrote: > >> >> I was a bit thrown off by your RFC 1087 reference, "Ethics and the >> Internet" from 1989. Perhaps that RFC is somewhat geared towards a >> non-commercial past, when as it says, the Internet is a "national facility" >> used mostly by researchers. >> >> The reference is historical, relating to "*Recent events involving the > hosts on the Internet andin similar network infrastructures underscore the > need to reiterate the professional responsibility every Internet user bears > to colleagues ..." > * > >> Can you advise your specific technical areas of concern, as it relates to >> this RFC (see below)? >> >> > They are these acts, which Comcast's current RST method and proposed > "Protocol Agnostic" method violate. > > * (b) disrupts the intended use of the Internet,* > > * (c) wastes resources (people, capacity, computer) through such* > * actions,* > > * (d) destroys the integrity of computer-based information,* > > * (e) compromises the privacy of users.* > > All, please be clear that WRT to RFC 1087 I'm using it as an example and expressing my criticisms at the methods being employed, not the persons and companies themselves. The effects of using Protocol discrimination or Consumption discrimination are these four effects above. Comcast is here participating -- not here acting "unethically." Unfortunately, the title of RFC 1087 is something like "Ethics and the Internet." Please do not interpret this fact as a criticism of Comcast or its participation here. Please do interpret my message as a criticism of both the old and their new proposed method. Thank you to the individual who sent me a corrective message in private. It did look like a shot, and that wasn't what I was going for. -- Robb Topolski (robb@funchords.com) Hillsboro, Oregon USA http://www.funchords.com/ ------=_Part_7671_15638233.1213056264795 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline (Adding to my own message)

On Mon, Jun 9, 2008 at 4:39 PM, Robb Topolski <robb@funchords.com> wrote:


On Mon, Jun 9, 2008 at 1:02 PM, Livingood, Jason <Jason_Livingood@cable.comcast.com> wrote:

I was a bit thrown off by your RFC 1087 reference, "Ethics and the Internet" from 1989.  Perhaps that RFC is somewhat geared towards a non-commercial past, when as it says, the Internet is a "national facility" used mostly by researchers. 
The reference is historical, relating to "Recent events involving the hosts on the Internet and
in similar network infrastructures underscore the need to reiterate the professional responsibility every Internet user bears to colleagues ..."
 
Can you advise your specific technical areas of concern, as it relates to this RFC (see below)?

They are these acts, which Comcast's current RST method and proposed "Protocol Agnostic" method violate.
 
      (b) disrupts the intended use of the Internet,

      (c) wastes resources (people, capacity, computer) through such
          actions,

      (d) destroys the integrity of computer-based information,

      (e) compromises the privacy of users.


All, please be clear that WRT to RFC 1087 I'm using it as an example and expressing my criticisms at the methods being employed, not the persons and companies themselves.  The effects of using Protocol discrimination or Consumption discrimination are these four effects above. 

Comcast is here participating -- not here acting "unethically."  Unfortunately, the title of RFC 1087 is something like "Ethics and the Internet."  Please do not interpret this fact as a criticism of Comcast or its participation here.  Please do interpret my message as a criticism of both the old and their new proposed method.

Thank you to the individual who sent me a corrective message in private.  It did look like a shot, and that wasn't what I was going for.


--
Robb Topolski (robb@funchords.com)
Hillsboro, Oregon USA
http://www.funchords.com/ ------=_Part_7671_15638233.1213056264795-- --===============1230315961== 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 --===============1230315961==-- From p2pi-bounces@ietf.org Mon Jun 9 17:26: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 9AF483A6A49; Mon, 9 Jun 2008 17:26: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 E86133A6864 for ; Mon, 9 Jun 2008 17:26:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.264 X-Spam-Level: X-Spam-Status: No, score=-2.264 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aqnhEhPMntoU for ; Mon, 9 Jun 2008 17:26:29 -0700 (PDT) Received: from outbound-mail-121.bluehost.com (outbound-mail-121.bluehost.com [67.222.38.21]) by core3.amsl.com (Postfix) with SMTP id E61CD3A6765 for ; Mon, 9 Jun 2008 17:26:27 -0700 (PDT) Received: (qmail 29877 invoked by uid 0); 10 Jun 2008 00:26:47 -0000 Received: from unknown (HELO host46.hostmonster.com) (74.220.202.46) by outboundproxy4.bluehost.com with SMTP; 10 Jun 2008 00:26:47 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=bennett.com; h=Received:Message-ID:Date:From:Organization:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:Content-Type:X-Identified-User:DomainKey-Status; b=tThCUXwi3iN1AtUcpxfCX+1oIe5f3CSS/1cTZ5j0Ebi+KuAeoOJFJKG6jsPGKLbX8NTWun398U97TV6C6mOQL8tDVGoYGTPXaqVziua2AGYMFIgC3AZCmQ+dgvkruCq1; Received: from adsl-69-106-224-201.dsl.pltn13.pacbell.net ([69.106.224.201] helo=[192.168.1.2]) by host46.hostmonster.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.68) (envelope-from ) id 1K5rhG-0001X5-Lc; Mon, 09 Jun 2008 18:26:47 -0600 Message-ID: <484DCA46.7050405@bennett.com> Date: Mon, 09 Jun 2008 17:26:46 -0700 From: Richard Bennett Organization: Network Strategies User-Agent: Thunderbird 2.0.0.14 (X11/20080501) MIME-Version: 1.0 To: Robb Topolski References: <3efc39a60806080822l575c83c1p2a370bbb20a41bd6@mail.gmail.com> <3efc39a60806080825yc1261ddmf2ce3da4b308a722@mail.gmail.com> <45AEC6EF95942140888406588E1A6602050F89D1@PACDCEXCMB04.cable.comcast.com> <3efc39a60806091639t3ff649a3i6421b1a334e458b7@mail.gmail.com> <3efc39a60806091704t771b2e4ak8ef6c820abd15e80@mail.gmail.com> In-Reply-To: <3efc39a60806091704t771b2e4ak8ef6c820abd15e80@mail.gmail.com> X-Identified-User: {842:host46.hostmonster.com:bennett1:bennett.com} {sentby:smtp auth 69.106.224.201 authed with richard@bennett.com} DomainKey-Status: no signature Cc: p2pi@ietf.org, "Livingood, Jason" Subject: Re: [p2pi] Fwd: For those who think "User Fairness/Cost Fairness" isunacceptable... X-BeenThere: p2pi@ietf.org X-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="===============0860718952==" Sender: p2pi-bounces@ietf.org Errors-To: p2pi-bounces@ietf.org This is a multi-part message in MIME format. --===============0860718952== Content-Type: multipart/alternative; boundary="------------050300080400050608040609" This is a multi-part message in MIME format. --------------050300080400050608040609 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit This isn't a court of law, and it's not our mandate to determine who the good guys (or good practices) are and who's being bad. It's certainly not an established fact that an application-neutral per-user fairness regime is "disruptive to the intended use of the Internet" or any such thing; in fact, the evidence leads to quite a different conclusion. Similarly, packet inspection (deep or shallow, if there is such a thing) without retention for the purpose of prioritizing is quite a different animal than packet inspection for the purpose of retaining personal information to be used for commercial or other purposes. Similarly, speculations about the viability of metered pricing are probably not productive, given that it's already the norm on most Internet access networks in the world. The Internet is, after all, a global phenomenon and not simply a slice of American life. I'd prefer to focus the energies of this group in a more productive direction, namely to identify means of harmonizing the needs and requirements of groups of users on shared network links, given that "infinite bandwidth at no cost" is outside the solution space. RB Robb Topolski wrote: > (Adding to my own message) > > On Mon, Jun 9, 2008 at 4:39 PM, Robb Topolski > wrote: > > > > On Mon, Jun 9, 2008 at 1:02 PM, Livingood, Jason > > wrote: > > > I was a bit thrown off by your RFC 1087 reference, "Ethics > and the Internet" from 1989. Perhaps that RFC is somewhat > geared towards a non-commercial past, when as it says, the > Internet is a "national facility" used mostly by researchers. > > The reference is historical, relating to "/Recent events involving > the hosts on the Internet and > in similar network infrastructures underscore the need to > reiterate the professional responsibility every Internet user > bears to colleagues ..." > / > > Can you advise your specific technical areas of concern, > as it relates to this RFC (see below)? > > > They are these acts, which Comcast's current RST method and > proposed "Protocol Agnostic" method violate. > > / (b) disrupts the intended use of the Internet,/ > > / (c) wastes resources (people, capacity, computer) through such/ > / actions,/ > > / (d) destroys the integrity of computer-based information,/ > > / (e) compromises the privacy of users./ > > > All, please be clear that WRT to RFC 1087 I'm using it as an example > and expressing my criticisms at the methods being employed, not the > persons and companies themselves. The effects of using Protocol > discrimination or Consumption discrimination are these four effects > above. > > Comcast is here participating -- not here acting "unethically." > Unfortunately, the title of RFC 1087 is something like "Ethics and the > Internet." Please do not interpret this fact as a criticism of > Comcast or its participation here. Please do interpret my message as > a criticism of both the old and their new proposed method. > > Thank you to the individual who sent me a corrective message in > private. It did look like a shot, and that wasn't what I was going for. > > > -- > Robb Topolski (robb@funchords.com ) > Hillsboro, Oregon USA > http://www.funchords.com/ > ------------------------------------------------------------------------ > > _______________________________________________ > p2pi mailing list > p2pi@ietf.org > https://www.ietf.org/mailman/listinfo/p2pi > -- Richard Bennett --------------050300080400050608040609 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit This isn't a court of law, and it's not our mandate to determine who the good guys (or good practices) are and who's being bad. It's certainly not an established fact that an application-neutral per-user fairness regime is "disruptive to the intended use of the Internet" or any such thing; in fact, the evidence leads to quite a different conclusion.

Similarly, packet inspection (deep or shallow, if there is such a thing) without retention for the purpose of prioritizing is quite a different animal than packet inspection for the purpose of retaining personal information  to be used for commercial or other purposes.

Similarly, speculations about the viability of metered pricing are probably not productive, given that it's already the norm on most Internet access networks in the world. The Internet is, after all, a global phenomenon and not simply a slice of American life.

I'd prefer to focus the energies of this group in a more productive direction, namely to identify means of harmonizing the needs and requirements of groups of users on shared network links, given that "infinite bandwidth at no cost" is outside the solution space.

RB

Robb Topolski wrote:
(Adding to my own message)

On Mon, Jun 9, 2008 at 4:39 PM, Robb Topolski <robb@funchords.com> wrote:


On Mon, Jun 9, 2008 at 1:02 PM, Livingood, Jason <Jason_Livingood@cable.comcast.com> wrote:

I was a bit thrown off by your RFC 1087 reference, "Ethics and the Internet" from 1989.  Perhaps that RFC is somewhat geared towards a non-commercial past, when as it says, the Internet is a "national facility" used mostly by researchers. 
The reference is historical, relating to "Recent events involving the hosts on the Internet and
in similar network infrastructures underscore the need to reiterate the professional responsibility every Internet user bears to colleagues ..."
 
Can you advise your specific technical areas of concern, as it relates to this RFC (see below)?

They are these acts, which Comcast's current RST method and proposed "Protocol Agnostic" method violate.
 
      (b) disrupts the intended use of the Internet,

      (c) wastes resources (people, capacity, computer) through such
          actions,

      (d) destroys the integrity of computer-based information,

      (e) compromises the privacy of users.


All, please be clear that WRT to RFC 1087 I'm using it as an example and expressing my criticisms at the methods being employed, not the persons and companies themselves.  The effects of using Protocol discrimination or Consumption discrimination are these four effects above. 

Comcast is here participating -- not here acting "unethically."  Unfortunately, the title of RFC 1087 is something like "Ethics and the Internet."  Please do not interpret this fact as a criticism of Comcast or its participation here.  Please do interpret my message as a criticism of both the old and their new proposed method.

Thank you to the individual who sent me a corrective message in private.  It did look like a shot, and that wasn't what I was going for.


--
Robb Topolski (robb@funchords.com)
Hillsboro, Oregon USA
http://www.funchords.com/ 

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

-- 
Richard Bennett
--------------050300080400050608040609-- --===============0860718952== 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 --===============0860718952==-- From p2pi-bounces@ietf.org Mon Jun 9 18:03:11 2008 Return-Path: X-Original-To: p2pi-archive@ietf.org Delivered-To: ietfarch-p2pi-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0E88B3A6831; Mon, 9 Jun 2008 18:03:11 -0700 (PDT) X-Original-To: p2pi@core3.amsl.com Delivered-To: p2pi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0C7AB3A67AD for ; Mon, 9 Jun 2008 18:03:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.367 X-Spam-Level: * X-Spam-Status: No, score=1.367 tagged_above=-999 required=5 tests=[AWL=-0.882, BAYES_50=0.001, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, HTML_MESSAGE=0.001, SARE_NETPROD=0.111] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3wKp1Lq2ZS9i for ; Mon, 9 Jun 2008 18:02:58 -0700 (PDT) Received: from paoakoavas10.cable.comcast.com (paoakoavas10.cable.comcast.com [208.17.35.59]) by core3.amsl.com (Postfix) with ESMTP id 93A913A6848 for ; Mon, 9 Jun 2008 18:02:58 -0700 (PDT) Received: from ([10.52.116.31]) by paoakoavas10.cable.comcast.com with ESMTP id KP-TDCH7.46681161; Mon, 09 Jun 2008 21:03:01 -0400 Received: from PACDCEXCMB04.cable.comcast.com ([24.40.15.86]) by PAOAKEXCSMTP02.cable.comcast.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 9 Jun 2008 21:03:01 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 9 Jun 2008 21:02:23 -0400 Message-ID: <45AEC6EF95942140888406588E1A6602045CBA87@PACDCEXCMB04.cable.comcast.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: RE: [p2pi] Follow-Up from Comcast Presentation Thread-Index: AcjIQ5uAAh1PJ7m7QBOwii8s1IaCawCMvQUQAAc28rA= From: "Livingood, Jason" To: X-OriginalArrivalTime: 10 Jun 2008 01:03:01.0301 (UTC) FILETIME=[BACD3E50:01C8CA95] Subject: Re: [p2pi] Follow-Up 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: multipart/mixed; boundary="===============0113711511==" Sender: p2pi-bounces@ietf.org Errors-To: p2pi-bounces@ietf.org This is a multi-part message in MIME format. --===============0113711511== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C8CA95.BB1B4FD9" This is a multi-part message in MIME format. ------_=_NextPart_001_01C8CA95.BB1B4FD9 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Inline below - sorry it took awhile, but it was a long email that touched on many things. Jason ________________________________ From: Robb Topolski [mailto:robb@funchords.com]=20 =09 In particular, I'm concerned with possible scenarios such as someone who is mid-upload of 1100 European vacation pictures (all at 8 Megapixel) when her husband has a medical emergency. She dials 9-1-1 on Vonage or whatever non-Comcast VOIP device. Comcast delays and drops her packets as the new system places her VOIP call is behind long packet queues created by other activity in her neighborhood. =20 =20 First, I would say that it seems that this example user should configure their home gateway router to allocate a specific amount of LAN bandwidth for their VoIP service, so that their VoIP service would not be overwhelmed by and negatively affected by the upload of several GB of digital photos. Many VoIP services instruct their customers to install their device directly to the broadband connection, and then connect their router behind this device. That device then makes decisions about traffic flowing from the customer's network and would ensure that the customer's VoIP service would not be negatively affected by any other other applications. =20 =20 Secondly, without any form of network management (current or future), the heavy use of whatever apps by a few people at times of congestion would interfere with the same VoIP call. =20 Nevertheless, in terms of when the bits get to our network, I can tell you that we have asked our engineers and our vendors to address this concern, which has been foremost in our minds.=20 ... many consumer gateway-router devices marketed under different brands use a QoS engine by Ubicom. These devices determine the upload stream size either as manually configured by the user or measured automatically when the router reboots. These devices will not function properly if the bandwidth it believes it is reserving is suddenly made unavailable by the network. In summary, best-effort traffic is the baseline traffic expectation and developers of Internet products do not expect a situation where a network operator has invented a "worse than best-effort" traffic class -- nor should they.=20 =20 As we stated up at MIT, our trial is NOT applying rate limits to the subscribers. So for example, we're NOT taking a 16Mbps/2Mbps customer down to 1Mbps/512Kbps. The user's bits we are talking about are simply assigned a lower QoS for some period of time, assuming (1) that the network is in a near-congestion state and (2) the user has crossed a specific threshold of usage for a specific period of time (both conditions must be met). =20 =20 But perhaps more importantly, devices that "assume" that the network's bandwidth is a fixed constant are flawed devices. First, congestion can occur anywhere along the path through the Internet, including parts beyond the ISP network and therefore outside of the ISP's control. Second, bandwidth can fluctuate for "good" reasons too (ref: Powerboost). How would such devices or software adapt to something like a wireless network, where bandwidth is probably the most variable due to the user moving in relation to base stations, etc.? It would seem that devices and software should, within reason, be able to adapt to normal ups and downs of bandwidth to a user or device. =20 The users are harmed because their network is behaving strangely and they have no way of knowing why. =20 =20 I am not sure how you know that a user will perceive the network as 'behaving strangely' at such a time. It would seem reasonable that one of the things a trial should ascertain is whether users even notice this at all. It is clearly one of the things we'll be studying very closely and gathering data on. =20 Innovation is harmed because the access and transit networks continue to behave unexpectedly. It isn't the network operator who will get the call about the online game or VOIP application that is behaving poorly, it's the software publisher. =20 =20 Actually, you may be surprised to discover that the ISP is often the first call for many of these customers. On a related item, for example, we recently observed complaints on our user forums, and on the forums at BroadbandReports that a certain web video site was performing poorly (a thread in which you and I both participated). Despite posts from users from other ISPs that would indicate the problem was not limited to Comcast users, we engaged engineering resources to study the problem, to check our network, and then contact that web site's NOC, open a ticket with them, and assist them in troubleshooting what appears to have been a routing problem on their network. This is in fact a regular and normal part of business for us, whether it is ensuring that web video sites work well for our customers, whether they can send email to certain domains, or their online games and VoIP services work well on our network. =20 =20 Comcast is sending the signal that the operators of the access networks are going to tamp down the natural demand-based growth of the internet is as uninteligent as a chip manufacturer saying that they're done making faster chips. So why would someone release a bandwidth-hungry product into that environment? Just as the world's largest chip manufacturers enable innovation by trying to stay as far ahead of developers ability to suck-up MIPS as possible, I would expect someone serious about leading in the business of broadband should be doing the same.=20 =20 Unfortunately, you have made a few statements to the effect that our investment in our network is largely static, meaning that every few years we decide whether or not to invest in the network. That could not be further from the truth. As our public financial statements show, we invest substantial sums of money on an ongoing basis to continuously improve all parts of our network. When parts of the network approach pre-set utilization numbers, a well tested process kicks in automatically to upgrade these portions of the network. In addition to these normal-course-of-business investments, we have large generational investments in things like DOCSIS 3.0. Further, we continue to develop and release new services that benefit our customers as well. Our network is a valuable asset and no rational company in our position would choose not to continue to invest in, care for, and improve such an asset. I'd also prefer to stick to the tech talk here, rather than the econ stuff. :-)=20 =09 Thanks for asking for feedback. I'm sorry it is not at all positive. While I do recognize efforts at more transparency and user notification as good things, the method itself fails the standards compatibility test.=20 =20 I am not sure I understand what standards compatability test you are referring to. ?? (Unless of course this is the earlier RFC you referred to in a different email.)=20 =20 Anyhow Robb, at this stage, I'd like to turn my attention to working with my colleagues to conduct our trials, find the best way to manage data flows to provide the best possible experience for all of our users, and let them be the judge. In the meantime, we will also continue our efforts as participants in this IETF list (and in the upcoming BoFs and other WGs at IETF-72) and our continuing effort to have a constructive technical dialogue with the broader community.=20 =20 Thanks, Jason =09 Robb Topolski=20 ------_=_NextPart_001_01C8CA95.BB1B4FD9 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Inline below - sorry it took awhile, but it = was a long=20 email that touched on many things.
Jason
From: Robb Topolski=20 [mailto:robb@funchords.com] 

In particular, I'm = concerned=20 with possible scenarios such as someone who is mid-upload of 1100 = European=20 vacation pictures (all at 8 Megapixel) when her husband has a medical=20 emergency.  She dials 9-1-1 on Vonage or whatever non-Comcast = VOIP=20 device. Comcast delays and drops her packets as the new system places = her VOIP=20 call is behind long packet queues created by other activity in her=20 neighborhood.   
 

First, I would say that it seems that = this example=20 user should configure their home gateway router to allocate a specific = amount=20 of LAN bandwidth for their VoIP service, so that their VoIP service = would not=20 be overwhelmed by and negatively affected by the upload of several GB = of=20 digital photos.  Many = VoIP=20 services instruct their customers to install their device directly to = the=20 broadband connection, and then connect their router behind this = device.  That device then makes = decisions about=20 traffic flowing from the customer’s network and would ensure = that the=20 customer’s VoIP service would not be negatively affected by = any other other applications.   

 

Secondly, without any form of network = management=20 (current or future), the heavy use of  whatever apps by a = few people at times of = congestion would=20 interfere with the same VoIP call.

 

Nevertheless,  in terms of = when the=20 bits get to our network, I can tell you that we have asked our = engineers and=20 our vendors to address this concern, which has been foremost in our=20 minds.=20


 <snip>... many=20 consumer gateway-router devices marketed under different brands use a = QoS=20 engine by Ubicom.  These devices determine the upload stream size = either=20 as manually configured by the user or measured automatically when the = router=20 reboots.  These devices will not function properly if the = bandwidth it=20 believes it is reserving is suddenly made unavailable by the = network.  In=20 summary, best-effort traffic is the baseline traffic expectation and=20 developers of Internet products do not expect a situation where a = network=20 operator has invented a "worse than best-effort" traffic class -- nor = should=20 they. 
 
As we stated up at = MIT, our trial=20 is NOT applying rate limits to the subscribers.  So for example, we’re = NOT taking a=20 16Mbps/2Mbps customer down to 1Mbps/512Kbps.  The user’s bits we are = talking about=20 are simply assigned a lower QoS for some period of time, assuming (1) = that the=20 network is in a near-congestion state and (2) the user has crossed a = specific=20 threshold of usage for a specific period of time (both conditions must = be=20 met). =20
 
But perhaps=20 more importantly, devices that "assume" that the = network's=20 bandwidth is a fixed constant are flawed devices. =20 First, congestion can occur anywhere along the path through the = Internet,=20 including parts beyond the ISP network and therefore outside of the = ISP's=20 control.  Second, bandwidth can fluctuate for "good" reasons = too=20 (ref: Powerboost).  How would such devices or software adapt to = something=20 like a wireless network, where bandwidth is probably the most variable = due to=20 the user moving in relation to base stations, etc.?  It would = seem that=20 devices and software should, within reason, be able to adapt to normal = ups and=20 downs of bandwidth to a user or = device.
 
The users are harmed because their network is behaving strangely = and they=20 have no way of knowing why.   
 

I am not sure how = you know that a=20 user will perceive the network as ‘behaving strangely’ at = such a time.  It would seem reasonable = that one of=20 the things a trial should ascertain is whether users even notice this = at=20 all.  It is clearly one = of the=20 things we’ll be studying very closely and gathering data=20 on.

 
 Innovation is = harmed because=20 the access and transit networks continue to behave unexpectedly.  = It=20 isn't the network operator who will get the call about the online game = or VOIP=20 application that is behaving poorly, it's the software=20 publisher.   
 

Actually, you may be surprised = to discover=20 that the ISP is often the first call for many of these=20 customers.   On a = related item,=20 for example, we recently observed complaints on our user = forums,=20 and on the forums at BroadbandReports that a certain web video site = was=20 performing poorly (a thread in which you and I both = participated).  Despite posts from users = from other=20 ISPs that would indicate the problem was not limited to Comcast users, = we=20 engaged engineering resources to study the problem, to check our = network, and=20 then contact that web site’s NOC, open a ticket with them, and = assist them in=20 troubleshooting what appears to have been a routing problem on their=20 network.  This is in = fact a=20 regular and normal part of business for us, whether it is ensuring = that web=20 video sites work well for our customers, whether they can send email = to=20 certain domains, or their online games and VoIP services work well on = our=20 network.   

 

Comcast is = sending the=20 signal that the operators of the access  networks are going to = tamp down=20 the natural demand-based growth of the internet is as uninteligent as = a chip=20 manufacturer saying that they're done making faster chips.  So = why would=20 someone release a bandwidth-hungry product into that = environment?  Just=20 as the world's largest chip manufacturers enable innovation by trying = to stay=20 as far ahead of developers ability to suck-up MIPS as possible, I = would expect=20 someone serious about leading in the business of broadband should be = doing the=20 same. 

 

Unfortunately, you have made a few statements to the = effect=20 that our investment in our network is largely static, meaning that = every few=20 years we decide whether or not to invest in the network.  That could not be further = from the=20 truth.    As our=20 public financial statements show, we invest = substantial=20 sums of money on an ongoing basis to continuously improve all parts of our network.  When parts of the network = approach=20 pre-set utilization numbers, a well tested process kicks in = automatically to=20 upgrade these portions of the network. =20 In addition to these normal-course-of-business investments, we = have=20 large generational investments in things like DOCSIS 3.0.  Further, we continue to = develop and=20 release new services that benefit our customers as well.  Our network is a valuable = asset and no=20 rational company in our position would choose not to continue to = invest in,=20 care for, and improve such an asset.   I'd also prefer to stick = to the tech=20 talk here, rather than the econ stuff. =20 :-) 


Thanks = for asking=20 for feedback.  I'm sorry it is not at all positive.  While I = do=20 recognize efforts at more transparency and user notification as good = things,=20 the method itself fails the standards compatibility test. 

 

I am not sure I = understand what=20 standards compatability test=20 you are referring to.  = ??   (Unless of course this is=20 the earlier RFC you referred to in a different=20 email.) 

 

Anyhow Robb, at=20 this stage, I'd like to turn my attention to working with my = colleagues to=20 conduct our trials, find the best way to manage data flows to provide = the best=20 possible experience for all of our users, and let them be the judge. = In the=20 meantime, we will also continue our efforts as participants in this = IETF list=20 (and in the upcoming BoFs and other WGs at IETF-72) and our continuing = effort=20 to have a constructive technical dialogue with the broader community.=20

 

Thanks,=20 Jason

Robb Topolski =

------_=_NextPart_001_01C8CA95.BB1B4FD9-- --===============0113711511== 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 --===============0113711511==-- From p2pi-bounces@ietf.org Mon Jun 9 18:22:00 2008 Return-Path: X-Original-To: p2pi-archive@ietf.org Delivered-To: ietfarch-p2pi-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C2FB83A68C7; Mon, 9 Jun 2008 18:22:00 -0700 (PDT) X-Original-To: p2pi@core3.amsl.com Delivered-To: p2pi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7283F3A688D for ; Mon, 9 Jun 2008 18:21:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.28 X-Spam-Level: X-Spam-Status: No, score=-2.28 tagged_above=-999 required=5 tests=[AWL=0.318, 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 8uNYMd0soIpp for ; Mon, 9 Jun 2008 18:21:46 -0700 (PDT) Received: from neustar.com (ns6.neustar.com [156.154.16.88]) by core3.amsl.com (Postfix) with ESMTP id 431033A67AD for ; Mon, 9 Jun 2008 18:21:46 -0700 (PDT) DKIM-Signature: a=rsa-sha1; d=neustar.biz; s=neustarbiz; c=simple/simple; q=dns; t=1213060923; x=1213147323; h=From:Date:Subject:Message-ID:Content-class:Content-Type; b=VeAY34w6RbhJjHADkSdMU4N4qyWrKxkXtic9IgRo6ZcxKY2ip2YBtlclTgigzNZhceqlNwNkCtZn0R 2HvPZAoQ== Received: from ([10.31.13.50]) by stihiron2.va.neustar.com with ESMTP id 5202732.8485957; Mon, 09 Jun 2008 21:21:53 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 9 Jun 2008 21:21:54 -0400 Message-ID: In-Reply-To: <484DCA46.7050405@bennett.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [p2pi] Fwd: For those who think "User Fairness/Cost Fairness" isunacceptable... thread-index: AcjKkMPtFVBUKNXxTLCk7tMI6fl3+AABRehQ References: <3efc39a60806080822l575c83c1p2a370bbb20a41bd6@mail.gmail.com> <3efc39a60806080825yc1261ddmf2ce3da4b308a722@mail.gmail.com> <45AEC6EF95942140888406588E1A6602050F89D1@PACDCEXCMB04.cable.comcast.com> <3efc39a60806091639t3ff649a3i6421b1a334e458b7@mail.gmail.com><3efc39a60806091704t771b2e4ak8ef6c820abd15e80@mail.gmail.com> <484DCA46.7050405@bennett.com> From: "Peterson, Jon" To: "Richard Bennett" , "Robb Topolski" Cc: "Livingood, Jason" , p2pi@ietf.org Subject: Re: [p2pi] Fwd: For those who think "User Fairness/Cost Fairness" isunacceptable... X-BeenThere: p2pi@ietf.org X-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="===============0478096346==" Sender: p2pi-bounces@ietf.org Errors-To: p2pi-bounces@ietf.org This is a multi-part message in MIME format. --===============0478096346== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C8CA98.5D6F5703" This is a multi-part message in MIME format. ------_=_NextPart_001_01C8CA98.5D6F5703 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable =20 I'd like to second this. =20 We're certainly not here to pass judgment on Comcast or any other network provider. What the IETF can do is engineer tools that may improve the interaction between applications and the underlying network, where previous assumptions about the relationship between those entities have proven unreliable. The P2P case under examination here is such an instance, and thus we have a few choices about what behaviors we might tweak to alleviate the undesirable symptoms. =20 I'd like to keep the discussion here focused, to the degree that we can, on what engineering deliverables we can identify and act upon. Is there anything outside the proposed scope of TANA and ALTO that we've missed, and that we should consider for IETF action? As a part of this ongoing discussion, I personally find Comcast's updates on their planned trials valuable, and I think the data that will result from those trials could be very useful in refining the problem space as the IETF continues to think through these problems. I would certainly be disappointed if our prejudgment of those trials, or hostility to business models, ultimately deprived us of that data. =20 The manner in which Comcast chooses to operate their network, and collect revenues, is not something we can or should decide - nor should this mailing list be a pillory where we revisit management practices that no one here is going to advocate. =20 Jon Peterson NeuStar, Inc. =20 ________________________________ From: p2pi-bounces@ietf.org [mailto:p2pi-bounces@ietf.org] On Behalf Of Richard Bennett Sent: Monday, June 09, 2008 5:27 PM To: Robb Topolski Cc: p2pi@ietf.org; Livingood, Jason Subject: Re: [p2pi] Fwd: For those who think "User Fairness/Cost Fairness" isunacceptable... =20 This isn't a court of law, and it's not our mandate to determine who the good guys (or good practices) are and who's being bad. It's certainly not an established fact that an application-neutral per-user fairness regime is "disruptive to the intended use of the Internet" or any such thing; in fact, the evidence leads to quite a different conclusion. Similarly, packet inspection (deep or shallow, if there is such a thing) without retention for the purpose of prioritizing is quite a different animal than packet inspection for the purpose of retaining personal information to be used for commercial or other purposes.=20 Similarly, speculations about the viability of metered pricing are probably not productive, given that it's already the norm on most Internet access networks in the world. The Internet is, after all, a global phenomenon and not simply a slice of American life. I'd prefer to focus the energies of this group in a more productive direction, namely to identify means of harmonizing the needs and requirements of groups of users on shared network links, given that "infinite bandwidth at no cost" is outside the solution space. RB Robb Topolski wrote:=20 (Adding to my own message) On Mon, Jun 9, 2008 at 4:39 PM, Robb Topolski wrote: =20 On Mon, Jun 9, 2008 at 1:02 PM, Livingood, Jason wrote: =20 I was a bit thrown off by your RFC 1087 reference, "Ethics and the Internet" from 1989. Perhaps that RFC is somewhat geared towards a non-commercial past, when as it says, the Internet is a "national facility" used mostly by researchers.=20 The reference is historical, relating to "Recent events involving the hosts on the Internet and=20 in similar network infrastructures underscore the need to reiterate the professional responsibility every Internet user bears to colleagues ..." =20 Can you advise your specific technical areas of concern, as it relates to this RFC (see below)? They are these acts, which Comcast's current RST method and proposed "Protocol Agnostic" method violate. =20 (b) disrupts the intended use of the Internet, (c) wastes resources (people, capacity, computer) through such actions, (d) destroys the integrity of computer-based information, (e) compromises the privacy of users. =20 All, please be clear that WRT to RFC 1087 I'm using it as an example and expressing my criticisms at the methods being employed, not the persons and companies themselves. The effects of using Protocol discrimination or Consumption discrimination are these four effects above. =20 Comcast is here participating -- not here acting "unethically." Unfortunately, the title of RFC 1087 is something like "Ethics and the Internet." Please do not interpret this fact as a criticism of Comcast or its participation here. Please do interpret my message as a criticism of both the old and their new proposed method. Thank you to the individual who sent me a corrective message in private. It did look like a shot, and that wasn't what I was going for. --=20 Robb Topolski (robb@funchords.com) Hillsboro, Oregon USA http://www.funchords.com/=20 =20 ________________________________ =20 _______________________________________________ p2pi mailing list p2pi@ietf.org https://www.ietf.org/mailman/listinfo/p2pi =20 --=20 Richard Bennett ------_=_NextPart_001_01C8CA98.5D6F5703 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

 

I’d like to second = this.

 

We’re certainly not here to = pass judgment on Comcast or any other network provider. What the IETF can do = is engineer tools that may improve the interaction between applications and = the underlying network, where previous assumptions about the relationship = between those entities have proven unreliable. The P2P case under examination = here is such an instance, and thus we have a few choices about what behaviors we = might tweak to alleviate the undesirable = symptoms.

 

I’d like to keep the = discussion here focused, to the degree that we can, on what engineering deliverables we = can identify and act upon. Is there anything outside the proposed scope of = TANA and ALTO that we’ve missed, and that we should consider for IETF = action? As a part of this ongoing discussion, I personally find Comcast’s = updates on their planned trials valuable, and I think the data that will result = from those trials could be very useful in refining the problem space as the IETF = continues to think through these problems. I would certainly be disappointed if = our prejudgment of those trials, or hostility to business models, ultimately deprived us of that data.

 

The manner in which Comcast chooses = to operate their network, and collect revenues, is not something we can or = should decide - nor should this mailing list be a pillory where we revisit = management practices that no one here is going to advocate.

 

Jon = Peterson

NeuStar, = Inc.

 

From: p2pi-bounces@ietf.org [mailto:p2pi-bounces@ietf.org] = On Behalf Of Richard Bennett
Sent: Monday, June 09, = 2008 5:27 PM
To: Robb Topolski
Cc: p2pi@ietf.org; Livingood, Jason
Subject: Re: [p2pi] Fwd: = For those who think "User Fairness/Cost Fairness" = isunacceptable...

 

This isn't a court of law, and it's not our = mandate to determine who the good guys (or good practices) are and who's being bad. = It's certainly not an established fact that an application-neutral per-user = fairness regime is "disruptive to the intended use of the Internet" or = any such thing; in fact, the evidence leads to quite a different = conclusion.

Similarly, packet inspection (deep or shallow, if there is such a thing) without retention for the purpose of prioritizing is quite a different = animal than packet inspection for the purpose of retaining personal = information  to be used for commercial or other purposes.

Similarly, speculations about the viability of metered pricing are = probably not productive, given that it's already the norm on most Internet access = networks in the world. The Internet is, after all, a global phenomenon and not = simply a slice of American life.

I'd prefer to focus the energies of this group in a more productive = direction, namely to identify means of harmonizing the needs and requirements of = groups of users on shared network links, given that "infinite bandwidth at no cost" is outside the solution space.

RB

Robb Topolski wrote:

(Adding to my = own message)

On Mon, Jun 9, 2008 at 4:39 PM, Robb Topolski = <robb@funchords.com> wrote:

 

On Mon, Jun 9, 2008 at 1:02 PM, Livingood, = Jason <Jason_Livingood@cable.comcast.com> = wrote:

 

I was a bit thrown off by your RFC = 1087 reference, "Ethics and the Internet" from 1989.  Perhaps = that RFC is somewhat geared towards a non-commercial past, when as it says, = the Internet is a "national facility" used mostly by = researchers. 

The reference is historical, relating to = "Recent events involving the hosts on the = Internet and

in similar network = infrastructures underscore the need to reiterate the professional responsibility every = Internet user bears to colleagues ..."

 

Can you advise your specific = technical areas of concern, as it relates to this RFC (see = below)?


They are these acts, which Comcast's current RST method and proposed "Protocol Agnostic" method violate.
 

    &nbs= p; (b) disrupts the intended use of the Internet,

      (c) = wastes resources (people, capacity, computer) through such
       &nb= sp;  actions,

      (d) = destroys the integrity of computer-based information,

    &nbs= p; (e) compromises the privacy of users.

 


All, please be clear that WRT to RFC 1087 I'm using it as an example and expressing my criticisms at the methods being employed, not the persons = and companies themselves.  The effects of using Protocol discrimination = or Consumption discrimination are these four effects above. 

Comcast is here participating -- not here acting = "unethically."  Unfortunately, the title of RFC 1087 is something like "Ethics and = the Internet."  Please do not interpret this fact as a criticism = of Comcast or its participation here.  Please do interpret my message = as a criticism of both the old and their new proposed method.

Thank you to the individual who sent me a corrective message in = private.  It did look like a shot, and that wasn't what I was going for.


--
Robb Topolski (robb@funchords.com)
Hillsboro, = Oregon USA
http://www.funchords.com/ 

 






 
______________________________________________=
_
p2pi mailing =
list
p2pi@ietf.org<=
/pre>
https://www.ietf.org/=
mailman/listinfo/p2pi
  











-- 
Richard =
Bennett
------_=_NextPart_001_01C8CA98.5D6F5703-- --===============0478096346== 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 --===============0478096346==-- From p2pi-bounces@ietf.org Mon Jun 9 18:44:08 2008 Return-Path: X-Original-To: p2pi-archive@ietf.org Delivered-To: ietfarch-p2pi-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B1C3E3A6848; Mon, 9 Jun 2008 18:44:08 -0700 (PDT) X-Original-To: p2pi@core3.amsl.com Delivered-To: p2pi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 38C0A3A6848 for ; Mon, 9 Jun 2008 18:44:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.623 X-Spam-Level: X-Spam-Status: No, score=-1.623 tagged_above=-999 required=5 tests=[AWL=0.353, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tXBTRllCOZVd for ; Mon, 9 Jun 2008 18:44:05 -0700 (PDT) Received: from wf-out-1314.google.com (wf-out-1314.google.com [209.85.200.172]) by core3.amsl.com (Postfix) with ESMTP id 4CA043A67AD for ; Mon, 9 Jun 2008 18:44:04 -0700 (PDT) Received: by wf-out-1314.google.com with SMTP id 27so2561710wfd.31 for ; Mon, 09 Jun 2008 18:44:25 -0700 (PDT) Received: by 10.142.107.1 with SMTP id f1mr1770727wfc.10.1213062265458; Mon, 09 Jun 2008 18:44:25 -0700 (PDT) Received: by 10.142.186.7 with HTTP; Mon, 9 Jun 2008 18:44:25 -0700 (PDT) Message-ID: <3efc39a60806091844m54dd2dc5w3107ea875efc0c40@mail.gmail.com> Date: Mon, 9 Jun 2008 18:44:25 -0700 From: "Robb Topolski" To: "Livingood, Jason" In-Reply-To: <45AEC6EF95942140888406588E1A6602045CBA87@PACDCEXCMB04.cable.comcast.com> MIME-Version: 1.0 References: <45AEC6EF95942140888406588E1A6602045CBA87@PACDCEXCMB04.cable.comcast.com> Cc: p2pi@ietf.org Subject: Re: [p2pi] Follow-Up 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: multipart/mixed; boundary="===============1959139155==" Sender: p2pi-bounces@ietf.org Errors-To: p2pi-bounces@ietf.org --===============1959139155== Content-Type: multipart/alternative; boundary="----=_Part_7999_4267158.1213062265454" ------=_Part_7999_4267158.1213062265454 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline 2008/6/9 Livingood, Jason : > First, I would say that it seems that this example user should configure > their home gateway router to allocate a specific amount of LAN bandwidth for > their VoIP service, so that their VoIP service would not be overwhelmed by > and negatively affected by the upload of several GB of digital photos. > Right, but such devices need to know both numbers in order to reserve it. What's left is the unreserved bandwidth -- the total minus the reserved. The protocol-agnostic method has the effect of lowering the total, rendering any such settings designed to reserve bandwidth meaningless.. Secondly, without any form of network management (current or future), the > heavy use of whatever apps by a few people at times of congestion would > interfere with the same VoIP call. > > As I've said before, network developers expect an Internet with occasional congestion. An application that is not tolerant of some congestion won't last on the Internet very long. > As we stated up at MIT, our trial is NOT applying rate limits to the > subscribers. So for example, we're NOT taking a 16Mbps/2Mbps customer > down to 1Mbps/512Kbps. The user's bits we are talking about are simply > assigned a lower QoS for some period of time, assuming (1) that the network > is in a near-congestion state and (2) the user has crossed a specific > threshold of usage for a specific period of time (both conditions must be > met). > > Which is like saying that instead of pot-holing the road, you're letting air out of their tires. Whether they get poor performance due to throttling or poor performance due to dropping or delaying packets, the result is that they get poor performance. > But perhaps more importantly, devices that "assume" that the network's > bandwidth is a fixed constant are flawed devices. > > I'm inclined to agree with you. However, most of the devices out there disagree with "us" -- and we should recognize that. > Actually, you may be surprised to discover that the ISP is often the *first > *call for many of these customers. > > OF COURSE it is. Let's see, you work for an ISP. I worked for a networking software/hardware vendor. From wherever I sit, the grass is always greener "over there." :-) Unfortunately, you have made a few statements to the effect that our > investment in our network is largely static, meaning that every few years we > decide whether or not to invest in the network. > > Please go back and read again. When the subject has come up, I've given you credit for spending the most money out of the list of MSOs on infrastructure growth. I AM WORRIED that innovations like Deep Packet Inspection will cause such investment to flatten -- even in Comcast -- but I have not taken the position that it stopped investment in it. I'm a Comcast Fan, and I remain a customer. I got DSL in a deal for my roommate, but I choose to use Comcast. I've posted that fact quite publically. But a line was crossed here that ISPs shouldn't cross, and I documented it. It's important, doubly-so given Comcast's leadership position in its industry. I very much want Comcast to remain the open-ports, low-interference ISP it has always been. As more and more *ideas *about stuff to put in the middle of the network to monitor and change and monetize what's happening on OUR Internet, the more concerned I become about the future. Because no matter how small industry-giant Comcast decides it is willing to intrude, the farther it pushes the bounds that poorer or less disciplined ISPs feel empowered for their more intrusive interceptions. Keeping Comcast's large network one that is conforming to the standards and qualified practices helps keep everyone's network that way. I've been a fan. I am a fan. And I plan to be a fan. But I've also been honest and I've been clearly rooting for you to use your leadership position for things that are good for the net. > When parts of the network approach pre-set utilization numbers, a well > tested process kicks in automatically to upgrade these portions of the > network. > > As I said before, I do know this. I've quoted Tony Werner in 2-year-old articles on this very topic. I know that you upgrade regularly -- so it's not me that you're arguing with. Robb -- Robb Topolski (robb@funchords.com) Hillsboro, Oregon USA http://www.funchords.com/ ------=_Part_7999_4267158.1213062265454 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline

2008/6/9 Livingood, Jason <Jason_Livingood@cable.comcast.com>:
First, I would say that it seems that this example user should configure their home gateway router to allocate a specific amount of LAN bandwidth for their VoIP service, so that their VoIP service would not be overwhelmed by and negatively affected by the upload of several GB of digital photos.

Right, but such devices need to know both numbers in order to reserve it.  What's left is the unreserved bandwidth -- the total minus the reserved. 

The protocol-agnostic method has the effect of lowering the total, rendering any such settings designed to reserve bandwidth meaningless..


Secondly, without any form of network management (current or future), the heavy use of  whatever apps by a few people at times of congestion would interfere with the same VoIP call.


As I've said before, network developers expect an Internet with occasional congestion.  An application that is not tolerant of some congestion won't last on the Internet very long.

 
As we stated up at MIT, our trial is NOT applying rate limits to the subscribers.  So for example, we're NOT taking a 16Mbps/2Mbps customer down to 1Mbps/512Kbps.  The user's bits we are talking about are simply assigned a lower QoS for some period of time, assuming (1) that the network is in a near-congestion state and (2) the user has crossed a specific threshold of usage for a specific period of time (both conditions must be met). 

Which is like saying that instead of pot-holing the road, you're letting air out of their tires.  Whether they get poor performance due to throttling or poor performance due to dropping or delaying packets, the result is that they get poor performance.


 
But perhaps more importantly, devices that "assume" that the network's bandwidth is a fixed constant are flawed devices.
I'm inclined to agree with you.  However, most of the devices out there disagree with "us" -- and we should recognize that.
 

Actually, you may be surprised to discover that the ISP is often the first call for many of these customers. 

OF COURSE it is.  Let's see, you work for an ISP.  I worked for a networking software/hardware vendor.  From wherever I sit, the grass is always greener "over there." :-)

Unfortunately, you have made a few statements to the effect that our investment in our network is largely static, meaning that every few years we decide whether or not to invest in the network. 

Please go back and read again. 

When the subject has come up, I've given you credit for spending the most money out of the list of MSOs on infrastructure growth.  I AM WORRIED that innovations like Deep Packet Inspection will cause such investment to flatten -- even in Comcast -- but I have not taken the position that it stopped investment in it.

I'm a Comcast Fan, and I remain a customer.  I got DSL in a deal for my roommate, but I choose to use Comcast. I've posted that fact quite publically.  But a line was crossed here that ISPs shouldn't cross, and I documented it.  It's important, doubly-so given Comcast's leadership position in its industry.  I very much want Comcast to remain the open-ports, low-interference ISP it has always been.

As more and more ideas about stuff to put in the middle of the network to monitor and change and monetize what's happening on OUR Internet, the more concerned I become about the future.  Because no matter how small industry-giant Comcast decides it is willing to intrude, the farther it pushes the bounds that poorer or less disciplined ISPs feel empowered for their more intrusive interceptions.  Keeping Comcast's large network one that is conforming to the standards and qualified practices helps keep everyone's network that way.

I've been a fan.  I am a fan.  And I plan to be a fan.  But I've also been honest and I've been clearly rooting for you to use your leadership position for things that are good for the net.
 

When parts of the network approach pre-set utilization numbers, a well tested process kicks in automatically to upgrade these portions of the network. 

As I said before, I do know this.  I've quoted Tony Werner in 2-year-old articles on this very topic.  I know that you upgrade regularly -- so it's not me that you're arguing with.

Robb
 




--
Robb Topolski (robb@funchords.com)
Hillsboro, Oregon USA
http://www.funchords.com/ ------=_Part_7999_4267158.1213062265454-- --===============1959139155== 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 --===============1959139155==-- From p2pi-bounces@ietf.org Mon Jun 9 21:44:46 2008 Return-Path: X-Original-To: p2pi-archive@ietf.org Delivered-To: ietfarch-p2pi-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 080193A67D0; Mon, 9 Jun 2008 21:44:46 -0700 (PDT) X-Original-To: p2pi@core3.amsl.com Delivered-To: p2pi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B62863A67D0 for ; Mon, 9 Jun 2008 21:44:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.645 X-Spam-Level: X-Spam-Status: No, score=-1.645 tagged_above=-999 required=5 tests=[AWL=0.331, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NYEiAxkNfjRd for ; Mon, 9 Jun 2008 21:44:43 -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 62DF13A676A for ; Mon, 9 Jun 2008 21:44:43 -0700 (PDT) Received: by wf-out-1314.google.com with SMTP id 27so2627489wfd.31 for ; Mon, 09 Jun 2008 21:45:04 -0700 (PDT) Received: by 10.142.148.10 with SMTP id v10mr1813072wfd.317.1213073104193; Mon, 09 Jun 2008 21:45:04 -0700 (PDT) Received: by 10.142.186.7 with HTTP; Mon, 9 Jun 2008 21:45:04 -0700 (PDT) Message-ID: <3efc39a60806092145y60c0dff6q18c783a44a71e31@mail.gmail.com> Date: Mon, 9 Jun 2008 21:45:04 -0700 From: "Robb Topolski" To: p2pi@ietf.org MIME-Version: 1.0 Subject: [p2pi] ALL PLEASE READ (Re: For those who think "User Fairness/Cost Fairness" isunacceptable...) X-BeenThere: p2pi@ietf.org X-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="===============2139559441==" Sender: p2pi-bounces@ietf.org Errors-To: p2pi-bounces@ietf.org --===============2139559441== Content-Type: multipart/alternative; boundary="----=_Part_8757_30881701.1213073104199" ------=_Part_8757_30881701.1213073104199 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline All, When the current controversy erupted, it was because the top Cable MSO was using equipment that tampered with communications between endpoints by replacing end-point packets with ones designed to tear TCP connections with the RST flag. The Standards impact of that practice is rather clear and nobody suggests that it continue (although this practice continues today). I've been among the first to call upon Comcast to adopt a standards-based solution, and barring the availability of any solution that might work for them, to participate in the IETF body and help to craft one. Either in spite of that call or because of it, Comcast is here and is making the attempt. They have made great strides. They are more open than before. And -- quite appropriately and laudably -- *they've asked for feedback*. The IETF is concerned with the evolution of the Internet architecture and the smooth operation of the Internet. We are a Standards body. The purpose of a Standard is interoperability. The test of a standard is relevance and quality of the information provided. The absence of a Standard does not prohibit a thing, however the presence of a standard does explain how a thing ought to be done if it is to be done. We have no lack of standards addressing the questions of congestion control and prioritization (a large feature of the new protocol-agnostic method that Comcast is testing). Jon, we are not here to pass judgment on Comcast. However, we have been asked a relevant question about topics in our purview and we should not be shy about answering it. Comcast stands to invest a lot of time and money in transitioning their systems from a less appropriate to a hopefully more appropriate management method. They've described it to us. They're trialling it. And they want feedback. I say, "Speak now, Standards body, or forever hold your peace." Whether we like it or not, a non-answer is going to be interpreted as approval. This time, we have a fair warning, because Comcast is about to spend the time and money if they like the results of their trial. I stand by everything that I've said about the Protocol-Agnostic method. It takes no particular bravery to do so -- the facts are quite plain. The problem statement that it attempts to solve is technically insufficient. >From an interoperability perspective, the solution proposed hurts innovation, investment, users, and the community as it lacks the detail and predictability/testability required to be useful. I do appreciate the openness shown, and regret not being able to be more positive about it. Some see me as an advocate. If you do, it's because you've been involved in policy. I'm a software tester. Network Neutrality to me is not a campaign, it is simply a side-effect caused by how the Internet was designed to work. It is neutral because it generally lacks the information to be otherwise. In May of 2007, I posted what amounts to a "bug report" about my ISP's network. And while I do have opinions, "policy advocacy" is not what is driving me. Whats more important to me is something that testers call "bug advocacy." (Please see http://www.google.com/search?q=bug+advocacy for several good descriptions.) I want to see my bug fixed -- *really *fixed -- not simply replaced with misbehavior just as repugnant as the original. We're not here to pass judgment on Comcast. That will be someone else's job. But, does Comcast's new protocol-agnostic congestion-management method pass the muster of the IETF? It's an engineering question, asked of an engineering body. If we're not the right body to pass judgment on *that question*, then nobody is. If we fail to object now, when the reasons are so plain, then why would we expect anybody to ask us ever again? Thank you Robb Topolski -- Robb Topolski (robb@funchords.com) Hillsboro, Oregon USA http://www.funchords.com/ ------=_Part_8757_30881701.1213073104199 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline All,

When the current controversy erupted, it was because the top Cable MSO was using equipment that tampered with communications between endpoints by replacing end-point packets with ones designed to tear TCP connections with the RST flag.  The Standards impact of that practice is rather clear and nobody suggests that it continue (although this practice continues today).

I've been among the first to call upon Comcast to adopt a standards-based solution, and barring the availability of any solution that might work for them, to participate in the IETF body and help to craft one.  Either in spite of that call or because of it, Comcast is here and is making the attempt.  They have made great strides.  They are more open than before.  And -- quite appropriately and laudably -- they've asked for feedback. 

The IETF is concerned with the evolution of the Internet architecture and the smooth operation of the Internet.  We are a Standards body.  The purpose of a Standard is interoperability.  The test of a standard is relevance and quality of the information provided.  The absence of a Standard does not prohibit a thing, however the presence of a standard does explain how a thing ought to be done if it is to be done.  We have no lack of standards addressing the questions of congestion control and prioritization (a large feature of the new protocol-agnostic method that Comcast is testing).

Jon, we are not here to pass judgment on Comcast.  However, we have been asked a relevant question about topics in our purview and we should not be shy about answering it.  Comcast stands to invest a lot of time and money in transitioning their systems from a less appropriate to a hopefully more appropriate management method.  They've described it to us.  They're trialling it.  And they want feedback. 

I say, "Speak now, Standards body, or forever hold your peace."  Whether we like it or not, a non-answer is going to be interpreted as approval. This time, we have a fair warning, because Comcast is about to spend the time and money if they like the results of their trial.

I stand by everything that I've said about the Protocol-Agnostic method.  It takes no particular bravery to do so -- the facts are quite plain. The problem statement that it attempts to solve is technically insufficient.  From an interoperability perspective, the solution proposed hurts innovation, investment, users, and the community as it lacks the detail and predictability/testability required to be useful.  I do appreciate the openness shown, and regret not being able to be more positive about it.

Some see me as an advocate. If you do, it's because you've been involved in policy. I'm a software tester. Network Neutrality to me is not a campaign, it is simply a side-effect caused by how the Internet was designed to work. It is neutral because it generally lacks the information to be otherwise. In May of 2007, I posted what amounts to a "bug report" about my ISP's network.  And while I do have opinions, "policy advocacy" is not what is driving me.  Whats more important to me is something that testers call "bug advocacy." (Please see http://www.google.com/search?q=bug+advocacy for several good descriptions.) I want to see my bug fixed -- really fixed -- not simply replaced with misbehavior just as repugnant as the original.

We're not here to pass judgment on Comcast.  That will be someone else's job.

But, does Comcast's new protocol-agnostic congestion-management method pass the muster of the IETF?  It's an engineering question, asked of an engineering body.  If we're not the right body to pass judgment on that question, then nobody is.  If we fail to object now, when the reasons are so plain, then why would we expect anybody to ask us ever again?

Thank you

Robb Topolski


--
Robb Topolski (robb@funchords.com)
Hillsboro, Oregon USA
http://www.funchords.com/ ------=_Part_8757_30881701.1213073104199-- --===============2139559441== 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 --===============2139559441==-- From p2pi-bounces@ietf.org Wed Jun 11 16:44:32 2008 Return-Path: X-Original-To: p2pi-archive@ietf.org Delivered-To: ietfarch-p2pi-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 162033A6A53; Wed, 11 Jun 2008 16:44:32 -0700 (PDT) X-Original-To: p2pi@core3.amsl.com Delivered-To: p2pi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DE2583A68CE for ; Wed, 11 Jun 2008 16:44:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.264 X-Spam-Level: X-Spam-Status: No, score=-2.264 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RTi8c11iPdJH for ; Wed, 11 Jun 2008 16:44:22 -0700 (PDT) Received: from outbound-mail-124.bluehost.com (outbound-mail-124.bluehost.com [67.222.38.24]) by core3.amsl.com (Postfix) with SMTP id 3FD693A6ABF for ; Wed, 11 Jun 2008 16:44:16 -0700 (PDT) Received: (qmail 22525 invoked by uid 0); 11 Jun 2008 23:44:42 -0000 Received: from unknown (HELO host46.hostmonster.com) (74.220.202.46) by outboundproxy4.bluehost.com with SMTP; 11 Jun 2008 23:44:42 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=bennett.com; h=Received:Message-ID:Date:From:Organization:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:Content-Type:X-Identified-User:DomainKey-Status; b=vJctwxWz/ABNHVUbdsRnbkg5tyyIbxMw08Q6nTBQ9LEjTl0hnmgr/6DtedC+ORR82CxTZ+uR+N3m8esu7edWwwhgJ+TN2VMUQ8kVr0lF7KRTmpI6Kh8WUSR3fHdSXbFb; Received: from adsl-69-106-251-234.dsl.pltn13.pacbell.net ([69.106.251.234] helo=[192.168.1.2]) by host46.hostmonster.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.68) (envelope-from ) id 1K6Zzd-0004ZG-Te; Wed, 11 Jun 2008 17:44:42 -0600 Message-ID: <48506369.8090409@bennett.com> Date: Wed, 11 Jun 2008 16:44:41 -0700 From: Richard Bennett Organization: Network Strategies User-Agent: Thunderbird 2.0.0.14 (X11/20080501) MIME-Version: 1.0 To: Henning Schulzrinne References: <06BEE447-3D17-45D0-A73B-E248C3141F51@ICSI.Berkeley.EDU> <484C1958.2010900@isi.edu> <8719C03C-9EC9-482B-9536-1784F95DC8A8@ICSI.Berkeley.EDU> <484CC2A5.6050105@isi.edu> <1621FECD-ED33-4BF2-88D0-199D6FA75993@ICSI.Berkeley.EDU> <484D2DE8.7020407@isi.edu> <4D7FB692-F754-4DD7-A63C-BA96C5FF5E05@ICSI.Berkeley.EDU> <484D450E.4060806@isi.edu> <86DEA620-3C64-4C5D-A2A6-C4CD064B5AE1@ICSI.Berkeley.EDU> <484D5868.9000209@isi.edu> <5C7D6FCF-4CF7-425E-8A17-A60DB8F07272@ICSI.Berkeley.EDU> <484D7DC6.1020207@bennett.com> <64378741-7169-4FEE-84F9-9FF632C865B6@cs.columbia.edu> In-Reply-To: <64378741-7169-4FEE-84F9-9FF632C865B6@cs.columbia.edu> X-Identified-User: {842:host46.hostmonster.com:bennett1:bennett.com} {sentby:smtp auth 69.106.251.234 authed with richard@bennett.com} DomainKey-Status: no signature Cc: p2pi@ietf.org, Nicholas Weaver Subject: Re: [p2pi] One more proposed definition of fairness... X-BeenThere: p2pi@ietf.org X-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="===============0848708412==" Sender: p2pi-bounces@ietf.org Errors-To: p2pi-bounces@ietf.org This is a multi-part message in MIME format. --===============0848708412== Content-Type: multipart/alternative; boundary="------------040308060804040603020300" This is a multi-part message in MIME format. --------------040308060804040603020300 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Comment below: Henning Schulzrinne wrote: > On Jun 9, 2008, at 3:00 PM, Richard Bennett wrote: >> Accepting statistical multiplexing as a design constraint from the >> get-go will help this group make faster progress. > The problem is that we'll get systems that are not going to work as > advertised, from a user perspective. We already have such systems, largely because we don't know how to mandate meaningful disclosure. It strikes me as going the wrong way around to say that ISPs have to provide CIR because that's the only thing that can be adequately communicated to the customer in a way that he can't misunderstand. If we go that way, we lose the benefits of packet networking in the burst scenario and most of the economics go down the tube as well. So rather than back off statistical multiplexing, it strikes me as more beneficial to develop some standard metrics that enable consumer advocates, if not consumers themselves, to evaluate different services. These metrics would include "mean information rates" at various levels of latency, the critical piece of a "buckets of packets" system. I'd like to be able to shop for an Internet access account that provided me with a bandwidth/latency profile that enabled me to successfully get one VoIP session through at the same time that three people surfed the web and four video stream downloads are in progress. There's no technical barrier to building such a network service, once the video stream downloads are managed as scavenger class activities (less that BE) and the VoIP is managed as a better-than-BE service. But how would the ISP advertise this service? The terms that are needed aren't part of the marketing lexicon at the moment, so they really do need to be developed. I mention this here because the next step after developing standards for P2P Infrastructure improvements, whether the system is based on optimum route discovery or caching, will be to communicate to the market that the system is in place and working at ISP XYZ. Are they going to say "Blazing Internet Service, now with Oracles and Scavengers!!!", or what? RB -- Richard Bennett --------------040308060804040603020300 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Comment below:

Henning Schulzrinne wrote:
On Jun 9, 2008, at 3:00 PM, Richard Bennett wrote:
Accepting statistical multiplexing as a design constraint from the get-go will help this group make faster progress.
The problem is that we'll get systems that are not going to work as advertised, from a user perspective.
We already have such systems, largely because we don't know how to mandate meaningful disclosure. It strikes me as going the wrong way around to say that ISPs have to provide CIR because that's the only thing that can be adequately communicated to the customer in a way that he can't misunderstand. If we go that way, we lose the benefits of packet networking in the burst scenario and most of the economics go down the tube as well. So rather than back off statistical multiplexing, it strikes me as more beneficial to develop some standard metrics that enable consumer advocates, if not consumers themselves, to evaluate different services.

These metrics would include "mean information rates" at various levels of latency, the critical piece of a "buckets of packets" system. I'd like to be able to shop for an Internet access account that provided me with a bandwidth/latency profile that enabled me to successfully get one VoIP session through at the same time that three people surfed the web and four video stream downloads are in progress. There's no technical barrier to building such a network service, once the video stream downloads are managed as scavenger class activities (less that BE) and the VoIP is managed as a better-than-BE service.

But how would the ISP advertise this service? The terms that are needed aren't part of the marketing lexicon at the moment, so they really do need to be developed.

I mention this here because the next step after developing standards for P2P Infrastructure improvements, whether the system is based on optimum route discovery or caching, will be to communicate to the market that the system is in place and working at ISP XYZ. Are they going to say "Blazing Internet Service, now with Oracles and Scavengers!!!", or what?

RB
 
-- 
Richard Bennett
--------------040308060804040603020300-- --===============0848708412== 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 --===============0848708412==-- From p2pi-bounces@ietf.org Wed Jun 11 17:36: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 CC2063A67DA; Wed, 11 Jun 2008 17:36: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 7A5183A67DA for ; Wed, 11 Jun 2008 17:36:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9fBv6jQuhJqB for ; Wed, 11 Jun 2008 17:36:15 -0700 (PDT) Received: from outgoing.csail.mit.edu (outgoing.csail.mit.edu [128.30.2.149]) by core3.amsl.com (Postfix) with ESMTP id EA6823A67A6 for ; Wed, 11 Jun 2008 17:36:14 -0700 (PDT) Received: from pool-71-178-142-83.washdc.east.verizon.net ([71.178.142.83] helo=[192.168.1.42]) by outgoing.csail.mit.edu with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.63) (envelope-from ) id 1K6anu-0006rV-Gm; Wed, 11 Jun 2008 20:36:38 -0400 Message-Id: <39ED814C-BEA0-4BDF-B7B1-9BE0B480991E@csail.mit.edu> From: Daniel Weitzner To: Nicholas Weaver In-Reply-To: <06BEE447-3D17-45D0-A73B-E248C3141F51@ICSI.Berkeley.EDU> Mime-Version: 1.0 (Apple Message framework v924) Date: Wed, 11 Jun 2008 20:36:37 -0400 References: <06BEE447-3D17-45D0-A73B-E248C3141F51@ICSI.Berkeley.EDU> X-Mailer: Apple Mail (2.924) Cc: p2pi@ietf.org Subject: Re: [p2pi] One more proposed definition of fairness... X-BeenThere: p2pi@ietf.org X-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 Reflecting on the thread that followed Nick's original proposal (quoted below).... I'd suggest that there are actually two kinds of fairness under discussion: 1. fairness between ISPs and their customers: you get the bandwidth and latency you pay for where those values are averaged over some stated period 2. fairness amongst network users: there are network mechanisms that guard against some traffic (perhaps generated by the hypothesized 5%) consistently degrading the traffic of others. That is, even though I may be receiving the promised average bandwidth as measured over a long period of time, the instantaneous performance is poor enough that I feel it. From the comments I've read I'll go out on a limb and suggest that no one really disagrees with the importance of achieving either notion. I'll go further on a said limb and suggest that the IETF concentrate on mechanisms for enabling user-to-user fairness (#2) because it seems like a tractable engineering problem. User-to-user fairness is necessary but not sufficient to achieving user-to-ISP fairness (#1). It is the case that even with user-to-user fairness, ISPs may have to re-think their network provisioning in order to live up to their contractual and/or marketing promises made to users. That, however, is a business and regulatory problem. I do agree that it is important to have verifiable service metrics, but am not sure that this is the right place to sort those out. On Jun 8, 2008, at 12:19 PM, Nicholas Weaver wrote: > (Buried in a previous mail, but I'd like comments on this separately) > > > How does the following sound as one possible ideal goal for user- > fairness: > > "Mechanisms to enable the network to enforce traffic such that, in the > presence of congestion, a user's congestion control response becomes > equivalent to aggregating all traffic from that user into a single TCP > stream." > > _______________________________________________ > p2pi mailing list > p2pi@ietf.org > https://www.ietf.org/mailman/listinfo/p2pi -- Daniel J. Weitzner +1.617.253.8036 Director, MIT Decentralized Information Group Principal Research Scientist, MIT CSAIL W3C Technology & Society Policy Director http://www.w3.org/People/Weitzner.html blog: http://people.w3.org/~djweitzner/blog/ _______________________________________________ p2pi mailing list p2pi@ietf.org https://www.ietf.org/mailman/listinfo/p2pi From p2pi-bounces@ietf.org Wed Jun 11 18:51: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 D4D6F3A6918; Wed, 11 Jun 2008 18:51: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 A779F3A6843 for ; Wed, 11 Jun 2008 18:51:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.264 X-Spam-Level: X-Spam-Status: No, score=-2.264 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zwLgUhVpYPRn for ; Wed, 11 Jun 2008 18:51:32 -0700 (PDT) Received: from outbound-mail-21.bluehost.com (outbound-mail-21.bluehost.com [69.89.21.16]) by core3.amsl.com (Postfix) with SMTP id 26FD33A68AF for ; Wed, 11 Jun 2008 18:51:14 -0700 (PDT) Received: (qmail 20857 invoked by uid 0); 12 Jun 2008 01:51:37 -0000 Received: from unknown (HELO host46.hostmonster.com) (74.220.202.46) by outboundproxy2.bluehost.com with SMTP; 12 Jun 2008 01:51:37 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=bennett.com; h=Received:Message-ID:Date:From:Organization:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:Content-Type:X-Identified-User:DomainKey-Status; b=vYdlDT44URcc8FWtphKtJeJ3PU7/FsJ6mE5R5L36kZNBHFGD+3Wn9vzWaz3bUiiZKMuvauQ/t1IMsWWuwIGpZ/E/C0DfVn9caREvdI01pe9u6aT7hE5ryDwOEkb4vnYv; Received: from adsl-69-106-251-234.dsl.pltn13.pacbell.net ([69.106.251.234] helo=[192.168.1.2]) by host46.hostmonster.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.68) (envelope-from ) id 1K6byT-0000kL-7E; Wed, 11 Jun 2008 19:51:37 -0600 Message-ID: <48508129.4040701@bennett.com> Date: Wed, 11 Jun 2008 18:51:37 -0700 From: Richard Bennett Organization: Network Strategies User-Agent: Thunderbird 2.0.0.14 (X11/20080501) MIME-Version: 1.0 To: Daniel Weitzner References: <06BEE447-3D17-45D0-A73B-E248C3141F51@ICSI.Berkeley.EDU> <39ED814C-BEA0-4BDF-B7B1-9BE0B480991E@csail.mit.edu> In-Reply-To: <39ED814C-BEA0-4BDF-B7B1-9BE0B480991E@csail.mit.edu> X-Identified-User: {842:host46.hostmonster.com:bennett1:bennett.com} {sentby:smtp auth 69.106.251.234 authed with richard@bennett.com} DomainKey-Status: no signature Cc: p2pi@ietf.org Subject: Re: [p2pi] One more proposed definition of fairness... X-BeenThere: p2pi@ietf.org X-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="===============0821091664==" Sender: p2pi-bounces@ietf.org Errors-To: p2pi-bounces@ietf.org This is a multi-part message in MIME format. --===============0821091664== Content-Type: multipart/alternative; boundary="------------020804030700060806010900" This is a multi-part message in MIME format. --------------020804030700060806010900 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Comments in-line: Daniel Weitzner wrote: > Reflecting on the thread that followed Nick's original proposal > (quoted below).... > > I'd suggest that there are actually two kinds of fairness under > discussion: > > 1. fairness between ISPs and their customers: you get the bandwidth > and latency you pay for where those values are averaged over some > stated period This isn't the scope of "fairness" as it's generally understood in networking standards, at least not the ones that I've worked on. I would suggest that "disclosure" or something along that line is the more relevant term. When engineers specify "fairness" mechanism, they generally have to do with your item number 2 below, an aspect of the multiple-access problem. > 2. fairness amongst network users: there are network mechanisms that > guard against some traffic (perhaps generated by the hypothesized 5%) > consistently degrading the traffic of others. That is, even though I > may be receiving the promised average bandwidth as measured over a > long period of time, the instantaneous performance is poor enough that > I feel it. > > From the comments I've read I'll go out on a limb and suggest that no > one really disagrees with the importance of achieving either notion. > > I'll go further on a said limb and suggest that the IETF concentrate > on mechanisms for enabling user-to-user fairness (#2) because it seems > like a tractable engineering problem. User-to-user fairness is > necessary but not sufficient to achieving user-to-ISP fairness (#1). > It is the case that even with user-to-user fairness, ISPs may have to > re-think their network provisioning in order to live up to their > contractual and/or marketing promises made to users. That, however, is > a business and regulatory problem. I do agree that it is important to > have verifiable service metrics, but am not sure that this is the > right place to sort those out. > The suggestion for a TANA BOF in Dublin mentions the importance of metrics, to wit, relevant text highlighted: (3) A mechanism that lets an application that can transfer data from or to several potential peers (i.e., servers, caches, end systems) select a subset of peers for efficient transmission in a way that is aligned with the dynamic interconnection structure of the network operators that provide connectivity to those peers. Application designers, network equipment vendors and network operators will need to collaborate on this work item to define *what kinds of dynamic interconnection information is useful to applications*, how to obtain it, and how to provide it to applications, resulting in a generic mechanism that is broadly applicable to many current and future applications. Given that applications need dynamic interconnection information - metrics - it seems like a small step to aggregate and export this for the purpose of service verification. But perhaps service verification is simply something that can be understood as an "application." In any event, "fairness" is only one of the issues in this work area, taking its place alongside congestion, optimization, and others. RB -- Richard Bennett --------------020804030700060806010900 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Comments in-line:

Daniel Weitzner wrote: 
Reflecting on the thread that followed Nick's original proposal  
(quoted below)....

I'd suggest that there are actually two kinds of fairness under  
discussion:

1. fairness between ISPs and their customers: you get the bandwidth  
and latency you pay for where those values are averaged over some  
stated period
This isn't the scope of "fairness" as it's generally understood in networking standards, at least not the ones that I've worked on. I would suggest that "disclosure" or something along that line is the more relevant term. When engineers specify "fairness" mechanism, they generally have to do with your item number 2 below, an aspect of the multiple-access problem.
2. fairness amongst network users: there are network mechanisms that  
guard against some traffic (perhaps generated by the hypothesized 5%)  
consistently degrading the traffic of others. That is, even though I  
may be receiving the promised average bandwidth as measured over a  
long period of time, the instantaneous performance is poor enough that  
I feel it.

 From the comments I've read I'll go out on a limb and suggest that no  
one really disagrees with the importance of achieving either notion.

I'll go further on a said limb and suggest that the IETF concentrate  
on mechanisms for enabling user-to-user fairness (#2) because it seems  
like a tractable engineering problem. User-to-user fairness is  
necessary but not sufficient to achieving user-to-ISP fairness (#1).  
It is the case that even with user-to-user fairness, ISPs may have to  
re-think their network provisioning in order to live up to their  
contractual and/or marketing promises made to users. That, however, is  
a business and regulatory problem. I do agree that it is important to  
have verifiable service metrics, but am not sure that this is the  
right place to sort those out.
The suggestion for a TANA BOF in Dublin mentions the importance of metrics, to wit, relevant text highlighted:

 
(3) A mechanism that lets an application that can
    transfer data from or to several potential peers (i.e.,
    servers, caches, end systems) select a subset of peers
    for efficient transmission in a way that is aligned with
    the dynamic interconnection structure of the network
    operators that provide connectivity to those peers.
    Application designers, network equipment vendors and
    network operators will need to collaborate on this work
    item to define what kinds of dynamic interconnection
    information is useful to applications, how to obtain it,
    and how to provide it to applications, resulting in a
    generic mechanism that is broadly applicable to many
    current and future applications.
Given that applications need dynamic interconnection information - metrics - it seems like a small step to aggregate and export this for the purpose of service verification. But perhaps service verification is simply something that can be understood as an "application."

In any event, "fairness" is only one of the issues in this work area, taking its place alongside congestion, optimization, and others.

RB

-- 
Richard Bennett
--------------020804030700060806010900-- --===============0821091664== 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 --===============0821091664==-- From p2pi-bounces@ietf.org Thu Jun 12 04:31: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 944823A695C; Thu, 12 Jun 2008 04:31:57 -0700 (PDT) X-Original-To: p2pi@core3.amsl.com Delivered-To: p2pi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0195C3A695C for ; Thu, 12 Jun 2008 04:31:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.114 X-Spam-Level: X-Spam-Status: No, score=-10.114 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, HABEAS_ACCREDITED_COI=-8, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gbqhShkpxQAn for ; Thu, 12 Jun 2008 04:31:54 -0700 (PDT) Received: from dkny.pando.com (dkny.pando.com [67.99.55.163]) by core3.amsl.com (Postfix) with ESMTP id 22CE43A694D for ; Thu, 12 Jun 2008 04:31:54 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by dkny.pando.com (Postfix) with ESMTP id 5EA37E10BBF; Thu, 12 Jun 2008 07:32:17 -0400 (EDT) X-Virus-Scanned: amavisd-new at Received: from dkny.pando.com ([127.0.0.1]) by localhost (dkny.pando.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iScpBTozpwoH; Thu, 12 Jun 2008 07:31:50 -0400 (EDT) Received: from dkny.pando.com (dkny.pando.com [10.10.60.11]) by dkny.pando.com (Postfix) with ESMTP id EB5D5E10BBD; Thu, 12 Jun 2008 07:31:50 -0400 (EDT) Date: Thu, 12 Jun 2008 07:31:50 -0400 (EDT) From: Laird Popkin To: p2pi@ietf.org Message-ID: <1669260528.386321213270310916.JavaMail.root@dkny.pando.com> In-Reply-To: <1506959200.386261213269833072.JavaMail.root@dkny.pando.com> MIME-Version: 1.0 X-Originating-IP: [71.187.207.81] Subject: [p2pi] We don't need to treat users fairly, we need to maximize their happiness! X-BeenThere: p2pi@ietf.org X-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="===============0140513747==" Sender: p2pi-bounces@ietf.org Errors-To: p2pi-bounces@ietf.org --===============0140513747== Content-Type: multipart/alternative; boundary="----=_Part_15684_594244554.1213270310916" ------=_Part_15684_594244554.1213270310916 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable The term 'fairness' is (IMO) distracting us from the real goals, since that= word has emotional=C2=A0 implications =C2=A0(e.g. "unfairness"). And a dis= cussion about fairness assumes that our goal is equal resource allocation i= n the context of a 'zero sum game'. I think that there equal allocation of = resources isn't the best answer for users (e.g. a VOIP call and a PodCast a= ren't equal value bits), and there are certainly some cases where we're not= in a zero sum game (i.e. being smarter can get much more performance out o= f the same physical resources). And, at least as relates to the p2p issues = we're discussing, I don't know that fairness is even particularly important= .=20 I think what we're ultimately trying to achieve is to maximize user happine= ss when on a constrained network. This is different from "fairness" in that= there are some pretty obvious cases where being "fair" does not maximize u= ser satisfaction. That's not to say that fairness is bad - fairness is the = best the network can do if there's no visibility into the actual value of t= he data, or ability to influence application-level decisions. But fairness = isn't really our goal. Maximized user satisfaction is our goal.=20 User satisfaction is, of course, too broad to use an an engineering goal di= rectly. But there are many specific ideas that all address, in one way or a= nother, the issue of maximizing user satisfaction in a resource limited env= ironment:=20 - Peer selection based on network topology (e.g. P4P) allows p2p to consume= fewer resources and improving performance. Faster downloads make users hap= py.=20 - Knowing which streams are congested (e.g. Re-ECN) allows apps to select b= etween data sources to shift traffic away from congested areas. This improv= es performance for all concerned (users and their neighbors), making users = happy.=20 - Marking background transfer data as "scavenger class" could allow congest= ed links to focus resources on the most time critical data. This makes the = users with time sensitive transfers happy, and hopefully doesn't make the u= sers doing background transfers unhappy.=20 - ISPs exposing user quota status could allow applications to avoid trigger= ing surcharges, or hitting caps, allow users to make informed decisions, et= c. This makes the users happy.=20 etc.=20 -=C2=A0Laird=C2=A0Popkin,=C2=A0CTO,=C2=A0Pando=C2=A0Networks=20 =C2=A0=C2=A0mobile:=C2=A0646/465-0570=20 ----- Original Message -----=20 From: "Richard Bennett" =20 To: "Daniel Weitzner" =20 Cc: p2pi@ietf.org=20 Sent: Wednesday, June 11, 2008 9:51:37 PM (GMT-0500) America/New_York=20 Subject: Re: [p2pi] One more proposed definition of fairness...=20 Comments in-line:=20 Daniel Weitzner wrote:=20 Reflecting on the thread that followed Nick's original proposal =20 (quoted below).... I'd suggest that there are actually two kinds of fairness under =20 discussion: 1. fairness between ISPs and their customers: you get the bandwidth =20 and latency you pay for where those values are averaged over some =20 stated period This isn't the scope of "fairness" as it's generally understo= od in networking standards, at least not the ones that I've worked on. I wo= uld suggest that "disclosure" or something along that line is the more rele= vant term. When engineers specify "fairness" mechanism, they generally have= to do with your item number 2 below, an aspect of the multiple-access prob= lem.=20 2. fairness amongst network users: there are network mechanisms that =20 guard against some traffic (perhaps generated by the hypothesized 5%) =20 consistently degrading the traffic of others. That is, even though I =20 may be receiving the promised average bandwidth as measured over a =20 long period of time, the instantaneous performance is poor enough that =20 I feel it. From the comments I've read I'll go out on a limb and suggest that no =20 one really disagrees with the importance of achieving either notion. I'll go further on a said limb and suggest that the IETF concentrate =20 on mechanisms for enabling user-to-user fairness (#2) because it seems =20 like a tractable engineering problem. User-to-user fairness is =20 necessary but not sufficient to achieving user-to-ISP fairness (#1). =20 It is the case that even with user-to-user fairness, ISPs may have to =20 re-think their network provisioning in order to live up to their =20 contractual and/or marketing promises made to users. That, however, is =20 a business and regulatory problem. I do agree that it is important to =20 have verifiable service metrics, but am not sure that this is the =20 right place to sort those out. The suggestion for a TANA BOF in Dublin ment= ions the importance of metrics, to wit, relevant text highlighted:=20 (3) A mechanism that lets an application that can transfer data from or to several potential peers (i.e., servers, caches, end systems) select a subset of peers for efficient transmission in a way that is aligned with the dynamic interconnection structure of the network operators that provide connectivity to those peers. Application designers, network equipment vendors and network operators will need to collaborate on this work item to define what kinds of dynamic interconnection information is useful to applications , how to obtain it, and how to provide it to applications, resulting in a generic mechanism that is broadly applicable to many current and future applications. Given that applications need dynamic i= nterconnection information - metrics - it seems like a small step to aggreg= ate and export this for the purpose of service verification. But perhaps se= rvice verification is simply something that can be understood as an "applic= ation."=20 In any event, "fairness" is only one of the issues in this work area, takin= g its place alongside congestion, optimization, and others.=20 RB=20 --=20 Richard Bennett=20 _______________________________________________ p2pi mailing list p2pi@ietf= .org https://www.ietf.org/mailman/listinfo/p2pi ------=_Part_15684_594244554.1213270310916 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable The term 'fairness' is (IMO) distracting us fro= m the real goals, since that word has emotional=C2=A0implications=C2=A0(e.g= . "unfairness"). And a discussion about fairness assumes that our goal is e= qual resource allocation in the context of a 'zero sum game'. I think that = there equal allocation of resources isn't the best answer for users (e.g. a= VOIP call and a PodCast aren't equal value bits), and there are certainly = some cases where we're not in a zero sum game (i.e. being smarter can get m= uch more performance out of the same physical resources). And, at least as = relates to the p2p issues we're discussing, I don't know that fairness is e= ven particularly important.

I think what we're ultimatel= y trying to achieve is to maximize user happiness when on a constrained net= work. This is different from "fairness" in that there are some pretty obvio= us cases where being "fair" does not maximize user satisfaction. That's not= to say that fairness is bad - fairness is the best the network can do if t= here's no visibility into the actual value of the data, or ability to influ= ence application-level decisions. But fairness isn't really our goal. Maxim= ized user satisfaction is our goal.

User satisfact= ion is, of course, too broad to use an an engineering goal directly. But th= ere are many specific ideas that all address, in one way or another, the is= sue of maximizing user satisfaction in a resource limited environment:
- Peer selection based on network topology (e.g. P4P) allows p2p to c= onsume fewer resources and improving performance. Faster downloads make use= rs happy.
- Knowing which streams are congested (e.g. Re-ECN) all= ows apps to select between data sources to shift traffic away from congeste= d areas. This improves performance for all concerned (users and their neigh= bors), making users happy.
- Marking background transfer data as = "scavenger class" could allow congested links to focus resources on the mos= t time critical data. This makes the users with time sensitive transfers ha= ppy, and hopefully doesn't make the users doing background transfers unhapp= y.
- ISPs exposing user quota status could allow applications to = avoid triggering surcharges, or hitting caps, allow users to make informed = decisions, etc. This makes the users happy.

etc.

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

----- Original Message -----=
From: "Richard Bennett" <richard@bennett.com>
To: "Daniel Weitzne= r" <djweitzner@csail.mit.edu>
Cc: p2pi@ietf.org
Sent: Wednesday, J= une 11, 2008 9:51:37 PM (GMT-0500) America/New_York
Subject: Re: [p2pi] = One more proposed definition of fairness...

Comments in-line:

Daniel Weitzner wrote: 
Reflecting on the thread that followed Nick's original proposal =20
(quoted below)....

I'd suggest that there are actually two kinds of fairness under =20
discussion:

1. fairness between ISPs and their customers: you get the bandwidth =20
and latency you pay for where those values are averaged over some =20
stated period
This isn't the scope of "fairness" as it's generally understood in networking standards, at least not the ones that I've worked on. I would suggest that "disclosure" or something along that line is the more relevant term. When engineers specify "fairness" mechanism, they generally have to do with your item number 2 below, an aspect of the multiple-access problem.
2. fairness amongst network users: there are network mechanisms that=
 =20
guard against some traffic (perhaps generated by the hypothesized 5%) =20
consistently degrading the traffic of others. That is, even though I =20
may be receiving the promised average bandwidth as measured over a =20
long period of time, the instantaneous performance is poor enough that =20
I feel it.

 From the comments I've read I'll go out on a limb and suggest that no =20
one really disagrees with the importance of achieving either notion.

I'll go further on a said limb and suggest that the IETF concentrate =20
on mechanisms for enabling user-to-user fairness (#2) because it seems =20
like a tractable engineering problem. User-to-user fairness is =20
necessary but not sufficient to achieving user-to-ISP fairness (#1). =20
It is the case that even with user-to-user fairness, ISPs may have to =20
re-think their network provisioning in order to live up to their =20
contractual and/or marketing promises made to users. That, however, is =20
a business and regulatory problem. I do agree that it is important to =20
have verifiable service metrics, but am not sure that this is the =20
right place to sort those out.
The suggestion for a TANA BOF in Dublin mentions the importance of metrics, to wit, relevant text highlighted:

 
(3) A mechanism that le=
ts an application that can
    transfer data from or to several potential peers (i.e.,
    servers, caches, end systems) select a subset of peers
    for efficient transmission in a way that is aligned with
    the dynamic interconnection structure of the network
    operators that provide connectivity to those peers.
    Application designers, network equipment vendors and
    network operators will need to collaborate on this work
    item to define what kinds of dynamic interconnection
    information is useful to applications, how to obtain it,
    and how to provide it to applications, resulting in a
    generic mechanism that is broadly applicable to many
    current and future applications.
Given that applications need dynamic interconnection information - metrics - it seems like a small step to aggregate and export this for the purpose of service verification. But perhaps service verification is simply something that can be understood as an "application."

In any event, "fairness" is only one of the issues in this work area, taking its place alongside congestion, optimization, and others.

RB

--=20
Richard Bennett

_______________________________________________ p2pi mailing list p2pi@ietf.org https://www.ietf.org/mailman/listinfo/p2pi
------=_Part_15684_594244554.1213270310916-- --===============0140513747== 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 --===============0140513747==-- From p2pi-bounces@ietf.org Thu Jun 12 06:29:36 2008 Return-Path: X-Original-To: p2pi-archive@ietf.org Delivered-To: ietfarch-p2pi-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4146E3A6ADF; Thu, 12 Jun 2008 06:29:36 -0700 (PDT) X-Original-To: p2pi@core3.amsl.com Delivered-To: p2pi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9261C3A6ADF for ; Thu, 12 Jun 2008 06:29:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.365 X-Spam-Level: X-Spam-Status: No, score=-6.365 tagged_above=-999 required=5 tests=[AWL=0.234, 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 rBFTirYnC+b3 for ; Thu, 12 Jun 2008 06:29:30 -0700 (PDT) Received: from fruitcake.ICSI.Berkeley.EDU (fruitcake.ICSI.Berkeley.EDU [192.150.186.11]) by core3.amsl.com (Postfix) with ESMTP id BCF293A695E for ; Thu, 12 Jun 2008 06:29:30 -0700 (PDT) Received: from [IPv6:::1] (fruitcake [192.150.186.11]) by fruitcake.ICSI.Berkeley.EDU (8.12.11.20060614/8.12.11) with ESMTP id m5CDTgeH017847; Thu, 12 Jun 2008 06:29:42 -0700 (PDT) Message-Id: <0CADC67E-B42E-4880-A589-3384500437E0@icsi.berkeley.edu> From: Nicholas Weaver To: Laird Popkin In-Reply-To: <1669260528.386321213270310916.JavaMail.root@dkny.pando.com> Mime-Version: 1.0 (Apple Message framework v924) Date: Thu, 12 Jun 2008 06:29:42 -0700 References: <1669260528.386321213270310916.JavaMail.root@dkny.pando.com> X-Mailer: Apple Mail (2.924) Cc: p2pi@ietf.org, Nicholas Weaver Subject: Re: [p2pi] We don't need to treat users fairly, we need to maximize their happiness! X-BeenThere: p2pi@ietf.org X-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 Jun 12, 2008, at 4:31 AM, Laird Popkin wrote: > The term 'fairness' is (IMO) distracting us from the real goals, > since that word has emotional implications (e.g. "unfairness"). And > a discussion about fairness assumes that our goal is equal resource > allocation in the context of a 'zero sum game'. I think that there > equal allocation of resources isn't the best answer for users (e.g. > a VOIP call and a PodCast aren't equal value bits), and there are > certainly some cases where we're not in a zero sum game (i.e. being > smarter can get much more performance out of the same physical > resources). And, at least as relates to the p2p issues we're > discussing, I don't know that fairness is even particularly important. > > I think what we're ultimately trying to achieve is to maximize user > happiness when on a constrained network. This is different from > "fairness" in that there are some pretty obvious cases where being > "fair" does not maximize user satisfaction. That's not to say that > fairness is bad - fairness is the best the network can do if there's > no visibility into the actual value of the data, or ability to > influence application-level decisions. But fairness isn't really our > goal. Maximized user satisfaction is our goal. > The problem is, if you want to maximize the aggregate user satisfaction for a large number of users, rather than fairness, you are going to invite protocol-based discrimination between users. EG, if "Happyness" is defined as "My voip works, my interactive sessions are great, my web surfing is OK, etc" for a large group of users, dropping all bulk-data P2P on the floor is a great maximizing function in times of congestion! Look at it this way, except for a few individuals, Comcast killing seeds and leeches increases user "happyness" by a considerable amount (they stopped getting complains about deliberately disrupting VoIP services), and unless the seeding was deliberate, it even increases happyness for the local users' whos traffic it kills. Fairness, on the other hand, can be quantified, defined, and, critically, does not and should not require INTER-user protocol discrimination. _______________________________________________ p2pi mailing list p2pi@ietf.org https://www.ietf.org/mailman/listinfo/p2pi From p2pi-bounces@ietf.org Thu Jun 12 11:33:11 2008 Return-Path: X-Original-To: p2pi-archive@ietf.org Delivered-To: ietfarch-p2pi-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4B2A03A6A4D; Thu, 12 Jun 2008 11:33:11 -0700 (PDT) X-Original-To: p2pi@core3.amsl.com Delivered-To: p2pi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C24003A6A4D for ; Thu, 12 Jun 2008 11:33:09 -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 g-t3+uqJA8Xa for ; Thu, 12 Jun 2008 11:33:08 -0700 (PDT) Received: from maild.telecomitalia.it (maild.telecomitalia.it [156.54.233.30]) by core3.amsl.com (Postfix) with ESMTP id 161363A6A19 for ; Thu, 12 Jun 2008 11:33:07 -0700 (PDT) Received: from ptpxch008ba020.idc.cww.telecomitalia.it ([156.54.240.51]) by maild.telecomitalia.it with Microsoft SMTPSVC(6.0.3790.1830); Thu, 12 Jun 2008 20:33:35 +0200 Received: from GRFHUB703BA020.griffon.local ([10.188.101.113]) by ptpxch008ba020.idc.cww.telecomitalia.it with Microsoft SMTPSVC(6.0.3790.1830); Thu, 12 Jun 2008 20:33:34 +0200 Received: from [172.16.82.10] (163.162.180.246) by smtp.telecomitalia.it (10.188.101.116) with Microsoft SMTP Server (TLS) id 8.1.263.0; Thu, 12 Jun 2008 20:33:34 +0200 Message-ID: <48516BE2.2080901@telecomitalia.it> Date: Thu, 12 Jun 2008 20:33:06 +0200 From: Enrico Marocco User-Agent: Mozilla-Thunderbird 2.0.0.14 (X11/20080509) MIME-Version: 1.0 To: "p2pi@ietf.org" References: <22F6A875-B548-4C65-AB68-B88E526CCA33@nokia.com> <6E1603B0-7116-45F9-A510-DC5F9040298B@nokia.com> In-Reply-To: X-Enigmail-Version: 0.95.0 X-OriginalArrivalTime: 12 Jun 2008 18:33:34.0707 (UTC) FILETIME=[D2773430:01C8CCBA] Subject: [p2pi] Refining the ALTO problem statement [Was: Re: discussing P2PI-related standardization in Dublin] X-BeenThere: p2pi@ietf.org X-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="===============1343779916==" Sender: p2pi-bounces@ietf.org Errors-To: p2pi-bounces@ietf.org --===============1343779916== Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms000206040003090209000802" --------------ms000206040003090209000802 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Peterson, Jon wrote: > The proposal for the ALTO BoF (which roughly covers (3)) is now in the > BoF tracker. You can read about it at its home page: > > http://alto.tilab.com/ [...] > we hope that discussions surrounding the BoF could elucidate the proper > division of labor and approach to this problem. To follow up on Jon's thoughts and to reflect discussions that happened during the MIT workshop and on the mailing list, Vijay and I are going to update the problem statement draft the ALTO BoF proposal is based on (draft-marocco-alto-problem-statement-00). As a prelude to focus the ALTO BoF, it would be great to start coalescing community agreement on ensuring that the scope of the problem is well defined and understood. Essentially, the problem that ALTO will attempt to solve is this: applications (P2P and otherwise) that make intensive use of the network bandwidth or want to make decisions to optimize some function (see use cases) may be interested in choosing all or some of their peers based on recommendations provided by some network entity -- colloquially called an oracle -- that has more of a global view on the peers in the network, their topological distances, and their capabilities than the application itself does. In thinking about the problem, it may help to consider the following: + Use cases: current version of the draft identifies four use cases for ALTO solutions (file-sharing, VoIP, p2p streaming and DHTs) but others come to mind (e.g. cache/http-mirror selection, CDN). At the MIT workshop, Ted Hardie coined the term "unattended consequences" of peer-to-peer nodes where traffic runs constantly for as long as the resources to that node are popular. Video feeds to remote stations were identified as a category. + Third-party services: even if topology information is directly available to network operators, nothing should prevent third-parties to provide peer selection services alternatively to or in competition with ISPs. An incomplete list of proposed solutions for providing such services is online at http://alto.tilab.com/resources.html; + Type(s) of information that are likely provided by the oracle (note that a third-party oracle may not have access to some of this information): * Given a list of peer candidate IP addresses, sort them according to preferences (topological proximity, bandwidth constraints, etc.) and return to querying application; * Ability for an application to determine its network location and proximity to other nodes; * Support for cost and charging information for application so that applications can make appropriate trade-offs; * Capabilities and characteristics of peers (i.e., last hop bandwidth, etc.); * Network policies; * ... + Type(s) of information that is provided to the oracle for rendering an equitable decision: * List of peer candidate IP addresses; * Parameter to optimize (cost, delay, ...); * ... This is mainly what we have captured so far; however, feedback, suggestions and contributions are not only welcome, but at this time even required for the successful setting of a BOF. Besides, the draft currently identifies two elements for which standardization work would be required, namely a discovery mechanisms for locating oracles and a signaling protocol for querying them. Do people think the core solution for ALTO should include anything else? -- Ciao, Enrico --------------ms000206040003090209000802 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 hkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wODA2MTIxODMzMDZaMCMG CSqGSIb3DQEJBDEWBBRVjyvOtMxNoQtsTms8u/eM555VTTBfBgkqhkiG9w0BCQ8xUjBQMAsG CWCGSAFlAwQBAjAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAw BwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgYUGCSsGAQQBgjcQBDF4MHYwYjELMAkGA1UEBhMC WkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1Ro YXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAhAeTAANDUMJU97n0e1AWxu4MIGH BgsqhkiG9w0BCRACCzF4oHYwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25z dWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJ c3N1aW5nIENBAhAeTAANDUMJU97n0e1AWxu4MA0GCSqGSIb3DQEBAQUABIIBAKN4fg0IK1kg lrJaVY3oCpb9nuZPtPSq0HSgBlzMXK/sRfsxbdh+UXSBBQPUUXzixbSU/i6KTozS3/BmwFHk fHFXFuT9/v9Bz90BH/3Ln7P9Rc0EzuFn/sZYJrRmAiINy+OCScrSZiFdI3lw2G8j6Metk1QI JVEEZyVYGnh3f6P/GbfhwnfkFpKjqMSiTUthIRKct8wZsO+TH3VzQxVOlW2URuzL4vtIZG8u G109bbAhmX5VJXaG83DDp11WJzt4Dio65UIyJ8xbJUufN7puOF/N9yBC4+o5nk1JTxzOWW1H h1PiyGyYnxEaCVfpQJCuDfM/L+IoHJ98ntsjgSXRPBkAAAAAAAA= --------------ms000206040003090209000802-- --===============1343779916== 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 --===============1343779916==-- From p2pi-bounces@ietf.org Fri Jun 13 01:52: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 ADEBF3A6B3B; Fri, 13 Jun 2008 01:52: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 1EBC83A6B3B for ; Fri, 13 Jun 2008 01:52:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.549 X-Spam-Level: X-Spam-Status: No, score=-2.549 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eGhkXTK8lUEE for ; Fri, 13 Jun 2008 01:52:19 -0700 (PDT) Received: from av-tac-bru.cisco.com (odd-brew.cisco.com [144.254.15.119]) by core3.amsl.com (Postfix) with ESMTP id 4F1083A69BA for ; Fri, 13 Jun 2008 01:52:19 -0700 (PDT) X-TACSUNS: Virus Scanned Received: from strange-brew.cisco.com (localhost [127.0.0.1]) by av-tac-bru.cisco.com (8.11.7p3+Sun/8.11.7) with ESMTP id m5D8qna06804; Fri, 13 Jun 2008 10:52:49 +0200 (CEST) Received: from [144.254.189.71] (dhcp-rom2-144-254-189-71.cisco.com [144.254.189.71]) by strange-brew.cisco.com (8.11.7p3+Sun/8.11.7) with ESMTP id m5D8qnA10647; Fri, 13 Jun 2008 10:52:49 +0200 (CEST) User-Agent: Microsoft-Entourage/11.4.0.080122 Date: Fri, 13 Jun 2008 10:52:29 +0200 From: stefano previdi To: Enrico Marocco , "p2pi@ietf.org" Message-ID: Thread-Topic: [p2pi] Refining the ALTO problem statement [Was: Re: discussing P2PI-related standardization in Dublin] Thread-Index: AcjNMs9MDdaZfzkmEd2gXAAX8vOM8g== In-Reply-To: <48516BE2.2080901@telecomitalia.it> Mime-version: 1.0 Subject: Re: [p2pi] Refining the ALTO problem statement [Was: Re: discussing P2PI-related standardization in Dublin] X-BeenThere: p2pi@ietf.org X-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 Enrico, I mostly agree mostly with everything below. My suggestion (as a routing guy more than an apps guy) is also to scope what could be extended/enhanced in routing protocols in order to improve localization mechanisms (whatever they are). As an example, we have extended ISIS routing protocol in order to carry some application related information (at this stage is an empty container) and probably these kind of enhancements may have a use in localization/oracle services. s. > From: Enrico Marocco > > Peterson, Jon wrote: >> The proposal for the ALTO BoF (which roughly covers (3)) is now in the >> BoF tracker. You can read about it at its home page: >> >> http://alto.tilab.com/ > [...] >> we hope that discussions surrounding the BoF could elucidate the proper >> division of labor and approach to this problem. > > To follow up on Jon's thoughts and to reflect discussions that happened > during the MIT workshop and on the mailing list, Vijay and I are going > to update the problem statement draft the ALTO BoF proposal is based on > (draft-marocco-alto-problem-statement-00). > > As a prelude to focus the ALTO BoF, it would be great to start > coalescing community agreement on ensuring that the scope of the problem > is well defined and understood. > > Essentially, the problem that ALTO will attempt to solve is this: > applications (P2P and otherwise) that make intensive use of the network > bandwidth or want to make decisions to optimize some function (see use > cases) may be interested in choosing all or some of their peers based on > recommendations provided by some network entity -- colloquially called > an oracle -- that has more of a global view on the peers in the network, > their topological distances, and their capabilities than the application > itself does. > > In thinking about the problem, it may help to consider the following: > > + Use cases: current version of the draft identifies four use cases for > ALTO solutions (file-sharing, VoIP, p2p streaming and DHTs) but others > come to mind (e.g. cache/http-mirror selection, CDN). At the MIT > workshop, Ted Hardie coined the term "unattended consequences" of > peer-to-peer nodes where traffic runs constantly for as long as the > resources to that node are popular. Video feeds to remote stations > were identified as a category. > > + Third-party services: even if topology information is directly > available to network operators, nothing should prevent third-parties > to provide peer selection services alternatively to or in competition > with ISPs. An incomplete list of proposed solutions for providing > such services is online at http://alto.tilab.com/resources.html; > > + Type(s) of information that are likely provided by the oracle (note > that a third-party oracle may not have access to some of this > information): > * Given a list of peer candidate IP addresses, sort them according to > preferences (topological proximity, bandwidth constraints, etc.) and > return to querying application; > * Ability for an application to determine its network location and > proximity to other nodes; > * Support for cost and charging information for application so that > applications can make appropriate trade-offs; > * Capabilities and characteristics of peers (i.e., last hop bandwidth, > etc.); > * Network policies; > * ... > > + Type(s) of information that is provided to the oracle for rendering an > equitable decision: > * List of peer candidate IP addresses; > * Parameter to optimize (cost, delay, ...); > * ... > > This is mainly what we have captured so far; however, feedback, > suggestions and contributions are not only welcome, but at this time > even required for the successful setting of a BOF. > > Besides, the draft currently identifies two elements for which > standardization work would be required, namely a discovery mechanisms > for locating oracles and a signaling protocol for querying them. Do > people think the core solution for ALTO should include anything else? > > -- > Ciao, > Enrico > _______________________________________________ > p2pi mailing list > p2pi@ietf.org > https://www.ietf.org/mailman/listinfo/p2pi _______________________________________________ p2pi mailing list p2pi@ietf.org https://www.ietf.org/mailman/listinfo/p2pi From p2pi-bounces@ietf.org Fri Jun 13 05:14:39 2008 Return-Path: X-Original-To: p2pi-archive@ietf.org Delivered-To: ietfarch-p2pi-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DA72A3A697D; Fri, 13 Jun 2008 05:14:39 -0700 (PDT) X-Original-To: p2pi@core3.amsl.com Delivered-To: p2pi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 81DB83A697D for ; Fri, 13 Jun 2008 05:14:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.145 X-Spam-Level: X-Spam-Status: No, score=-10.145 tagged_above=-999 required=5 tests=[AWL=0.120, BAYES_00=-2.599, HABEAS_ACCREDITED_COI=-8, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IQg9t7WlO7rv for ; Fri, 13 Jun 2008 05:14:37 -0700 (PDT) Received: from dkny.pando.com (dkny.pando.com [67.99.55.163]) by core3.amsl.com (Postfix) with ESMTP id D58B13A68F2 for ; Fri, 13 Jun 2008 05:14:36 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by dkny.pando.com (Postfix) with ESMTP id 11323E10AE4; Fri, 13 Jun 2008 08:15:06 -0400 (EDT) X-Virus-Scanned: amavisd-new at Received: from dkny.pando.com ([127.0.0.1]) by localhost (dkny.pando.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dx+eLZKRFody; Fri, 13 Jun 2008 08:14:53 -0400 (EDT) Received: from dkny.pando.com (dkny.pando.com [10.10.60.11]) by dkny.pando.com (Postfix) with ESMTP id 7A5CEE10AE1; Fri, 13 Jun 2008 08:14:53 -0400 (EDT) Date: Fri, 13 Jun 2008 08:14:53 -0400 (EDT) From: Laird Popkin To: stefano previdi Message-ID: <565621476.393261213359293462.JavaMail.root@dkny.pando.com> In-Reply-To: <1098693626.393241213358903592.JavaMail.root@dkny.pando.com> MIME-Version: 1.0 X-Originating-IP: [71.187.207.81] Cc: p2pi@ietf.org Subject: Re: [p2pi] Refining the ALTO problem statement [Was: Re: discussing P2PI-related standardization in Dublin] X-BeenThere: p2pi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: P2P Infrastructure Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: p2pi-bounces@ietf.org Errors-To: p2pi-bounces@ietf.org This is a great discussion. One point I'll make related to the signaling protocol for querying the "oracle" is that while the "send in a list of peer IP addresses and receive a sorted list back" approach is appealing in its simplicity, it has some serious limitations that would need to be taken into account. It's important to keep in mind that optimizing peer selection for p2p transfers has the most impact for large swarms. That is, if there are only 20 people on the planet that can serve you data, (1) it doesn't take too long to connect to all of them so optimized peer selection doesn't save much peer connection time, and (2) the odds of any of them being in the same ISP is fairly low, so optimized peer selection doesn't affect data flow much. Optimizing peer selection is focused on swarms with very large numbers of peers. For example, we often see swarms with thousands or tens of thousands of peers. These are a small percentage of swarms, of course, but they are responsible for a disproportionately large volume of data. For example, when Yale surveyed "major tracker sites" they saw that a very small percentage of swarms had 100+ peers, but that those swarms were responsible for well over 50% of downloads. For perspective, at Pando, we see swarms with thousands to tens of thousands of peers fairly often. It is for these large sarms where the "list of IPs" approach runs into some pragmatic issues: - The "oracle" must be sent the current complete set of IPs in each swarm. This means that the queries would be very large (e.g. a list of 1,000 IP addresses). This is not very cacheable, because swarm composition is highly dynamic. And it has to be a complete list, or the value of the guidance degrades dramatically. (Conceivable this could be implemented as 'delta' updates, but that raises oracle state issues, makes the software and protocol much more complex, etc.). - The "oracle" would have to maintain state (or recompute on every query) for every swarm in every p2p network. - The volume of queries would be very large (perhaps on the order of 100K queries per second, across all p2p networks operating within an ISP). - The queries cannot be cached (because the first announce is the most important to optimize, and following queries need to include all new peers, and each query generates a response unique to the peer being provided the guidance). - The ISP would need to scale the "oracle" capacity to satisfy this volume. - It exposes the entire membership and data flow of the p2p network to the ISPs, which raises obvious legal and privacy issues. Imagine asking your lawyers whether they want to run Pirate's Bay's Trackers. - It makes every Tracker announce slow, expensive and unreliable instead of fast, cheap and reliable. This is why we shifted (in the P4P approach) away from the more obvious IP list approach to moving the guidance into the Tracker's memory. Admittedly that does require ISPs to expose some abstract guidance information (IP prefixes and percentages), but in return: - The communication from the "oracle" to the p2p network is a single asynchronous update (e.g. as little as one message every hour) instead of one message per peer announce per swarm. - The p2p network's Tracker can process peer requests in-memory, without having to make a blocking network call to an external "oracle". This is several orders of magnitude faster, more reliable, and far less resource intensive. - There's minimal information exposed between the ISP and the P2P network (which is, from a legal and privacy angle, better for both P2P and ISP). - Laird Popkin, CTO, Pando Networks mobile: 646/465-0570 ----- Original Message ----- From: "stefano previdi" To: "Enrico Marocco" , p2pi@ietf.org Sent: Friday, June 13, 2008 4:52:29 AM (GMT-0500) America/New_York Subject: Re: [p2pi] Refining the ALTO problem statement [Was: Re: discussing P2PI-related standardization in Dublin] Enrico, I mostly agree mostly with everything below. My suggestion (as a routing guy more than an apps guy) is also to scope what could be extended/enhanced in routing protocols in order to improve localization mechanisms (whatever they are). As an example, we have extended ISIS routing protocol in order to carry some application related information (at this stage is an empty container) and probably these kind of enhancements may have a use in localization/oracle services. s. > From: Enrico Marocco > > Peterson, Jon wrote: >> The proposal for the ALTO BoF (which roughly covers (3)) is now in the >> BoF tracker. You can read about it at its home page: >> >> http://alto.tilab.com/ > [...] >> we hope that discussions surrounding the BoF could elucidate the proper >> division of labor and approach to this problem. > > To follow up on Jon's thoughts and to reflect discussions that happened > during the MIT workshop and on the mailing list, Vijay and I are going > to update the problem statement draft the ALTO BoF proposal is based on > (draft-marocco-alto-problem-statement-00). > > As a prelude to focus the ALTO BoF, it would be great to start > coalescing community agreement on ensuring that the scope of the problem > is well defined and understood. > > Essentially, the problem that ALTO will attempt to solve is this: > applications (P2P and otherwise) that make intensive use of the network > bandwidth or want to make decisions to optimize some function (see use > cases) may be interested in choosing all or some of their peers based on > recommendations provided by some network entity -- colloquially called > an oracle -- that has more of a global view on the peers in the network, > their topological distances, and their capabilities than the application > itself does. > > In thinking about the problem, it may help to consider the following: > > + Use cases: current version of the draft identifies four use cases for > ALTO solutions (file-sharing, VoIP, p2p streaming and DHTs) but others > come to mind (e.g. cache/http-mirror selection, CDN). At the MIT > workshop, Ted Hardie coined the term "unattended consequences" of > peer-to-peer nodes where traffic runs constantly for as long as the > resources to that node are popular. Video feeds to remote stations > were identified as a category. > > + Third-party services: even if topology information is directly > available to network operators, nothing should prevent third-parties > to provide peer selection services alternatively to or in competition > with ISPs. An incomplete list of proposed solutions for providing > such services is online at http://alto.tilab.com/resources.html; > > + Type(s) of information that are likely provided by the oracle (note > that a third-party oracle may not have access to some of this > information): > * Given a list of peer candidate IP addresses, sort them according to > preferences (topological proximity, bandwidth constraints, etc.) and > return to querying application; > * Ability for an application to determine its network location and > proximity to other nodes; > * Support for cost and charging information for application so that > applications can make appropriate trade-offs; > * Capabilities and characteristics of peers (i.e., last hop bandwidth, > etc.); > * Network policies; > * ... > > + Type(s) of information that is provided to the oracle for rendering an > equitable decision: > * List of peer candidate IP addresses; > * Parameter to optimize (cost, delay, ...); > * ... > > This is mainly what we have captured so far; however, feedback, > suggestions and contributions are not only welcome, but at this time > even required for the successful setting of a BOF. > > Besides, the draft currently identifies two elements for which > standardization work would be required, namely a discovery mechanisms > for locating oracles and a signaling protocol for querying them. Do > people think the core solution for ALTO should include anything else? > > -- > Ciao, > Enrico > _______________________________________________ > p2pi mailing list > p2pi@ietf.org > https://www.ietf.org/mailman/listinfo/p2pi _______________________________________________ p2pi mailing list p2pi@ietf.org https://www.ietf.org/mailman/listinfo/p2pi _______________________________________________ p2pi mailing list p2pi@ietf.org https://www.ietf.org/mailman/listinfo/p2pi From p2pi-bounces@ietf.org Fri Jun 13 06:01:28 2008 Return-Path: X-Original-To: p2pi-archive@ietf.org Delivered-To: ietfarch-p2pi-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 24B6F3A6A16; Fri, 13 Jun 2008 06:01:28 -0700 (PDT) X-Original-To: p2pi@core3.amsl.com Delivered-To: p2pi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 70FFF3A6A16 for ; Fri, 13 Jun 2008 06:01:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.566 X-Spam-Level: X-Spam-Status: No, score=-2.566 tagged_above=-999 required=5 tests=[AWL=0.033, 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 UdvZjjKqlb4d for ; Fri, 13 Jun 2008 06:01:25 -0700 (PDT) Received: from av-tac-bru.cisco.com (odd-brew.cisco.com [144.254.15.119]) by core3.amsl.com (Postfix) with ESMTP id 5F86B3A6924 for ; Fri, 13 Jun 2008 06:01:25 -0700 (PDT) X-TACSUNS: Virus Scanned Received: from strange-brew.cisco.com (localhost [127.0.0.1]) by av-tac-bru.cisco.com (8.11.7p3+Sun/8.11.7) with ESMTP id m5DD1um02688; Fri, 13 Jun 2008 15:01:56 +0200 (CEST) Received: from [144.254.189.71] (dhcp-rom2-144-254-189-71.cisco.com [144.254.189.71]) by strange-brew.cisco.com (8.11.7p3+Sun/8.11.7) with ESMTP id m5DD1qA09863; Fri, 13 Jun 2008 15:01:52 +0200 (CEST) User-Agent: Microsoft-Entourage/11.4.0.080122 Date: Fri, 13 Jun 2008 15:01:32 +0200 From: stefano previdi To: Laird Popkin Message-ID: Thread-Topic: [p2pi] Refining the ALTO problem statement [Was: Re: discussing P2PI-related standardization in Dublin] Thread-Index: AcjNVZoF2Ksm3zlIEd2gXAAX8vOM8g== In-Reply-To: <565621476.393261213359293462.JavaMail.root@dkny.pando.com> Mime-version: 1.0 Cc: p2pi@ietf.org Subject: Re: [p2pi] Refining the ALTO problem statement [Was: Re: discussing P2PI-related standardization in Dublin] X-BeenThere: p2pi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: P2P Infrastructure Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: p2pi-bounces@ietf.org Errors-To: p2pi-bounces@ietf.org Hi Laird, I understand your concern and let me try to answer from a routing implementation perspective. My thoughts are as follows: - the options of having a list of IP addresses to rank may be faced to some limitations but I probably have different view. I believe one alternative is to have a ranking of _pair_ of IP addresses (I believe there's a proposal made already on this direction). It doesn't address scalability per se but it allows other form of oracle/proximity capability. - From a routing algorithm perspective (and its implementation). The localization of 10 Vs. 1000 addresses may not incur an exponential complexity. I fact, routing algorithms/implementations are faced to this problem for years now... ;-) In the last years a lot of work has been done in the routing layer in order to improve performance and to minimize the impact of routing computations. We are now leveraging all this work in order to address other type of routing paradigms (using the same input). - State can be kept even if it results from different computations. This allows an "oracle/proximity" provider to minimize the amount of computation and to be able do deliver results on-the-fly. - There are apps models that have some form of hierarchy (e.g: trackers) and some others not. Should we have different models in the oracle too, or should we try to be as much as possible transparent/agnostic ? I'd vote for the latter. - I can't speak much about the legal/psychological issue (disclosing p2p addresses to SP) as I come from bottom layers, but what I can say is that, technically, the SP doesn't need any form of oracle in order to understand who among his customers is a p2p addicted... ;-) - In one point we're in violent agreement: This is a great discussion. Thanks. s. > From: Laird Popkin > > This is a great discussion. > > One point I'll make related to the signaling protocol for querying the > "oracle" is that while the "send in a list of peer IP addresses and receive a > sorted list back" approach is appealing in its simplicity, it has some serious > limitations that would need to be taken into account. > > It's important to keep in mind that optimizing peer selection for p2p > transfers has the most impact for large swarms. That is, if there are only 20 > people on the planet that can serve you data, (1) it doesn't take too long to > connect to all of them so optimized peer selection doesn't save much peer > connection time, and (2) the odds of any of them being in the same ISP is > fairly low, so optimized peer selection doesn't affect data flow much. > Optimizing peer selection is focused on swarms with very large numbers of > peers. For example, we often see swarms with thousands or tens of thousands of > peers. These are a small percentage of swarms, of course, but they are > responsible for a disproportionately large volume of data. For example, when > Yale surveyed "major tracker sites" they saw that a very small percentage of > swarms had 100+ peers, but that those swarms were responsible for well over > 50% of downloads. For perspective, at Pando, we see swarms with thousands to > tens of thousands of peers fairly often. > > It is for these large sarms where the "list of IPs" approach runs into some > pragmatic issues: > - The "oracle" must be sent the current complete set of IPs in each swarm. > This means that the queries would be very large (e.g. a list of 1,000 IP > addresses). This is not very cacheable, because swarm composition is highly > dynamic. And it has to be a complete list, or the value of the guidance > degrades dramatically. (Conceivable this could be implemented as 'delta' > updates, but that raises oracle state issues, makes the software and protocol > much more complex, etc.). > > - The "oracle" would have to maintain state (or recompute on every query) for > every swarm in every p2p network. > - The volume of queries would be very large (perhaps on the order of 100K > queries per second, across all p2p networks operating within an ISP). > - The queries cannot be cached (because the first announce is the most > important to optimize, and following queries need to include all new peers, > and each query generates a response unique to the peer being provided the > guidance). > - The ISP would need to scale the "oracle" capacity to satisfy this volume. > - It exposes the entire membership and data flow of the p2p network to the > ISPs, which raises obvious legal and privacy issues. Imagine asking your > lawyers whether they want to run Pirate's Bay's Trackers. > - It makes every Tracker announce slow, expensive and unreliable instead of > fast, cheap and reliable. > > This is why we shifted (in the P4P approach) away from the more obvious IP > list approach to moving the guidance into the Tracker's memory. Admittedly > that does require ISPs to expose some abstract guidance information (IP > prefixes and percentages), but in return: > - The communication from the "oracle" to the p2p network is a single > asynchronous update (e.g. as little as one message every hour) instead of one > message per peer announce per swarm. > - The p2p network's Tracker can process peer requests in-memory, without > having to make a blocking network call to an external "oracle". This is > several orders of magnitude faster, more reliable, and far less resource > intensive. > - There's minimal information exposed between the ISP and the P2P network > (which is, from a legal and privacy angle, better for both P2P and ISP). > > - Laird Popkin, CTO, Pando Networks > mobile: 646/465-0570 > > ----- Original Message ----- > From: "stefano previdi" > To: "Enrico Marocco" , p2pi@ietf.org > Sent: Friday, June 13, 2008 4:52:29 AM (GMT-0500) America/New_York > Subject: Re: [p2pi] Refining the ALTO problem statement [Was: Re: discussing > P2PI-related standardization in Dublin] > > Enrico, > > I mostly agree mostly with everything below. My suggestion (as a routing guy > more than an apps guy) is also to scope what could be extended/enhanced in > routing protocols in order to improve localization mechanisms (whatever they > are). > > As an example, we have extended ISIS routing protocol in order to carry some > application related information (at this stage is an empty container) and > probably these kind of enhancements may have a use in localization/oracle > services. > > s. > > >> From: Enrico Marocco >> >> Peterson, Jon wrote: >>> The proposal for the ALTO BoF (which roughly covers (3)) is now in the >>> BoF tracker. You can read about it at its home page: >>> >>> http://alto.tilab.com/ >> [...] >>> we hope that discussions surrounding the BoF could elucidate the proper >>> division of labor and approach to this problem. >> >> To follow up on Jon's thoughts and to reflect discussions that happened >> during the MIT workshop and on the mailing list, Vijay and I are going >> to update the problem statement draft the ALTO BoF proposal is based on >> (draft-marocco-alto-problem-statement-00). >> >> As a prelude to focus the ALTO BoF, it would be great to start >> coalescing community agreement on ensuring that the scope of the problem >> is well defined and understood. >> >> Essentially, the problem that ALTO will attempt to solve is this: >> applications (P2P and otherwise) that make intensive use of the network >> bandwidth or want to make decisions to optimize some function (see use >> cases) may be interested in choosing all or some of their peers based on >> recommendations provided by some network entity -- colloquially called >> an oracle -- that has more of a global view on the peers in the network, >> their topological distances, and their capabilities than the application >> itself does. >> >> In thinking about the problem, it may help to consider the following: >> >> + Use cases: current version of the draft identifies four use cases for >> ALTO solutions (file-sharing, VoIP, p2p streaming and DHTs) but others >> come to mind (e.g. cache/http-mirror selection, CDN). At the MIT >> workshop, Ted Hardie coined the term "unattended consequences" of >> peer-to-peer nodes where traffic runs constantly for as long as the >> resources to that node are popular. Video feeds to remote stations >> were identified as a category. >> >> + Third-party services: even if topology information is directly >> available to network operators, nothing should prevent third-parties >> to provide peer selection services alternatively to or in competition >> with ISPs. An incomplete list of proposed solutions for providing >> such services is online at http://alto.tilab.com/resources.html; >> >> + Type(s) of information that are likely provided by the oracle (note >> that a third-party oracle may not have access to some of this >> information): >> * Given a list of peer candidate IP addresses, sort them according to >> preferences (topological proximity, bandwidth constraints, etc.) and >> return to querying application; >> * Ability for an application to determine its network location and >> proximity to other nodes; >> * Support for cost and charging information for application so that >> applications can make appropriate trade-offs; >> * Capabilities and characteristics of peers (i.e., last hop bandwidth, >> etc.); >> * Network policies; >> * ... >> >> + Type(s) of information that is provided to the oracle for rendering an >> equitable decision: >> * List of peer candidate IP addresses; >> * Parameter to optimize (cost, delay, ...); >> * ... >> >> This is mainly what we have captured so far; however, feedback, >> suggestions and contributions are not only welcome, but at this time >> even required for the successful setting of a BOF. >> >> Besides, the draft currently identifies two elements for which >> standardization work would be required, namely a discovery mechanisms >> for locating oracles and a signaling protocol for querying them. Do >> people think the core solution for ALTO should include anything else? >> >> -- >> Ciao, >> Enrico >> _______________________________________________ >> p2pi mailing list >> p2pi@ietf.org >> https://www.ietf.org/mailman/listinfo/p2pi > > > _______________________________________________ > p2pi mailing list > p2pi@ietf.org > https://www.ietf.org/mailman/listinfo/p2pi _______________________________________________ p2pi mailing list p2pi@ietf.org https://www.ietf.org/mailman/listinfo/p2pi From p2pi-bounces@ietf.org Fri Jun 13 07:37:37 2008 Return-Path: X-Original-To: p2pi-archive@ietf.org Delivered-To: ietfarch-p2pi-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B0E8A3A6920; Fri, 13 Jun 2008 07:37:37 -0700 (PDT) X-Original-To: p2pi@core3.amsl.com Delivered-To: p2pi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E6A013A695D for ; Fri, 13 Jun 2008 07:37:36 -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 rBK+PejUj-qV for ; Fri, 13 Jun 2008 07:37:33 -0700 (PDT) Received: from maild.telecomitalia.it (maild.telecomitalia.it [156.54.233.30]) by core3.amsl.com (Postfix) with ESMTP id 667483A6817 for ; Fri, 13 Jun 2008 07:37:30 -0700 (PDT) Received: from ptpxch010ba020.idc.cww.telecomitalia.it ([156.54.240.53]) by maild.telecomitalia.it with Microsoft SMTPSVC(6.0.3790.1830); Fri, 13 Jun 2008 16:38:01 +0200 Received: from GRFHUB703BA020.griffon.local ([10.188.101.113]) by ptpxch010ba020.idc.cww.telecomitalia.it with Microsoft SMTPSVC(6.0.3790.1830); Fri, 13 Jun 2008 16:38:01 +0200 Received: from [10.229.8.35] (10.229.8.35) by smtp.telecomitalia.it (10.188.101.116) with Microsoft SMTP Server (TLS) id 8.1.263.0; Fri, 13 Jun 2008 16:38:00 +0200 Message-ID: <4852862D.9030202@telecomitalia.it> Date: Fri, 13 Jun 2008 16:37:33 +0200 From: Enrico Marocco User-Agent: Mozilla-Thunderbird 2.0.0.14 (X11/20080509) MIME-Version: 1.0 To: Laird Popkin References: <565621476.393261213359293462.JavaMail.root@dkny.pando.com> In-Reply-To: <565621476.393261213359293462.JavaMail.root@dkny.pando.com> X-Enigmail-Version: 0.95.0 X-OriginalArrivalTime: 13 Jun 2008 14:38:01.0078 (UTC) FILETIME=[14945160:01C8CD63] Cc: "p2pi@ietf.org" Subject: Re: [p2pi] Refining the ALTO problem statement [Was: Re: discussing P2PI-related standardization in Dublin] X-BeenThere: p2pi@ietf.org X-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="===============0604211757==" Sender: p2pi-bounces@ietf.org Errors-To: p2pi-bounces@ietf.org --===============0604211757== Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms060709040603080709000802" --------------ms060709040603080709000802 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Laird Popkin wrote: > One point I'll make related to the signaling protocol for querying the > "oracle" is that while the "send in a list of peer IP addresses and > receive a sorted list back" approach is appealing in its simplicity, it > has some serious limitations that would need to be taken into account. Actually I used the term "oracle" in a general way, to refer to servers providing information useful for peer selection. The "sorting" oracle is only one proposed approach for addressing the problem of p2p traffic optimization. Other competing or complementary approaches, e.g. based on network coordinates or topology/policy information, have both advantages and disadvantages in respect to it. The main goal of ALTO is to compare the different approaches on a technical basis with a view towards standardization -- Ciao, Enrico --------------ms060709040603080709000802 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 hkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wODA2MTMxNDM3MzNaMCMG CSqGSIb3DQEJBDEWBBRW9sWZrKr4zdpOLvEAAYfR57MyrzBfBgkqhkiG9w0BCQ8xUjBQMAsG CWCGSAFlAwQBAjAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAw BwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgYUGCSsGAQQBgjcQBDF4MHYwYjELMAkGA1UEBhMC WkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1Ro YXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAhAeTAANDUMJU97n0e1AWxu4MIGH BgsqhkiG9w0BCRACCzF4oHYwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25z dWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJ c3N1aW5nIENBAhAeTAANDUMJU97n0e1AWxu4MA0GCSqGSIb3DQEBAQUABIIBAK7JrdQWyzdG FWXf47TkZBtO6XC6I2tH4DlkrVfIEqs3YLcObfA3uLzopanI8MovtZHxbkVRRZZag4MrZF51 E7vfgOmOY6ZRRyWGfcKwo9/v5pvqKKVMv9vrW0B+zyTnaFaiYaXWFXRN/uMmhD+gDTXLRbLH FbcpNQdPeNIESeAKctvbJoNFKcsZJP0aRH9tZh4Jm8uPEVCrvapSOFZh+jgQTCoklNjWJHWh WOQS/NSUbByjv3oG8XeYjSo9jKQeVtb+Su41BAOrQ2mpO0A4BwWvvZC05vFfcLRHLCrI4Tyg jx6HrL3c791bxF5/bd4vhJF2UbGp0XUj1Wloh0dXODsAAAAAAAA= --------------ms060709040603080709000802-- --===============0604211757== 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 --===============0604211757==-- From p2pi-bounces@ietf.org Fri Jun 13 08:00: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 83F2F3A6A16; Fri, 13 Jun 2008 08:00: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 98DFC3A69F7 for ; Fri, 13 Jun 2008 08:00:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.226 X-Spam-Level: X-Spam-Status: No, score=-2.226 tagged_above=-999 required=5 tests=[AWL=0.373, 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 aoM7ITIIYPKb for ; Fri, 13 Jun 2008 08:00:26 -0700 (PDT) Received: from mailhost.jlc.net (mailhost.jlc.net [199.201.159.9]) by core3.amsl.com (Postfix) with ESMTP id 012753A69BE for ; Fri, 13 Jun 2008 08:00:26 -0700 (PDT) Received: by mailhost.jlc.net (Postfix, from userid 104) id 2955D33C50; Fri, 13 Jun 2008 11:00:58 -0400 (EDT) Date: Fri, 13 Jun 2008 11:00:58 -0400 From: John Leslie To: Enrico Marocco Message-ID: <20080613150058.GA3759@verdi> References: <22F6A875-B548-4C65-AB68-B88E526CCA33@nokia.com> <6E1603B0-7116-45F9-A510-DC5F9040298B@nokia.com> <48516BE2.2080901@telecomitalia.it> Mime-Version: 1.0 Content-Disposition: inline In-Reply-To: <48516BE2.2080901@telecomitalia.it> User-Agent: Mutt/1.4.1i Cc: "p2pi@ietf.org" Subject: Re: [p2pi] Refining the ALTO problem statement [Was: Re: discussing P2PI-related standardization in Dublin] X-BeenThere: p2pi@ietf.org X-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 Enrico Marocco wrote: > > To follow up on Jon's thoughts and to reflect discussions that happened > during the MIT workshop and on the mailing list, Vijay and I are going > to update the problem statement draft the ALTO BoF proposal is based on > (draft-marocco-alto-problem-statement-00). >... > + Type(s) of information that is provided to the oracle for rendering an > equitable decision: > * List of peer candidate IP addresses; > * Parameter to optimize (cost, delay, ...); I think we could reasonably expand this, so as to provide more for the oracle to work from. There are two well-known cases: 1. We want a well-known range of bandwidth for a possibly well-known length of time. 2. We want to transfer a well-known number of bytes within a fairly well-known period of time. In the first case, "No path will work" is a useful answer, and we should have a way of saying so. In the second case, an estimate of how long the transfer _would_ take is very useful information, and we should have a way of passing that back. (Users will typically abort transfers that aren't making enough progress; and giving them information to abort sooner would be a good thing.) (I really like calling this an "oracle" service, because it must necessarily make predictions about the future. However poor those predictions may prove, the oracle _can_ have a better (statistical) basis for them than either end-point.) Latency is also possibly an issue in the first case: it's probably a good idea to report expected latency for each path. (Optimizing for it may or may not be useful.) -- John Leslie _______________________________________________ p2pi mailing list p2pi@ietf.org https://www.ietf.org/mailman/listinfo/p2pi From p2pi-bounces@ietf.org Fri Jun 13 08:12: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 5973B3A6825; Fri, 13 Jun 2008 08:12: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 45CBC3A6825 for ; Fri, 13 Jun 2008 08:12:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.185 X-Spam-Level: X-Spam-Status: No, score=-6.185 tagged_above=-999 required=5 tests=[AWL=0.064, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sy-9lJELzxOU for ; Fri, 13 Jun 2008 08:12:17 -0700 (PDT) Received: from mx2.nic.fr (mx2.nic.fr [192.134.4.11]) by core3.amsl.com (Postfix) with ESMTP id 542A13A67A4 for ; Fri, 13 Jun 2008 08:12:17 -0700 (PDT) Received: from mx2.nic.fr (localhost [127.0.0.1]) by mx2.nic.fr (Postfix) with SMTP id AD9D21C011B; Fri, 13 Jun 2008 17:12:46 +0200 (CEST) Received: from relay2.nic.fr (relay2.nic.fr [192.134.4.163]) by mx2.nic.fr (Postfix) with ESMTP id A7E201C0110; Fri, 13 Jun 2008 17:12:46 +0200 (CEST) Received: from bortzmeyer.nic.fr (batilda.nic.fr [192.134.4.69]) by relay2.nic.fr (Postfix) with ESMTP id A414B58EBC5; Fri, 13 Jun 2008 17:12:46 +0200 (CEST) Date: Fri, 13 Jun 2008 17:12:46 +0200 From: Stephane Bortzmeyer To: Enrico Marocco Message-ID: <20080613151246.GA20314@nic.fr> References: <565621476.393261213359293462.JavaMail.root@dkny.pando.com> <4852862D.9030202@telecomitalia.it> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <4852862D.9030202@telecomitalia.it> X-Operating-System: Debian GNU/Linux lenny/sid X-Kernel: Linux 2.6.24-1-686 i686 Organization: NIC France X-URL: http://www.nic.fr/ User-Agent: Mutt/1.5.18 (2008-05-17) Cc: "p2pi@ietf.org" Subject: Re: [p2pi] Refining the ALTO problem statement [Was: Re: discussing P2PI-related standardization in Dublin] X-BeenThere: p2pi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: P2P Infrastructure Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: p2pi-bounces@ietf.org Errors-To: p2pi-bounces@ietf.org On Fri, Jun 13, 2008 at 04:37:33PM +0200, Enrico Marocco wrote a message of 112 lines which said: > The "sorting" oracle is only one proposed approach for addressing > the problem of p2p traffic optimization. Other competing or > complementary approaches, e.g. based on network coordinates or > topology/policy information, have both advantages and disadvantages > in respect to it. > > The main goal of ALTO is to compare the different approaches on a > technical basis with a view towards standardization As a beginner in this list, I request more explanations. Reading draft-marocco-alto-problem-statement-00, I had the impression that ALTO only follows one approach, "optimizing traffic generated by P2P applications Using Information Provided By Isps And Network Operators" (section 1). I'm a big fan of ICS myself but are they really on-topic? Or is it too early to say? _______________________________________________ p2pi mailing list p2pi@ietf.org https://www.ietf.org/mailman/listinfo/p2pi From p2pi-bounces@ietf.org Fri Jun 13 08:22:43 2008 Return-Path: X-Original-To: p2pi-archive@ietf.org Delivered-To: ietfarch-p2pi-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8AEF53A6840; Fri, 13 Jun 2008 08:22: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 A34DA3A6840 for ; Fri, 13 Jun 2008 08:22:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.413 X-Spam-Level: X-Spam-Status: No, score=-2.413 tagged_above=-999 required=5 tests=[AWL=0.186, 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 4mmVcni5aXzn for ; Fri, 13 Jun 2008 08:22:41 -0700 (PDT) Received: from ihemail4.lucent.com (ihemail4.lucent.com [135.245.0.39]) by core3.amsl.com (Postfix) with ESMTP id 6EAC03A681E for ; Fri, 13 Jun 2008 08:22:41 -0700 (PDT) Received: from umail.lucent.com (h135-3-40-61.lucent.com [135.3.40.61]) by ihemail4.lucent.com (8.13.8/IER-o) with ESMTP id m5DFN1o0028080 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 13 Jun 2008 10:23:01 -0500 (CDT) Received: from [135.185.244.90] (il0015vkg1.ih.lucent.com [135.185.244.90]) by umail.lucent.com (8.13.8/TPES) with ESMTP id m5DFMxO1026920; Fri, 13 Jun 2008 10:22:59 -0500 (CDT) Message-ID: <485290D5.1010909@alcatel-lucent.com> Date: Fri, 13 Jun 2008 10:23:01 -0500 From: "Vijay K. Gurbani" Organization: Bell Labs Security Technology Research Group User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Stephane Bortzmeyer References: <565621476.393261213359293462.JavaMail.root@dkny.pando.com> <4852862D.9030202@telecomitalia.it> <20080613151246.GA20314@nic.fr> In-Reply-To: <20080613151246.GA20314@nic.fr> X-Scanned-By: MIMEDefang 2.57 on 135.245.2.39 Cc: "p2pi@ietf.org" Subject: Re: [p2pi] Refining the ALTO problem statement [Was: Re: discussing P2PI-related standardization in Dublin] X-BeenThere: p2pi@ietf.org X-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 Stephane Bortzmeyer wrote: > As a beginner in this list, I request more explanations. Stephane: I am not sure how recently you joined the list, but there were a fair amount of papers and viewpoints presented at the MIT workshop in May 2008. In case you do not have access to those, here here is a link to the final set of papers and summary slides that were discussed at the workshop: http://idisk.mac.com/cullenfluffyjennings-Public?view=web > Reading draft-marocco-alto-problem-statement-00, I had the impression > that ALTO only follows one approach, "optimizing traffic generated by > P2P applications Using Information Provided By Isps And Network > Operators" (section 1). A good summary of the approaches, including ALTO, that came out of the workshop is also discussed in Lars' follow-up email, which can be accessed at: http://www.ietf.org/mail-archive/web/p2pi/current/msg00068.html > I'm a big fan of ICS myself but are they really on-topic? Or is it > too early to say? I am sorry but could you please expand on "ICS"? Thanks, - vijay -- Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent 2701 Lucent Lane, Rm. 9F-546, Lisle, Illinois 60532 (USA) Email: vkg@{alcatel-lucent.com,bell-labs.com,acm.org} WWW: http://www.alcatel-lucent.com/bell-labs _______________________________________________ p2pi mailing list p2pi@ietf.org https://www.ietf.org/mailman/listinfo/p2pi From p2pi-bounces@ietf.org Fri Jun 13 08:25: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 E30AB3A69AA; Fri, 13 Jun 2008 08:25: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 657D53A69AA for ; Fri, 13 Jun 2008 08:25:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.165 X-Spam-Level: X-Spam-Status: No, score=-10.165 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, HABEAS_ACCREDITED_COI=-8, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G2V+uz-d3ufU for ; Fri, 13 Jun 2008 08:25:12 -0700 (PDT) Received: from dkny.pando.com (dkny.pando.com [67.99.55.163]) by core3.amsl.com (Postfix) with ESMTP id 555683A6969 for ; Fri, 13 Jun 2008 08:25:12 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by dkny.pando.com (Postfix) with ESMTP id 2C40AE10C17; Fri, 13 Jun 2008 11:25:44 -0400 (EDT) X-Virus-Scanned: amavisd-new at Received: from dkny.pando.com ([127.0.0.1]) by localhost (dkny.pando.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hccSX-lKuIie; Fri, 13 Jun 2008 11:25:40 -0400 (EDT) Received: from [10.10.20.61] (unknown [10.10.20.61]) by dkny.pando.com (Postfix) with ESMTP id 2DB86E10AD0; Fri, 13 Jun 2008 11:25:40 -0400 (EDT) Message-Id: From: Laird Popkin To: Enrico Marocco In-Reply-To: <4852862D.9030202@telecomitalia.it> Mime-Version: 1.0 (Apple Message framework v924) Date: Fri, 13 Jun 2008 11:25:39 -0400 References: <565621476.393261213359293462.JavaMail.root@dkny.pando.com> <4852862D.9030202@telecomitalia.it> X-Mailer: Apple Mail (2.924) Cc: "p2pi@ietf.org" Subject: Re: [p2pi] Refining the ALTO problem statement [Was: Re: discussing P2PI-related standardization in Dublin] X-BeenThere: p2pi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: P2P Infrastructure Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: p2pi-bounces@ietf.org Errors-To: p2pi-bounces@ietf.org Yes, I certainly didn't mean to imply that there was any problem with the "oracle" approach or the ALTO proposal - I am a strong supporter of this model. My only concern is that we don't limit our discussion to the one signaling protocol that was used as an example. My apologies if my (perhaps overly detailed) email came across as more negative than I intended. :-) - LP On Jun 13, 2008, at 10:37 AM, Enrico Marocco wrote: > Laird Popkin wrote: >> One point I'll make related to the signaling protocol for querying >> the >> "oracle" is that while the "send in a list of peer IP addresses and >> receive a sorted list back" approach is appealing in its >> simplicity, it >> has some serious limitations that would need to be taken into >> account. > > Actually I used the term "oracle" in a general way, to refer to > servers > providing information useful for peer selection. The "sorting" oracle > is only one proposed approach for addressing the problem of p2p > traffic > optimization. Other competing or complementary approaches, e.g. based > on network coordinates or topology/policy information, have both > advantages and disadvantages in respect to it. > > The main goal of ALTO is to compare the different approaches on a > technical basis with a view towards standardization > > -- > Ciao, > Enrico _______________________________________________ p2pi mailing list p2pi@ietf.org https://www.ietf.org/mailman/listinfo/p2pi From p2pi-bounces@ietf.org Fri Jun 13 08:27:05 2008 Return-Path: X-Original-To: p2pi-archive@ietf.org Delivered-To: ietfarch-p2pi-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3DD153A681E; Fri, 13 Jun 2008 08:27:05 -0700 (PDT) X-Original-To: p2pi@core3.amsl.com Delivered-To: p2pi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8DE123A6825 for ; Fri, 13 Jun 2008 08:27:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.188 X-Spam-Level: X-Spam-Status: No, score=-6.188 tagged_above=-999 required=5 tests=[AWL=0.061, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZaGCWxLxsDG3 for ; Fri, 13 Jun 2008 08:27:03 -0700 (PDT) Received: from mx2.nic.fr (mx2.nic.fr [192.134.4.11]) by core3.amsl.com (Postfix) with ESMTP id A91A13A67A4 for ; Fri, 13 Jun 2008 08:27:03 -0700 (PDT) Received: from mx2.nic.fr (localhost [127.0.0.1]) by mx2.nic.fr (Postfix) with SMTP id 7169E1C0158; Fri, 13 Jun 2008 17:27:35 +0200 (CEST) Received: from relay1.nic.fr (relay1.nic.fr [192.134.4.162]) by mx2.nic.fr (Postfix) with ESMTP id 6CC8B1C011E; Fri, 13 Jun 2008 17:27:35 +0200 (CEST) Received: from bortzmeyer.nic.fr (batilda.nic.fr [192.134.4.69]) by relay1.nic.fr (Postfix) with ESMTP id 60F02A1DA87; Fri, 13 Jun 2008 17:27:35 +0200 (CEST) Date: Fri, 13 Jun 2008 17:27:35 +0200 From: Stephane Bortzmeyer To: "Vijay K. Gurbani" Message-ID: <20080613152734.GA25170@nic.fr> References: <565621476.393261213359293462.JavaMail.root@dkny.pando.com> <4852862D.9030202@telecomitalia.it> <20080613151246.GA20314@nic.fr> <485290D5.1010909@alcatel-lucent.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <485290D5.1010909@alcatel-lucent.com> X-Operating-System: Debian GNU/Linux lenny/sid X-Kernel: Linux 2.6.24-1-686 i686 Organization: NIC France X-URL: http://www.nic.fr/ User-Agent: Mutt/1.5.18 (2008-05-17) Cc: p2pi@ietf.org Subject: Re: [p2pi] Refining the ALTO problem statement [Was: Re: discussing P2PI-related standardization in Dublin] X-BeenThere: p2pi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: P2P Infrastructure Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: p2pi-bounces@ietf.org Errors-To: p2pi-bounces@ietf.org On Fri, Jun 13, 2008 at 10:23:01AM -0500, Vijay K. Gurbani wrote a message of 34 lines which said: > I am sorry but could you please expand on "ICS"? Sorry, Internet Coordinates Systems as in or similar works. _______________________________________________ p2pi mailing list p2pi@ietf.org https://www.ietf.org/mailman/listinfo/p2pi From p2pi-bounces@ietf.org Fri Jun 13 08:28:20 2008 Return-Path: X-Original-To: p2pi-archive@ietf.org Delivered-To: ietfarch-p2pi-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C770D3A693A; Fri, 13 Jun 2008 08:28:20 -0700 (PDT) X-Original-To: p2pi@core3.amsl.com Delivered-To: p2pi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A7AFA3A693A for ; Fri, 13 Jun 2008 08:28:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.19 X-Spam-Level: X-Spam-Status: No, score=-6.19 tagged_above=-999 required=5 tests=[AWL=0.059, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 310RD9IX05Ds for ; Fri, 13 Jun 2008 08:28:18 -0700 (PDT) Received: from mx2.nic.fr (mx2.nic.fr [192.134.4.11]) by core3.amsl.com (Postfix) with ESMTP id C3AE83A6825 for ; Fri, 13 Jun 2008 08:28:18 -0700 (PDT) Received: from mx2.nic.fr (localhost [127.0.0.1]) by mx2.nic.fr (Postfix) with SMTP id 8CEB81C00D9; Fri, 13 Jun 2008 17:28:50 +0200 (CEST) Received: from relay2.nic.fr (relay2.nic.fr [192.134.4.163]) by mx2.nic.fr (Postfix) with ESMTP id 87C901C009D; Fri, 13 Jun 2008 17:28:50 +0200 (CEST) Received: from bortzmeyer.nic.fr (batilda.nic.fr [192.134.4.69]) by relay2.nic.fr (Postfix) with ESMTP id 7A5F458EBC5; Fri, 13 Jun 2008 17:28:50 +0200 (CEST) Date: Fri, 13 Jun 2008 17:28:50 +0200 From: Stephane Bortzmeyer To: "Vijay K. Gurbani" Message-ID: <20080613152850.GA25521@nic.fr> References: <565621476.393261213359293462.JavaMail.root@dkny.pando.com> <4852862D.9030202@telecomitalia.it> <20080613151246.GA20314@nic.fr> <485290D5.1010909@alcatel-lucent.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <485290D5.1010909@alcatel-lucent.com> X-Operating-System: Debian GNU/Linux lenny/sid X-Kernel: Linux 2.6.24-1-686 i686 Organization: NIC France X-URL: http://www.nic.fr/ User-Agent: Mutt/1.5.18 (2008-05-17) Cc: p2pi@ietf.org Subject: Re: [p2pi] Refining the ALTO problem statement [Was: Re: discussing P2PI-related standardization in Dublin] X-BeenThere: p2pi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: P2P Infrastructure Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: p2pi-bounces@ietf.org Errors-To: p2pi-bounces@ietf.org On Fri, Jun 13, 2008 at 10:23:01AM -0500, Vijay K. Gurbani wrote a message of 34 lines which said: > http://idisk.mac.com/cullenfluffyjennings-Public?view=web Required Browsers You may be using an unsupported browser. We recommend: * Mac OS X Safari 1.3 or later * Firefox 1.0.4 or later * Windows Firefox 1.0.4 or later * Internet Explorer 6 or later [I use Firefox 2.0.0.14] _______________________________________________ p2pi mailing list p2pi@ietf.org https://www.ietf.org/mailman/listinfo/p2pi From p2pi-bounces@ietf.org Fri Jun 13 08:33: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 AE42D3A68F2; Fri, 13 Jun 2008 08:33: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 40EEF3A68F2 for ; Fri, 13 Jun 2008 08:33:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.45 X-Spam-Level: X-Spam-Status: No, score=-2.45 tagged_above=-999 required=5 tests=[AWL=0.149, 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 jmTNkONvXtSw for ; Fri, 13 Jun 2008 08:33:21 -0700 (PDT) Received: from ihemail3.lucent.com (ihemail3.lucent.com [135.245.0.37]) by core3.amsl.com (Postfix) with ESMTP id 5092A3A67A4 for ; Fri, 13 Jun 2008 08:33:21 -0700 (PDT) Received: from umail.lucent.com (h135-3-40-61.lucent.com [135.3.40.61]) by ihemail3.lucent.com (8.13.8/IER-o) with ESMTP id m5DFXqM4028747 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 13 Jun 2008 10:33:52 -0500 (CDT) Received: from [135.185.244.90] (il0015vkg1.ih.lucent.com [135.185.244.90]) by umail.lucent.com (8.13.8/TPES) with ESMTP id m5DFXnOI007200; Fri, 13 Jun 2008 10:33:49 -0500 (CDT) Message-ID: <48529360.3080301@alcatel-lucent.com> Date: Fri, 13 Jun 2008 10:33:52 -0500 From: "Vijay K. Gurbani" Organization: Bell Labs Security Technology Research Group User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Stephane Bortzmeyer References: <565621476.393261213359293462.JavaMail.root@dkny.pando.com> <4852862D.9030202@telecomitalia.it> <20080613151246.GA20314@nic.fr> <485290D5.1010909@alcatel-lucent.com> <20080613152734.GA25170@nic.fr> In-Reply-To: <20080613152734.GA25170@nic.fr> X-Scanned-By: MIMEDefang 2.57 on 135.245.2.37 Cc: p2pi@ietf.org Subject: Re: [p2pi] Refining the ALTO problem statement [Was: Re: discussing P2PI-related standardization in Dublin] X-BeenThere: p2pi@ietf.org X-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 Stephane Bortzmeyer wrote: > On Fri, Jun 13, 2008 at 10:23:01AM -0500, > Vijay K. Gurbani wrote > a message of 34 lines which said: > >> I am sorry but could you please expand on "ICS"? > > Sorry, Internet Coordinates Systems as in > or similar > works. Ah, OK. I figured as much, but before suggesting anything, I wanted to be sure. A discussion of ICS as epitomized by Vivaldi, PIC, et al. is discussed in our paper (in the URL I sent you for the iDisk volume, see the paper "29 alto.pdf"). Thanks, - vijay -- Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent 2701 Lucent Lane, Rm. 9F-546, Lisle, Illinois 60532 (USA) Email: vkg@{alcatel-lucent.com,bell-labs.com,acm.org} WWW: http://www.alcatel-lucent.com/bell-labs _______________________________________________ p2pi mailing list p2pi@ietf.org https://www.ietf.org/mailman/listinfo/p2pi From p2pi-bounces@ietf.org Fri Jun 13 08:35: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 EDF913A69AA; Fri, 13 Jun 2008 08:35: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 670693A69AA for ; Fri, 13 Jun 2008 08:35:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.475 X-Spam-Level: X-Spam-Status: No, score=-2.475 tagged_above=-999 required=5 tests=[AWL=0.124, 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 qPGskA3dxymY for ; Fri, 13 Jun 2008 08:35:02 -0700 (PDT) Received: from ihemail3.lucent.com (ihemail3.lucent.com [135.245.0.37]) by core3.amsl.com (Postfix) with ESMTP id 7CB763A68F2 for ; Fri, 13 Jun 2008 08:35:02 -0700 (PDT) Received: from umail.lucent.com (h135-3-40-61.lucent.com [135.3.40.61]) by ihemail3.lucent.com (8.13.8/IER-o) with ESMTP id m5DFZXd5000155 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 13 Jun 2008 10:35:34 -0500 (CDT) Received: from [135.185.244.90] (il0015vkg1.ih.lucent.com [135.185.244.90]) by umail.lucent.com (8.13.8/TPES) with ESMTP id m5DFZVZb009055; Fri, 13 Jun 2008 10:35:31 -0500 (CDT) Message-ID: <485293C5.5080704@alcatel-lucent.com> Date: Fri, 13 Jun 2008 10:35:33 -0500 From: "Vijay K. Gurbani" Organization: Bell Labs Security Technology Research Group User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Stephane Bortzmeyer References: <565621476.393261213359293462.JavaMail.root@dkny.pando.com> <4852862D.9030202@telecomitalia.it> <20080613151246.GA20314@nic.fr> <485290D5.1010909@alcatel-lucent.com> <20080613152850.GA25521@nic.fr> In-Reply-To: <20080613152850.GA25521@nic.fr> X-Scanned-By: MIMEDefang 2.57 on 135.245.2.37 Cc: p2pi@ietf.org Subject: Re: [p2pi] Refining the ALTO problem statement [Was: Re: discussing P2PI-related standardization in Dublin] X-BeenThere: p2pi@ietf.org X-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 Stephane Bortzmeyer wrote: > On Fri, Jun 13, 2008 at 10:23:01AM -0500, > Vijay K. Gurbani wrote > a message of 34 lines which said: > >> http://idisk.mac.com/cullenfluffyjennings-Public?view=web > > Required Browsers > > You may be using an unsupported browser. > We recommend: > > * Mac OS X Safari 1.3 or later > * Firefox 1.0.4 or later > > * Windows Firefox 1.0.4 or later > * Internet Explorer 6 or later > > [I use Firefox 2.0.0.14] Hmmm ... funny -- I use Firefox v2.0.0.14 as well, and it works for me. In any case, I will send you a tar file in private email that includes the workshop proceedings and presentations. Ciao. - vijay -- Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent 2701 Lucent Lane, Rm. 9F-546, Lisle, Illinois 60532 (USA) Email: vkg@{alcatel-lucent.com,bell-labs.com,acm.org} WWW: http://www.alcatel-lucent.com/bell-labs _______________________________________________ p2pi mailing list p2pi@ietf.org https://www.ietf.org/mailman/listinfo/p2pi From p2pi-bounces@ietf.org Fri Jun 13 08:38: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 518463A68F2; Fri, 13 Jun 2008 08:38: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 EB20E3A68F2 for ; Fri, 13 Jun 2008 08:38:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.265 X-Spam-Level: X-Spam-Status: No, score=-10.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HABEAS_ACCREDITED_COI=-8, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fq08kgxonrVO for ; Fri, 13 Jun 2008 08:38:07 -0700 (PDT) Received: from dkny.pando.com (dkny.pando.com [67.99.55.163]) by core3.amsl.com (Postfix) with ESMTP id 5B8A53A6804 for ; Fri, 13 Jun 2008 08:38:07 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by dkny.pando.com (Postfix) with ESMTP id 66AF7E10C32; Fri, 13 Jun 2008 11:38:39 -0400 (EDT) X-Virus-Scanned: amavisd-new at Received: from dkny.pando.com ([127.0.0.1]) by localhost (dkny.pando.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eEjJ8nbqBk1Q; Fri, 13 Jun 2008 11:38:13 -0400 (EDT) Received: from [10.178.101.188] (unknown [32.137.88.217]) by dkny.pando.com (Postfix) with ESMTP id F38D2E10C31; Fri, 13 Jun 2008 11:38:11 -0400 (EDT) From: Laird Popkin To: Stephane Bortzmeyer In-Reply-To: <20080613152734.GA25170@nic.fr> X-Mailer: iPhone Mail (4A102) References: <565621476.393261213359293462.JavaMail.root@dkny.pando.com> <4852862D.9030202@telecomitalia.it> <20080613151246.GA20314@nic.fr> <485290D5.1010909@alcatel-lucent.com> <20080613152734.GA25170@nic.fr> Message-Id: Mime-Version: 1.0 (iPhone Mail 4A102) Date: Fri, 13 Jun 2008 11:37:17 -0400 Cc: "p2pi@ietf.org" Subject: Re: [p2pi] Refining the ALTO problem statement [Was: Re: discussing P2PI-related standardization in Dublin] X-BeenThere: p2pi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: P2P Infrastructure Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: p2pi-bounces@ietf.org Errors-To: p2pi-bounces@ietf.org Very interesting reading, thanks! - Laird Popkin, CTO, Pando Networks http://www.pandonetworks.com 520 Broadway, 10th Floor, NY, NY, 10012 laird@pando.com, 646/465-0570. Sent from my iPhone. Apologies in advance for typo's. On Jun 13, 2008, at 11:27 AM, Stephane Bortzmeyer wrote: > On Fri, Jun 13, 2008 at 10:23:01AM -0500, > Vijay K. Gurbani wrote > a message of 34 lines which said: > >> I am sorry but could you please expand on "ICS"? > > Sorry, Internet Coordinates Systems as in > or similar > works. > _______________________________________________ > 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 Jun 13 08:53:46 2008 Return-Path: X-Original-To: p2pi-archive@ietf.org Delivered-To: ietfarch-p2pi-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B00033A69EC; Fri, 13 Jun 2008 08:53:46 -0700 (PDT) X-Original-To: p2pi@core3.amsl.com Delivered-To: p2pi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 804733A69EC for ; Fri, 13 Jun 2008 08:53:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.493 X-Spam-Level: X-Spam-Status: No, score=-2.493 tagged_above=-999 required=5 tests=[AWL=0.106, 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 2BLFlGKVI-1J for ; Fri, 13 Jun 2008 08:53:44 -0700 (PDT) Received: from ihemail3.lucent.com (ihemail3.lucent.com [135.245.0.37]) by core3.amsl.com (Postfix) with ESMTP id 719F23A698D for ; Fri, 13 Jun 2008 08:53:43 -0700 (PDT) Received: from umail.lucent.com (h135-3-40-61.lucent.com [135.3.40.61]) by ihemail3.lucent.com (8.13.8/IER-o) with ESMTP id m5DFsAWW014688 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 13 Jun 2008 10:54:10 -0500 (CDT) Received: from [135.185.244.90] (il0015vkg1.ih.lucent.com [135.185.244.90]) by umail.lucent.com (8.13.8/TPES) with ESMTP id m5DFs77Z026730; Fri, 13 Jun 2008 10:54:07 -0500 (CDT) Message-ID: <48529822.2030101@alcatel-lucent.com> Date: Fri, 13 Jun 2008 10:54:10 -0500 From: "Vijay K. Gurbani" Organization: Bell Labs Security Technology Research Group User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: stefano previdi References: In-Reply-To: X-Scanned-By: MIMEDefang 2.57 on 135.245.2.37 Cc: "p2pi@ietf.org" Subject: Re: [p2pi] Refining the ALTO problem statement [Was: Re: discussing P2PI-related standardization in Dublin] X-BeenThere: p2pi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: P2P Infrastructure Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: p2pi-bounces@ietf.org Errors-To: p2pi-bounces@ietf.org stefano previdi wrote: > Enrico, > > I mostly agree mostly with everything below. Stefano: Thank you. > My suggestion (as a routing guy more than an apps guy) is also to > scope what could be extended/enhanced in routing protocols in order > to improve localization mechanisms (whatever they are). I think the issue of scoping is something that we definitely have to work on. I also suspect that ALTO solutions deployed by network operators will probably make use of information carried in routing protocols and, if it turns out that extensions to such protocols may be beneficial, they should be specified in coordination with ALTO, but probably in the Routing area. At the current time, the viewpoints of the ADs appear to be that ALTO will be either in RAI or Apps. > As an example, we have extended ISIS routing protocol in order to > carry some application related information (at this stage is an empty > container) and probably these kind of enhancements may have a use in > localization/oracle services. It would be great if you could describe this in a draft. One of the points we made in our workshop paper was the need for layer cooperation. Your existing work would go a long way to provide some illumination of feasibility in that area. Ciao. - vijay -- Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent 2701 Lucent Lane, Rm. 9F-546, Lisle, Illinois 60532 (USA) Email: vkg@{alcatel-lucent.com,bell-labs.com,acm.org} WWW: http://www.alcatel-lucent.com/bell-labs _______________________________________________ p2pi mailing list p2pi@ietf.org https://www.ietf.org/mailman/listinfo/p2pi From p2pi-bounces@ietf.org Fri Jun 13 09:10:08 2008 Return-Path: X-Original-To: p2pi-archive@ietf.org Delivered-To: ietfarch-p2pi-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 21BB43A6826; Fri, 13 Jun 2008 09:10:08 -0700 (PDT) X-Original-To: p2pi@core3.amsl.com Delivered-To: p2pi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D32413A6826 for ; Fri, 13 Jun 2008 09:10:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.474 X-Spam-Level: X-Spam-Status: No, score=-6.474 tagged_above=-999 required=5 tests=[AWL=0.125, 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 OZCcrxG9JNwJ for ; Fri, 13 Jun 2008 09:10:03 -0700 (PDT) Received: from mgw-mx03.nokia.com (smtp.nokia.com [192.100.122.230]) by core3.amsl.com (Postfix) with ESMTP id 800183A67F5 for ; Fri, 13 Jun 2008 09:10:02 -0700 (PDT) Received: from esebh107.NOE.Nokia.com (esebh107.ntc.nokia.com [172.21.143.143]) by mgw-mx03.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id m5DGA8qk029117; Fri, 13 Jun 2008 19:10:32 +0300 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 13 Jun 2008 19:10:28 +0300 Received: from net-92.nrpn.net ([10.241.184.208]) by esebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Fri, 13 Jun 2008 19:10:27 +0300 Message-Id: From: Lars Eggert To: ext Enrico Marocco In-Reply-To: <48516BE2.2080901@telecomitalia.it> Mime-Version: 1.0 (Apple Message framework v924) Date: Fri, 13 Jun 2008 19:10:23 +0300 References: <22F6A875-B548-4C65-AB68-B88E526CCA33@nokia.com> <6E1603B0-7116-45F9-A510-DC5F9040298B@nokia.com> <48516BE2.2080901@telecomitalia.it> X-Mailer: Apple Mail (2.924) X-OriginalArrivalTime: 13 Jun 2008 16:10:28.0463 (UTC) FILETIME=[FF1417F0:01C8CD6F] X-Nokia-AV: Clean Cc: "p2pi@ietf.org" Subject: Re: [p2pi] Refining the ALTO problem statement [Was: Re: discussing P2PI-related standardization in Dublin] X-BeenThere: p2pi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: P2P Infrastructure Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: p2pi-bounces@ietf.org Errors-To: p2pi-bounces@ietf.org Hi, On 2008-6-12, at 21:33, ext Enrico Marocco wrote: > + Type(s) of information that are likely provided by the oracle (note > that a third-party oracle may not have access to some of this > information): I have a few comments about the kinds of information that the oracle might provide to the app. The high level bit is that I believe that although it will be possible to provide information that changes on relatively large timescales (such as information about topological proximity), it will be both very difficult and potentially problematic to share performance- related information that changes on short timescales in the same fashion. > * Given a list of peer candidate IP addresses, sort them according to > preferences (topological proximity, bandwidth constraints, etc.) > and > return to querying application; > * Ability for an application to determine its network location and > proximity to other nodes; These are all OK, except for the bit about "bandwidth constraints". The available bandwidth along a path changes very rapidly, on timescales roughly O(RTT), because bandwidth consumption is regulated by the congestion control loops of the flows sharing a path. This pretty much guarantees that any such information an oracle could maintain will be stale by the time that an oracle can provide it to an application. So this information is unlikely to be useful to an app; and I can even construct cases where using this stale information leads to traffic oscillations, which is problematic. Modulo this concern about stuff that varies on short timescales, a simple mechanism that lets an app query an oracle about the things in the two bullets above would be useful. I'm MUCH less convinced of the usefulness of the shopping list of things in the following bullets. For a lot of the things below, it's unclear to me why an application would want them and where an oracle would get them from. I don't think they should be part of any standardization effort at this time. (Looking at them from a research perspective is fine.) > * Support for cost and charging information for application so that > applications can make appropriate trade-offs; Can you be a bit more explicit about whose costs this is about? Who is paying whom, on what timescales and based on what resources? > * Capabilities and characteristics of peers (i.e., last hop > bandwidth, > etc.); The bandwidth example is IMO again problematic (and it's not a peer characteristic, it's a path characteristic.) Also, why would an oracle know anything about the capabilities or characteristics of the peers? Are the peers supposed to register with the oracle? That goes far beyond what I thought this BOF was about. > * Network policies; Such as? > + Type(s) of information that is provided to the oracle for > rendering an > equitable decision: > * List of peer candidate IP addresses; > * Parameter to optimize (cost, delay, ...); Why is it useful to query the oracle for delay? An app can get a relatively accurate and more importantly timely RTT sample by sending a few packets to a peer. That practice causes no issues for operators, since the traffic volume is so low. Lars _______________________________________________ p2pi mailing list p2pi@ietf.org https://www.ietf.org/mailman/listinfo/p2pi From p2pi-bounces@ietf.org Fri Jun 13 09:12:37 2008 Return-Path: X-Original-To: p2pi-archive@ietf.org Delivered-To: ietfarch-p2pi-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 75FD13A6924; Fri, 13 Jun 2008 09:12:37 -0700 (PDT) X-Original-To: p2pi@core3.amsl.com Delivered-To: p2pi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C84A03A6924 for ; Fri, 13 Jun 2008 09:12:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.477 X-Spam-Level: X-Spam-Status: No, score=-6.477 tagged_above=-999 required=5 tests=[AWL=0.122, 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 9vhaD3TnQk1z for ; Fri, 13 Jun 2008 09:12:35 -0700 (PDT) Received: from mgw-mx06.nokia.com (smtp.nokia.com [192.100.122.233]) by core3.amsl.com (Postfix) with ESMTP id AB6303A6826 for ; Fri, 13 Jun 2008 09:12:34 -0700 (PDT) Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-mx06.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id m5DGD1RN010958; Fri, 13 Jun 2008 19:13:03 +0300 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 13 Jun 2008 19:13:03 +0300 Received: from net-92.nrpn.net ([10.241.184.208]) by esebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Fri, 13 Jun 2008 19:13:02 +0300 Message-Id: <4E2CFB2D-A2E2-432E-82B2-0B32500EFA9B@nokia.com> From: Lars Eggert To: ext John Leslie In-Reply-To: <20080613150058.GA3759@verdi> Mime-Version: 1.0 (Apple Message framework v924) Date: Fri, 13 Jun 2008 19:12:57 +0300 References: <22F6A875-B548-4C65-AB68-B88E526CCA33@nokia.com> <6E1603B0-7116-45F9-A510-DC5F9040298B@nokia.com> <48516BE2.2080901@telecomitalia.it> <20080613150058.GA3759@verdi> X-Mailer: Apple Mail (2.924) X-OriginalArrivalTime: 13 Jun 2008 16:13:02.0789 (UTC) FILETIME=[5B105F50:01C8CD70] X-Nokia-AV: Clean Cc: "p2pi@ietf.org" Subject: Re: [p2pi] Refining the ALTO problem statement [Was: Re: discussing P2PI-related standardization in Dublin] X-BeenThere: p2pi@ietf.org X-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 2008-6-13, at 18:00, ext John Leslie wrote: > In the second case, an estimate of how long the transfer _would_ > take is very useful information, and we should have a way of passing > that back. (Users will typically abort transfers that aren't making > enough progress; and giving them information to abort sooner would be > a good thing.) There is NO way for the oracle to figure this out - this depends entirely on the current load along the path, which is changing on short timescales under the control of the end-to-end congestion control loop. Lars _______________________________________________ p2pi mailing list p2pi@ietf.org https://www.ietf.org/mailman/listinfo/p2pi From p2pi-bounces@ietf.org Fri Jun 13 09:23: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 DBC623A67F4; Fri, 13 Jun 2008 09:23: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 6023A3A67F4 for ; Fri, 13 Jun 2008 09:23:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.506 X-Spam-Level: X-Spam-Status: No, score=-2.506 tagged_above=-999 required=5 tests=[AWL=0.093, 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 vZIpojX6c7nj for ; Fri, 13 Jun 2008 09:23:46 -0700 (PDT) Received: from ihemail4.lucent.com (ihemail4.lucent.com [135.245.0.39]) by core3.amsl.com (Postfix) with ESMTP id 251163A67B3 for ; Fri, 13 Jun 2008 09:23:45 -0700 (PDT) Received: from umail.lucent.com (h135-3-40-61.lucent.com [135.3.40.61]) by ihemail4.lucent.com (8.13.8/IER-o) with ESMTP id m5DGOBH3021750 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 13 Jun 2008 11:24:13 -0500 (CDT) Received: from [135.185.244.90] (il0015vkg1.ih.lucent.com [135.185.244.90]) by umail.lucent.com (8.13.8/TPES) with ESMTP id m5DGO86O025534; Fri, 13 Jun 2008 11:24:08 -0500 (CDT) Message-ID: <48529F2B.1080400@alcatel-lucent.com> Date: Fri, 13 Jun 2008 11:24:11 -0500 From: "Vijay K. Gurbani" Organization: Bell Labs Security Technology Research Group User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Laird Popkin References: <565621476.393261213359293462.JavaMail.root@dkny.pando.com> <4852862D.9030202@telecomitalia.it> In-Reply-To: X-Scanned-By: MIMEDefang 2.57 on 135.245.2.39 Cc: "p2pi@ietf.org" Subject: Re: [p2pi] Refining the ALTO problem statement [Was: Re: discussing P2PI-related standardization in Dublin] X-BeenThere: p2pi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: P2P Infrastructure Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: p2pi-bounces@ietf.org Errors-To: p2pi-bounces@ietf.org Laird Popkin wrote: > Yes, I certainly didn't mean to imply that there was any problem with > the "oracle" approach or the ALTO proposal - I am a strong supporter > of this model. My only concern is that we don't limit our discussion > to the one signaling protocol that was used as an example. My > apologies if my (perhaps overly detailed) email came across as more > negative than I intended. :-) Laird: No worries, it did not. In fact, you bring a lot of relevant discussion points. One thing that caught my eye was: > It's important to keep in mind that optimizing peer selection for p2p > transfers has the most impact for large swarms. That is, if there > are only 20 people on the planet that can serve you data, (1) it > doesn't take too long to connect to all of them so optimized peer > selection doesn't save much peer connection time, and (2) the odds of > any of them being in the same ISP is fairly low, so optimized peer > selection doesn't affect data flow much. This is very true for large swarms. However, aside from a BitTorrent- like P2P configuration, consider the whole notion of service discovery in VoIP P2P networks in the context of finding the nearest -- say -- video mail peer to deposit my video mail, and if that resource is replicated in the DHT, to find the nearest peer that can serve it. Here, the number of people interested in this video mail resource is low, probably the sender and the receiver only, and maybe a finite number of others who the first two may want to share the resource with. But the network could benefit from keeping the traffic localized. > This is why we shifted (in the P4P approach) away from the more > obvious IP list approach to moving the guidance into the Tracker's > memory [...] Thanks; I did read your paper in preparation for the workshop, but either I did not read it closely enough, or some epiphany occurred on reading your email to make things more clear on the tracker approach. Ciao. - vijay -- Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent 2701 Lucent Lane, Rm. 9F-546, Lisle, Illinois 60532 (USA) Email: vkg@{alcatel-lucent.com,bell-labs.com,acm.org} WWW: http://www.alcatel-lucent.com/bell-labs _______________________________________________ p2pi mailing list p2pi@ietf.org https://www.ietf.org/mailman/listinfo/p2pi From p2pi-bounces@ietf.org Fri Jun 13 09:42:02 2008 Return-Path: X-Original-To: p2pi-archive@ietf.org Delivered-To: ietfarch-p2pi-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 790EF3A6890; Fri, 13 Jun 2008 09:42:02 -0700 (PDT) X-Original-To: p2pi@core3.amsl.com Delivered-To: p2pi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2C2E03A6890; Fri, 13 Jun 2008 09:42:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.482 X-Spam-Level: X-Spam-Status: No, score=-6.482 tagged_above=-999 required=5 tests=[AWL=0.117, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fzmX75u5peEZ; Fri, 13 Jun 2008 09:42:00 -0700 (PDT) Received: from mgw-mx03.nokia.com (smtp.nokia.com [192.100.122.230]) by core3.amsl.com (Postfix) with ESMTP id D95BB3A67B3; Fri, 13 Jun 2008 09:41:59 -0700 (PDT) Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-mx03.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id m5DGfuvg028341; Fri, 13 Jun 2008 19:42:26 +0300 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 13 Jun 2008 19:39:42 +0300 Received: from net-92.nrpn.net ([10.241.184.208]) by esebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Fri, 13 Jun 2008 19:39:41 +0300 Message-Id: <14F37DBB-BCF0-43C9-90D0-A8B7D4A9FD36@nokia.com> From: Lars Eggert To: TSV Area In-Reply-To: <6E1603B0-7116-45F9-A510-DC5F9040298B@nokia.com> Mime-Version: 1.0 (Apple Message framework v924) Date: Fri, 13 Jun 2008 19:39:35 +0300 References: <22F6A875-B548-4C65-AB68-B88E526CCA33@nokia.com> <6E1603B0-7116-45F9-A510-DC5F9040298B@nokia.com> X-Mailer: Apple Mail (2.924) X-OriginalArrivalTime: 13 Jun 2008 16:39:42.0425 (UTC) FILETIME=[14857490:01C8CD74] X-Nokia-AV: Clean Cc: p2pi@ietf.org, "iab@iab.org IAB" , p2prg@irtf.org, "IESG \(\(E-mail\)\)" , P2PSIP Mailing List Subject: Re: [p2pi] discussing P2PI-related standardization in Dublin X-BeenThere: p2pi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: P2P Infrastructure Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: p2pi-bounces@ietf.org Errors-To: p2pi-bounces@ietf.org Hi, On 2008-6-6, at 17:40, ext Lars Eggert wrote: > related to the work item below, I've just heard that some folks had > already been discussing the submission of a more targeted BOF > proposal. Depending on the details of that proposal (which I haven't > seen yet), work item (3) might be subsumed by it. this BOF proposal has now materialized in form of ALTO (http://alto.tilab.com/ ), a BOF proposal targeted at APP and RAI. It's hence somewhat likely that we may have a TANA BOF in TSV that focuses on the work items (1) and (2) from my original email, and a second ALTO BOF hosted by APP and RAI. (Note: this email is *not* an IESG approval of either the TANA or ALTO BOF - those will come from the responsible ADs if and when they come.) ALTO is currently scoped a bit more broadly than the TANA work item (3) was, and some of the broader proposals in the ALTO space could lead to significant transport issues. A fraction of the ALTO proponents argues to exchange information related to end-to-end performance (bandwidth, RTT, congestion, transfer time estimates, etc.) through the oracle, for example. I'd like to ask transport folks to participate in the discussion on ALTO on the p2pi@ietf.org mailing list, in order to discuss the transport implications of the various ALTO ideas. > On 2008-6-6, at 15:58, Lars Eggert wrote: >> (3) A mechanism that lets an application that can >> transfer data from or to several potential peers (i.e., >> servers, caches, end systems) select a subset of peers >> for efficient transmission in a way that is aligned with >> the dynamic interconnection structure of the network >> operators that provide connectivity to those peers. >> Application designers, network equipment vendors and >> network operators will need to collaborate on this work >> item to define what kinds of dynamic interconnection >> information is useful to applications, how to obtain it, >> and how to provide it to applications, resulting in a >> generic mechanism that is broadly applicable to many >> current and future applications. This work item has >> obvious interactions with the IETF's Application, Routing >> and Operations areas. In order to make this effort more >> manageable, it may make sense to work out the >> requirements for such a solution first, before discussing >> individual proposals or breaking up the work into pieces >> for specification in different areas or WGs. Lars _______________________________________________ p2pi mailing list p2pi@ietf.org https://www.ietf.org/mailman/listinfo/p2pi From p2pi-bounces@ietf.org Fri Jun 13 11:42: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 20D5E3A6804; Fri, 13 Jun 2008 11:42: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 61CF33A6804 for ; Fri, 13 Jun 2008 11:42:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.879 X-Spam-Level: X-Spam-Status: No, score=0.879 tagged_above=-999 required=5 tests=[AWL=-1.598, BAYES_00=-2.599, DATE_IN_FUTURE_24_48=3.196, 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 bSnmb1Y86nD6 for ; Fri, 13 Jun 2008 11:42:04 -0700 (PDT) Received: from maild.telecomitalia.it (maild.telecomitalia.it [156.54.233.30]) by core3.amsl.com (Postfix) with ESMTP id 04F663A63D3 for ; Fri, 13 Jun 2008 11:42:03 -0700 (PDT) Received: from ptpxch009ba020.idc.cww.telecomitalia.it ([156.54.240.52]) by maild.telecomitalia.it with Microsoft SMTPSVC(6.0.3790.1830); Fri, 13 Jun 2008 20:42:33 +0200 Received: from GRFHUB703BA020.griffon.local ([10.188.101.113]) by ptpxch009ba020.idc.cww.telecomitalia.it with Microsoft SMTPSVC(6.0.3790.1830); Fri, 13 Jun 2008 20:42:33 +0200 Received: from [172.16.82.18] (163.162.180.246) by smtp.telecomitalia.it (10.188.101.116) with Microsoft SMTP Server (TLS) id 8.1.263.0; Fri, 13 Jun 2008 20:42:32 +0200 Message-ID: <4854111C.8020107@telecomitalia.it> Date: Sat, 14 Jun 2008 20:42:36 +0200 From: Enrico Marocco User-Agent: Mozilla-Thunderbird 2.0.0.14 (X11/20080509) MIME-Version: 1.0 To: Stephane Bortzmeyer References: <565621476.393261213359293462.JavaMail.root@dkny.pando.com> <4852862D.9030202@telecomitalia.it> <20080613151246.GA20314@nic.fr> <485290D5.1010909@alcatel-lucent.com> <20080613152850.GA25521@nic.fr> In-Reply-To: <20080613152850.GA25521@nic.fr> X-OriginalArrivalTime: 13 Jun 2008 18:42:33.0565 (UTC) FILETIME=[3E1028D0:01C8CD85] Cc: "p2pi@ietf.org" Subject: Re: [p2pi] Refining the ALTO problem statement [Was: Re: discussing P2PI-related standardization in Dublin] X-BeenThere: p2pi@ietf.org X-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="===============1770582969==" Sender: p2pi-bounces@ietf.org Errors-To: p2pi-bounces@ietf.org --===============1770582969== Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms050200070600090101040505" --------------ms050200070600090101040505 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Stephane Bortzmeyer wrote: > Vijay K. Gurbani wrote > a message of 34 lines which said: > >> http://idisk.mac.com/cullenfluffyjennings-Public?view=web > > Required Browsers It is actually quite an unfriendly website for non-mac users, but fortunately it has also a webdav interface. Just point a dav client (e.g. cadaver) to the URL above and it should work. > [I use Firefox 2.0.0.14] Maybe your browser is just presenting itself with another name (Iceweasel?). -- Ciao, Enrico --------------ms050200070600090101040505 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 hkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wODA2MTQxODQyMzZaMCMG CSqGSIb3DQEJBDEWBBTXow7JkWIPl0v0Pgij9GOwM5Z7iDBfBgkqhkiG9w0BCQ8xUjBQMAsG CWCGSAFlAwQBAjAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAw BwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgYUGCSsGAQQBgjcQBDF4MHYwYjELMAkGA1UEBhMC WkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1Ro YXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAhAeTAANDUMJU97n0e1AWxu4MIGH BgsqhkiG9w0BCRACCzF4oHYwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25z dWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJ c3N1aW5nIENBAhAeTAANDUMJU97n0e1AWxu4MA0GCSqGSIb3DQEBAQUABIIBAGVcAMQF24K6 yG/UyRUedTXOJMUowtN2t+Rz2u4ToULcC9Vgy3qw0C0gHjkM9JFds2ML237SlFq68YHk0OAP S6Y5UOeURMohpvSeoJ0z1fpcOvqAiB8uu7q/N/jtPcO0aBvNP3E+y5CUoVLqWaN4ZYArHoAR tPNBbi4c9BNFPEfa2S8Jk2d+SZQ6EMIh8bTmgJmpakIYFxL7IVqbHk85/k6bn/P2TIJURQl9 ZvWtvEIPyJ3mVyOFrkd5wJYN6yB1tx+0C6X/Lj3E6j3XKoFYL22wddVOYO1V9GpROx8UEfrS yn3YB6mdl5w7xgiYT6CRstJOcjMKEkuBja/abgcglpIAAAAAAAA= --------------ms050200070600090101040505-- --===============1770582969== 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 --===============1770582969==-- From p2pi-bounces@ietf.org Fri Jun 13 11:52: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 DDDED3A68CE; Fri, 13 Jun 2008 11:52: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 859493A68E1 for ; Fri, 13 Jun 2008 11:52:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.412 X-Spam-Level: * X-Spam-Status: No, score=1.412 tagged_above=-999 required=5 tests=[AWL=-1.065, BAYES_00=-2.599, DATE_IN_FUTURE_24_48=3.196, 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 8u9KZuB0T5m9 for ; Fri, 13 Jun 2008 11:52:50 -0700 (PDT) Received: from mailm.telecomitalia.it (mailm.telecomitalia.it [217.169.121.53]) by core3.amsl.com (Postfix) with ESMTP id 325A73A68CE for ; Fri, 13 Jun 2008 11:52:50 -0700 (PDT) Received: from ptpxch008rm001.idc.cww.telecomitalia.it ([156.54.205.170]) by mailm.telecomitalia.it with Microsoft SMTPSVC(6.0.3790.1830); Fri, 13 Jun 2008 20:53:20 +0200 Received: from grfhub701rm001.griffon.local ([10.19.3.8]) by ptpxch008rm001.idc.cww.telecomitalia.it with Microsoft SMTPSVC(6.0.3790.1830); Fri, 13 Jun 2008 20:53:20 +0200 Received: from [172.16.82.18] (163.162.180.246) by smtp.telecomitalia.it (10.19.3.40) with Microsoft SMTP Server (TLS) id 8.1.278.0; Fri, 13 Jun 2008 20:53:20 +0200 Message-ID: <485413A4.1060106@telecomitalia.it> Date: Sat, 14 Jun 2008 20:53:24 +0200 From: Enrico Marocco User-Agent: Mozilla-Thunderbird 2.0.0.14 (X11/20080509) MIME-Version: 1.0 To: Stephane Bortzmeyer References: <565621476.393261213359293462.JavaMail.root@dkny.pando.com> <4852862D.9030202@telecomitalia.it> <20080613151246.GA20314@nic.fr> In-Reply-To: <20080613151246.GA20314@nic.fr> X-OriginalArrivalTime: 13 Jun 2008 18:53:20.0986 (UTC) FILETIME=[BFF4C3A0:01C8CD86] Cc: "p2pi@ietf.org" Subject: Re: [p2pi] Refining the ALTO problem statement [Was: Re: discussing P2PI-related standardization in Dublin] X-BeenThere: p2pi@ietf.org X-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="===============0595096070==" Sender: p2pi-bounces@ietf.org Errors-To: p2pi-bounces@ietf.org --===============0595096070== Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms030805030807010705050007" --------------ms030805030807010705050007 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Stephane Bortzmeyer wrote: > As a beginner in this list, I request more explanations. Reading > draft-marocco-alto-problem-statement-00, I had the impression that > ALTO only follows one approach, "optimizing traffic generated by P2P > applications Using Information Provided By Isps And Network > Operators" (section 1). Actually the draft was written a couple of months ago with much emphasis on ISP-based solutions. After several discussions, it has become clear that the same service could be effectively provided by third-parties. We'll try make it clearer in the next version of the draft. > I'm a big fan of ICS myself but are they really on-topic? Or is it too > early to say? The main goal here is to provide an interface to help p2p applications in the peer selection process. Whether such interface is implemented by an oracle deployed by some ISPs, or by a distributed coordinate system should be transparent to the standardization effort we are proposing. -- Ciao, Enrico --------------ms030805030807010705050007 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 hkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wODA2MTQxODUzMjRaMCMG CSqGSIb3DQEJBDEWBBSUNC8MZetYorFRi1ujCTTLX/shOTBfBgkqhkiG9w0BCQ8xUjBQMAsG CWCGSAFlAwQBAjAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAw BwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgYUGCSsGAQQBgjcQBDF4MHYwYjELMAkGA1UEBhMC WkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1Ro YXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAhAeTAANDUMJU97n0e1AWxu4MIGH BgsqhkiG9w0BCRACCzF4oHYwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25z dWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJ c3N1aW5nIENBAhAeTAANDUMJU97n0e1AWxu4MA0GCSqGSIb3DQEBAQUABIIBAKraUsqmhyOn yYHICcUn3ta6NiwJKesF5mQmUUa47du6ck2hHBFE15UNqk713Piw+1O+qN8sClRYv3EKdpEo MbiApTZefu74Vl5dppXywPl6uI9q5LC4zju8yHzPl1lQM45D9ZFax9s/0Ybd41MVT8jHOW4Q Bw5eolda7Z7tb90Wr4gl+ZMv+eUKzfPWiFXKhMSVHBAiWiNnGCZQaib5lQbMTH9YGRhkBWQH xrl5mDJL0I71mpXJIkRcVpslFyRBFoH5ZnPvMy5c0ksp0RQjTUy1yAAzi72w8K6AwKexoPix f96CCyF8kBp+r4eSF4KIvxJ6uxOb8LFbuLfOnJtZB9YAAAAAAAA= --------------ms030805030807010705050007-- --===============0595096070== 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 --===============0595096070==-- From p2pi-bounces@ietf.org Fri Jun 13 12:43:46 2008 Return-Path: X-Original-To: p2pi-archive@ietf.org Delivered-To: ietfarch-p2pi-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6A49E3A691B; Fri, 13 Jun 2008 12:43:46 -0700 (PDT) X-Original-To: p2pi@core3.amsl.com Delivered-To: p2pi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3E8F83A691B for ; Fri, 13 Jun 2008 12:43:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.678 X-Spam-Level: * X-Spam-Status: No, score=1.678 tagged_above=-999 required=5 tests=[AWL=-0.799, BAYES_00=-2.599, DATE_IN_FUTURE_24_48=3.196, 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 3h4ZBZXGugam for ; Fri, 13 Jun 2008 12:43:44 -0700 (PDT) Received: from maill.telecomitalia.it (maill.telecomitalia.it [217.169.121.52]) by core3.amsl.com (Postfix) with ESMTP id 7A1543A67A7 for ; Fri, 13 Jun 2008 12:43:43 -0700 (PDT) Received: from ptpxch009rm001.idc.cww.telecomitalia.it ([156.54.205.171]) by maill.telecomitalia.it with Microsoft SMTPSVC(6.0.3790.1830); Fri, 13 Jun 2008 21:44:14 +0200 Received: from grfhub703rm001.griffon.local ([10.19.3.10]) by ptpxch009rm001.idc.cww.telecomitalia.it with Microsoft SMTPSVC(6.0.3790.1830); Fri, 13 Jun 2008 21:44:14 +0200 Received: from [172.16.82.18] (163.162.180.246) by smtp.telecomitalia.it (10.19.3.42) with Microsoft SMTP Server (TLS) id 8.1.263.0; Fri, 13 Jun 2008 21:44:13 +0200 Message-ID: <48541F91.1010306@telecomitalia.it> Date: Sat, 14 Jun 2008 21:44:17 +0200 From: Enrico Marocco User-Agent: Mozilla-Thunderbird 2.0.0.14 (X11/20080509) MIME-Version: 1.0 To: Lars Eggert References: <22F6A875-B548-4C65-AB68-B88E526CCA33@nokia.com> <6E1603B0-7116-45F9-A510-DC5F9040298B@nokia.com> <48516BE2.2080901@telecomitalia.it> In-Reply-To: X-OriginalArrivalTime: 13 Jun 2008 19:44:14.0437 (UTC) FILETIME=[DBF46950:01C8CD8D] Cc: "p2pi@ietf.org" Subject: Re: [p2pi] Refining the ALTO problem statement [Was: Re: discussing P2PI-related standardization in Dublin] X-BeenThere: p2pi@ietf.org X-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="===============1735960400==" Sender: p2pi-bounces@ietf.org Errors-To: p2pi-bounces@ietf.org --===============1735960400== Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms010704020008040506050603" --------------ms010704020008040506050603 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: quoted-printable Lars Eggert wrote: > I have a few comments about the kinds of information that the oracle > might provide to the app. Lars, thanks for your comments. > These are all OK, except for the bit about "bandwidth constraints". > The available bandwidth along a path changes very rapidly, on > timescales roughly O(RTT), because bandwidth consumption is regulated > by the congestion control loops of the flows sharing a path. This > pretty much guarantees that any such information an oracle could > maintain will be stale by the time that an oracle can provide it to an > application. So this information is unlikely to be useful to an app; > and I can even construct cases where using this stale information > leads to traffic oscillations, which is problematic. >=20 > Modulo this concern about stuff that varies on short timescales, a > simple mechanism that lets an app query an oracle about the things in > the two bullets above would be useful. Ok. > I'm MUCH less convinced of the usefulness of the shopping list of > things in the following bullets. For a lot of the things below, it's > unclear to me why an application would want them and where an oracle > would get them from. I don't think they should be part of any > standardization effort at this time. (Looking at them from a research > perspective is fine.) >=20 >> * Support for cost and charging information for application so that >> applications can make appropriate trade-offs; >=20 > Can you be a bit more explicit about whose costs this is about? Who is > paying whom, on what timescales and based on what resources? Sure. This was one bullet point that was made in Prof. Schulzrinne's=20 paper. I quote the text from the paper: Cost-of-bandwidth information Relying on cooperative applications to be =93nice=94 is probably insufficient unless there is an incentive. There are at least three possibilities, namely either volume limiting, rate limiting or volume-based charging. For example, a network could offer a tiered tariff that allows unlimited bandwidth within the same AS, 100 kb/s rate-limited but unlimited prioritized DiffServ to anywhere and volume-limited bulk traffic to any AS. There are several ways to convey this information to applications, allowing them to make appropriate trade-offs. For example, a network could provide an information service with a list of service descriptors, similar to the RSVP TSpec. Alternatively, a protocol such as GIST could discover= the cost of particular destination. The service classes may change over time. For example, a network may offer "midnight specials" when the network is idle during off-hours, encouraging bulk downloads during that time. >> * Capabilities and characteristics of peers (i.e., last hop >> bandwidth, >> etc.); >=20 > The bandwidth example is IMO again problematic (and it's not a peer > characteristic, it's a path characteristic.) Yes, you are right in characterizing this as a path characteristic. > Also, why would an oracle= > know anything about the capabilities or characteristics of the peers? > Are the peers supposed to register with the oracle? That goes far > beyond what I thought this BOF was about. No, we are not suggesting that peers register with the oracle. This is=20 more along the point of trying to generate some discussion. What if a=20 peer is willing to publish its capabilities, either for other peers or=20 for an oracle. Is this something that is worth considering, if not for=20 a standardization aspect, at least as a research problem? >> * Network policies; >=20 > Such as? Along the same line as mentioned above in the "Cost-of-bandwidth"=20 information. >> + Type(s) of information that is provided to the oracle for >> rendering an >> equitable decision: >> * List of peer candidate IP addresses; >> * Parameter to optimize (cost, delay, ...); >=20 > Why is it useful to query the oracle for delay? An app can get a > relatively accurate and more importantly timely RTT sample by sending > a few packets to a peer. That practice causes no issues for operators, > since the traffic volume is so low. Well, the use case I had in mind here was the selection of media relays=20 in real-time communication systems, when the list of candidate peers may = have hundreds or thousands of elements (think of Skype). In such a=20 case, provided the oracle can elaborate lists and not on single=20 instances only, a one query would replace tons of RTT measurements. On a side note, is it possible for RTT to be small on a high latency=20 link one hop away when compared to a slightly higher RTT on low latency=20 links six hops away? That is, the time it takes for a peer to download=20 a large content from the peer with the lower RTT is actually higher than = the time it takes to do the same from the peer with higher RTT. --=20 Ciao, Enrico --------------ms010704020008040506050603 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 hkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wODA2MTQxOTQ0MTdaMCMG CSqGSIb3DQEJBDEWBBSZ3L7FQGyVhZ/dGCtDaAomK2/g8TBfBgkqhkiG9w0BCQ8xUjBQMAsG CWCGSAFlAwQBAjAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAw BwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgYUGCSsGAQQBgjcQBDF4MHYwYjELMAkGA1UEBhMC WkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1Ro YXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAhAeTAANDUMJU97n0e1AWxu4MIGH BgsqhkiG9w0BCRACCzF4oHYwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25z dWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJ c3N1aW5nIENBAhAeTAANDUMJU97n0e1AWxu4MA0GCSqGSIb3DQEBAQUABIIBACWx7foFtg/z NCONQE0b8GVl2lBd09rCnJTEv3u2njgnvvma0x2K5tq1W/LDaWEmwf3kEwoQA+sgRuAgxU84 wr13J/M92sEfwiTJ+TLMxV69xaQZnhx9ekGmrRD9b+4ZHFt+z99bGqOZ5EscxA6bKWScxKxS 1j2lt+xXsgD9BH2gy49a/rxVWS5DCZInVTm/DdLcDW02wpYgE/kPRCv73me8hEmkbUjO/mKp sJFc3VwP0V1a2TA6jn4Qfq90fERRSuVFsTjc6ip6zvlVWgo3QIUTAZA27A2M2P7LDGpM/gv4 A7vmen+Dopbt0byE1mwGZN1TwxEddeZLbh5CDP7+9igAAAAAAAA= --------------ms010704020008040506050603-- --===============1735960400== 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 --===============1735960400==-- From p2pi-bounces@ietf.org Fri Jun 13 13:18:55 2008 Return-Path: X-Original-To: p2pi-archive@ietf.org Delivered-To: ietfarch-p2pi-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4DE6A3A68E1; Fri, 13 Jun 2008 13:18:55 -0700 (PDT) X-Original-To: p2pi@core3.amsl.com Delivered-To: p2pi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 66F583A68E1 for ; Fri, 13 Jun 2008 13:18:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.022 X-Spam-Level: X-Spam-Status: No, score=-10.022 tagged_above=-999 required=5 tests=[AWL=-0.072, BAYES_00=-2.599, HABEAS_ACCREDITED_COI=-8, IP_NOT_FRIENDLY=0.334, SARE_MILLIONSOF=0.315] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o9Fmb9pIBFBC for ; Fri, 13 Jun 2008 13:18:52 -0700 (PDT) Received: from dkny.pando.com (dkny.pando.com [67.99.55.163]) by core3.amsl.com (Postfix) with ESMTP id D49AA3A6885 for ; Fri, 13 Jun 2008 13:18:51 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by dkny.pando.com (Postfix) with ESMTP id 26F1FE10CB1; Fri, 13 Jun 2008 16:19:24 -0400 (EDT) X-Virus-Scanned: amavisd-new at Received: from dkny.pando.com ([127.0.0.1]) by localhost (dkny.pando.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PmmaMWAJPHOW; Fri, 13 Jun 2008 16:19:15 -0400 (EDT) Received: from [10.10.20.61] (unknown [10.10.20.61]) by dkny.pando.com (Postfix) with ESMTP id 04471E10CAF; Fri, 13 Jun 2008 16:19:15 -0400 (EDT) Message-Id: <1101C5F1-9CDC-4E20-90FA-1F0CEE0547BC@pando.com> From: Laird Popkin To: stefano previdi In-Reply-To: Mime-Version: 1.0 (Apple Message framework v924) Date: Fri, 13 Jun 2008 16:19:14 -0400 References: X-Mailer: Apple Mail (2.924) Cc: p2pi@ietf.org Subject: Re: [p2pi] Refining the ALTO problem statement [Was: Re: discussing P2PI-related standardization in Dublin] X-BeenThere: p2pi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: P2P Infrastructure Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: p2pi-bounces@ietf.org Errors-To: p2pi-bounces@ietf.org Comments below. On Jun 13, 2008, at 9:01 AM, stefano previdi wrote: > Hi Laird, > > I understand your concern and let me try to answer from a routing > implementation perspective. My thoughts are as follows: > > - the options of having a list of IP addresses to rank may be faced > to some > limitations but I probably have different view. I believe one > alternative is > to have a ranking of _pair_ of IP addresses (I believe there's a > proposal > made already on this direction). It doesn't address scalability per > se but > it allows other form of oracle/proximity capability. > > - From a routing algorithm perspective (and its implementation). The > localization of 10 Vs. 1000 addresses may not incur an exponential > complexity. I fact, routing algorithms/implementations are faced to > this > problem for years now... ;-) In the last years a lot of work has > been done > in the routing layer in order to improve performance and to minimize > the > impact of routing computations. We are now leveraging all this work > in order > to address other type of routing paradigms (using the same input). > > - State can be kept even if it results from different computations. > This > allows an "oracle/proximity" provider to minimize the amount of > computation > and to be able do deliver results on-the-fly. I'm not concerned about the computational cost of figuring out which peers to connect to which - we do that now in our Trackers, and with enough pre-computation it's remarkably fast, though of course not quite as fast as picking random numbers from a list. But we don't mind a little CPU overhead if it generates performance and efficiency. :-) The main concern that I have is that I can't take an extremely high volume, fast, in-memory operation and turn it into a blocking external message, because that makes my system orders of magnitude slower and more fragile. The issue isn't the algorithm, it's where we draw the "line" through the system where data crosses the wire. If the high-volume interactions (mapping IP's to network locations, finding nearby locations, and returning a sorted list of nearby IP's) can be done in memory, and only periodic map updates are done over the wire, that's more efficient then if the high-volume interactions all have to cross the wire. Now perhaps we can find a way to have "sorting lists of IP's" work really well. As far as the ALTO BOF goes, I just don't want us to assume that approach, because I tried it last year and hit a wall, and I don't want us to collectively hit that wall without at least knowing that there's a wall in the vicinity. > - There are apps models that have some form of hierarchy (e.g: > trackers) and > some others not. Should we have different models in the oracle too, or > should we try to be as much as possible transparent/agnostic ? I'd > vote for > the latter. This is a very good question. In principle I agree that a single, more 'generic' solution would be better. But the communication patterns for tracker-based and trackerless p2p networks are quite different, and the scaling requirements are so extreme, that it's not clear to me what a single approach can work well for both. But that's what the ALTO discussions will help explore. For a tracker-based system, my instinct is that a "map-based" approach is more efficient, because there are a small number of Trackers and they have plenty of resources to keep a map in memory. For a trackerless system, my instinct is that a "sort IP list" approach might be more appropriate, since each peer only knows about a small piece of the swarm (so the lists aren't too big) and it seems inefficient to send a complex "map" to millions of peers. > - I can't speak much about the legal/psychological issue (disclosing > p2p > addresses to SP) as I come from bottom layers, but what I can say is > that, > technically, the SP doesn't need any form of oracle in order to > understand > who among his customers is a p2p addicted... ;-) I am sure that's true - uplink utilization probably correlates pretty well with p2p application usage. But if the p2p network sent IP lists for every swarm to the oracle, that means that the ISP would know exactly who was in each swarm for each unique piece of content in the swarm, and which p2p network that piece of content was in, and (to some degree) what the content is. This is broadcasting a level of detail around user behavior that is, to be frank, a little unsettling. > - In one point we're in violent agreement: This is a great discussion. Yep. I am enjoying this quite a bit. > Thanks. > > s. > > >> From: Laird Popkin >> >> This is a great discussion. >> >> One point I'll make related to the signaling protocol for querying >> the >> "oracle" is that while the "send in a list of peer IP addresses and >> receive a >> sorted list back" approach is appealing in its simplicity, it has >> some serious >> limitations that would need to be taken into account. >> >> It's important to keep in mind that optimizing peer selection for p2p >> transfers has the most impact for large swarms. That is, if there >> are only 20 >> people on the planet that can serve you data, (1) it doesn't take >> too long to >> connect to all of them so optimized peer selection doesn't save >> much peer >> connection time, and (2) the odds of any of them being in the same >> ISP is >> fairly low, so optimized peer selection doesn't affect data flow >> much. >> Optimizing peer selection is focused on swarms with very large >> numbers of >> peers. For example, we often see swarms with thousands or tens of >> thousands of >> peers. These are a small percentage of swarms, of course, but they >> are >> responsible for a disproportionately large volume of data. For >> example, when >> Yale surveyed "major tracker sites" they saw that a very small >> percentage of >> swarms had 100+ peers, but that those swarms were responsible for >> well over >> 50% of downloads. For perspective, at Pando, we see swarms with >> thousands to >> tens of thousands of peers fairly often. >> >> It is for these large sarms where the "list of IPs" approach runs >> into some >> pragmatic issues: >> - The "oracle" must be sent the current complete set of IPs in each >> swarm. >> This means that the queries would be very large (e.g. a list of >> 1,000 IP >> addresses). This is not very cacheable, because swarm composition >> is highly >> dynamic. And it has to be a complete list, or the value of the >> guidance >> degrades dramatically. (Conceivable this could be implemented as >> 'delta' >> updates, but that raises oracle state issues, makes the software >> and protocol >> much more complex, etc.). >> >> - The "oracle" would have to maintain state (or recompute on every >> query) for >> every swarm in every p2p network. >> - The volume of queries would be very large (perhaps on the order >> of 100K >> queries per second, across all p2p networks operating within an ISP). >> - The queries cannot be cached (because the first announce is the >> most >> important to optimize, and following queries need to include all >> new peers, >> and each query generates a response unique to the peer being >> provided the >> guidance). >> - The ISP would need to scale the "oracle" capacity to satisfy this >> volume. >> - It exposes the entire membership and data flow of the p2p network >> to the >> ISPs, which raises obvious legal and privacy issues. Imagine asking >> your >> lawyers whether they want to run Pirate's Bay's Trackers. >> - It makes every Tracker announce slow, expensive and unreliable >> instead of >> fast, cheap and reliable. >> >> This is why we shifted (in the P4P approach) away from the more >> obvious IP >> list approach to moving the guidance into the Tracker's memory. >> Admittedly >> that does require ISPs to expose some abstract guidance information >> (IP >> prefixes and percentages), but in return: >> - The communication from the "oracle" to the p2p network is a single >> asynchronous update (e.g. as little as one message every hour) >> instead of one >> message per peer announce per swarm. >> - The p2p network's Tracker can process peer requests in-memory, >> without >> having to make a blocking network call to an external "oracle". >> This is >> several orders of magnitude faster, more reliable, and far less >> resource >> intensive. >> - There's minimal information exposed between the ISP and the P2P >> network >> (which is, from a legal and privacy angle, better for both P2P and >> ISP). >> >> - Laird Popkin, CTO, Pando Networks >> mobile: 646/465-0570 >> >> ----- Original Message ----- >> From: "stefano previdi" >> To: "Enrico Marocco" , p2pi@ietf.org >> Sent: Friday, June 13, 2008 4:52:29 AM (GMT-0500) America/New_York >> Subject: Re: [p2pi] Refining the ALTO problem statement [Was: Re: >> discussing >> P2PI-related standardization in Dublin] >> >> Enrico, >> >> I mostly agree mostly with everything below. My suggestion (as a >> routing guy >> more than an apps guy) is also to scope what could be extended/ >> enhanced in >> routing protocols in order to improve localization mechanisms >> (whatever they >> are). >> >> As an example, we have extended ISIS routing protocol in order to >> carry some >> application related information (at this stage is an empty >> container) and >> probably these kind of enhancements may have a use in localization/ >> oracle >> services. >> >> s. >> >> >>> From: Enrico Marocco >>> >>> Peterson, Jon wrote: >>>> The proposal for the ALTO BoF (which roughly covers (3)) is now >>>> in the >>>> BoF tracker. You can read about it at its home page: >>>> >>>> http://alto.tilab.com/ >>> [...] >>>> we hope that discussions surrounding the BoF could elucidate the >>>> proper >>>> division of labor and approach to this problem. >>> >>> To follow up on Jon's thoughts and to reflect discussions that >>> happened >>> during the MIT workshop and on the mailing list, Vijay and I are >>> going >>> to update the problem statement draft the ALTO BoF proposal is >>> based on >>> (draft-marocco-alto-problem-statement-00). >>> >>> As a prelude to focus the ALTO BoF, it would be great to start >>> coalescing community agreement on ensuring that the scope of the >>> problem >>> is well defined and understood. >>> >>> Essentially, the problem that ALTO will attempt to solve is this: >>> applications (P2P and otherwise) that make intensive use of the >>> network >>> bandwidth or want to make decisions to optimize some function (see >>> use >>> cases) may be interested in choosing all or some of their peers >>> based on >>> recommendations provided by some network entity -- colloquially >>> called >>> an oracle -- that has more of a global view on the peers in the >>> network, >>> their topological distances, and their capabilities than the >>> application >>> itself does. >>> >>> In thinking about the problem, it may help to consider the >>> following: >>> >>> + Use cases: current version of the draft identifies four use >>> cases for >>> ALTO solutions (file-sharing, VoIP, p2p streaming and DHTs) but >>> others >>> come to mind (e.g. cache/http-mirror selection, CDN). At the MIT >>> workshop, Ted Hardie coined the term "unattended consequences" of >>> peer-to-peer nodes where traffic runs constantly for as long as the >>> resources to that node are popular. Video feeds to remote stations >>> were identified as a category. >>> >>> + Third-party services: even if topology information is directly >>> available to network operators, nothing should prevent third- >>> parties >>> to provide peer selection services alternatively to or in >>> competition >>> with ISPs. An incomplete list of proposed solutions for providing >>> such services is online at http://alto.tilab.com/resources.html; >>> >>> + Type(s) of information that are likely provided by the oracle >>> (note >>> that a third-party oracle may not have access to some of this >>> information): >>> * Given a list of peer candidate IP addresses, sort them >>> according to >>> preferences (topological proximity, bandwidth constraints, >>> etc.) and >>> return to querying application; >>> * Ability for an application to determine its network location and >>> proximity to other nodes; >>> * Support for cost and charging information for application so that >>> applications can make appropriate trade-offs; >>> * Capabilities and characteristics of peers (i.e., last hop >>> bandwidth, >>> etc.); >>> * Network policies; >>> * ... >>> >>> + Type(s) of information that is provided to the oracle for >>> rendering an >>> equitable decision: >>> * List of peer candidate IP addresses; >>> * Parameter to optimize (cost, delay, ...); >>> * ... >>> >>> This is mainly what we have captured so far; however, feedback, >>> suggestions and contributions are not only welcome, but at this time >>> even required for the successful setting of a BOF. >>> >>> Besides, the draft currently identifies two elements for which >>> standardization work would be required, namely a discovery >>> mechanisms >>> for locating oracles and a signaling protocol for querying them. Do >>> people think the core solution for ALTO should include anything >>> else? >>> >>> -- >>> Ciao, >>> Enrico >>> _______________________________________________ >>> p2pi mailing list >>> p2pi@ietf.org >>> https://www.ietf.org/mailman/listinfo/p2pi >> >> >> _______________________________________________ >> p2pi mailing list >> p2pi@ietf.org >> https://www.ietf.org/mailman/listinfo/p2pi > > _______________________________________________ p2pi mailing list p2pi@ietf.org https://www.ietf.org/mailman/listinfo/p2pi From p2pi-bounces@ietf.org Fri Jun 13 15:57:01 2008 Return-Path: X-Original-To: p2pi-archive@ietf.org Delivered-To: ietfarch-p2pi-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 618123A6969; Fri, 13 Jun 2008 15:57:01 -0700 (PDT) X-Original-To: p2pi@core3.amsl.com Delivered-To: p2pi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CCCC43A6969 for ; Fri, 13 Jun 2008 15:56:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.267 X-Spam-Level: X-Spam-Status: No, score=-2.267 tagged_above=-999 required=5 tests=[AWL=0.332, 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 UjXyceghNVvf for ; Fri, 13 Jun 2008 15:56:58 -0700 (PDT) Received: from mailhost.jlc.net (mailhost.jlc.net [199.201.159.9]) by core3.amsl.com (Postfix) with ESMTP id A1A543A6945 for ; Fri, 13 Jun 2008 15:56:58 -0700 (PDT) Received: by mailhost.jlc.net (Postfix, from userid 104) id BBCC933C6C; Fri, 13 Jun 2008 18:57:27 -0400 (EDT) Date: Fri, 13 Jun 2008 18:57:27 -0400 From: John Leslie To: Lars Eggert Message-ID: <20080613225727.GC3759@verdi> References: <22F6A875-B548-4C65-AB68-B88E526CCA33@nokia.com> <6E1603B0-7116-45F9-A510-DC5F9040298B@nokia.com> <48516BE2.2080901@telecomitalia.it> Mime-Version: 1.0 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.1i Cc: p2pi@ietf.org Subject: Re: [p2pi] Refining the ALTO problem statement X-BeenThere: p2pi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: P2P Infrastructure Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: p2pi-bounces@ietf.org Errors-To: p2pi-bounces@ietf.org Lars Eggert wrote: > > I have a few comments about the kinds of information that the oracle > might provide to the app. > > The high level bit is that I believe that although it will be possible > to provide information that changes on relatively large timescales > (such as information about topological proximity), it will be both > very difficult and potentially problematic to share performance- > related information that changes on short timescales in the same > fashion. That's an implementation issue. We should do protocol design before we do implementation. Besides, it's only a couple orders of magnitude "difficult." It might be quite practical five years from now. > On 2008-6-12, at 21:33, ext Enrico Marocco wrote: > >> * Given a list of peer candidate IP addresses, sort them according to >> preferences (topological proximity, bandwidth constraints, etc.) >> and return to querying application; >> * Ability for an application to determine its network location and >> proximity to other nodes; > > These are all OK, except for the bit about "bandwidth constraints". > The available bandwidth along a path changes very rapidly, on > timescales roughly O(RTT), because bandwidth consumption is regulated > by the congestion control loops of the flows sharing a path. Absolutely true. > This pretty much guarantees that any such information an oracle could > maintain will be stale by the time that an oracle can provide it to an > application. Not as true. The application isn't particularly interested in one instantaneous snapshot: it's interested in what's likely to be the case over an extended period (or how long it is likely to take to transfer a known amount of data. Statistical summaries are much more useful: and the oracle is in a good position to provide those. > So this information is unlikely to be useful to an app; > and I can even construct cases where using this stale information > leads to traffic oscillations, which is problematic. Traffic oscillations are indeed problematic. But can you construct a case where statistical damping isn't sufficient to guard against that? > I'm MUCH less convinced of the usefulness of the shopping list of > things in the following bullets. For a lot of the things below, it's > unclear to me why an application would want them and where an oracle > would get them from. I don't think they should be part of any > standardization effort at this time. We should be standardizing a protocol, not an implementation. >> * Support for cost and charging information for application so that >> applications can make appropriate trade-offs; Clearly, applications have every reason to consider cost/charging information provided by the supplier the user will have to pay. > Can you be a bit more explicit about whose costs this is about? Who is > paying whom, on what timescales and based on what resources? I'm not sure we can answer any of those, but it would be good for the protocol to carry the answers to those questions. >> * Capabilities and characteristics of peers (i.e., last hop >> bandwidth, etc.); > > The bandwidth example is IMO again problematic (and it's not a peer > characteristic, it's a path characteristic.) Also, why would an oracle > know anything about the capabilities or characteristics of the peers? > Are the peers supposed to register with the oracle? That goes far > beyond what I thought this BOF was about. The peer might impose its own limits, beyond the limits of the path. It might (or might not) be appropriate to standardize a way of advertising these. >> * Network policies; > > Such as? Good question: I can imagine several, but don't know if we could define a good set of metrics. >> + Type(s) of information that is provided to the oracle for >> rendering an equitable decision: >> * List of peer candidate IP addresses; >> * Parameter to optimize (cost, delay, ...); > > Why is it useful to query the oracle for delay? Because instantaneous delay isn't a good measure. An oracle will be in a better position to know minimum latency, plus normal range for minimal congestion. -- John Leslie _______________________________________________ p2pi mailing list p2pi@ietf.org https://www.ietf.org/mailman/listinfo/p2pi From p2pi-bounces@ietf.org Fri Jun 13 17:16: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 1F8A73A69F7; Fri, 13 Jun 2008 17:16: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 8B3913A6A3B for ; Fri, 13 Jun 2008 17:16:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.457 X-Spam-Level: X-Spam-Status: No, score=-1.457 tagged_above=-999 required=5 tests=[AWL=-0.485, BAYES_00=-2.599, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334, MISSING_HEADERS=1.292] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G2R+Ew3VLXvl for ; Fri, 13 Jun 2008 17:16:03 -0700 (PDT) Received: from outbound-mail-146.bluehost.com (outbound-mail-146.bluehost.com [67.222.38.36]) by core3.amsl.com (Postfix) with SMTP id 35B563A69F7 for ; Fri, 13 Jun 2008 17:16:03 -0700 (PDT) Received: (qmail 14353 invoked by uid 0); 14 Jun 2008 00:16:34 -0000 Received: from unknown (HELO host46.hostmonster.com) (74.220.202.46) by outboundproxy5.bluehost.com with SMTP; 14 Jun 2008 00:16:34 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=bennett.com; h=Received:Message-ID:Date:From:Organization:User-Agent:MIME-Version:CC:Subject:References:In-Reply-To:Content-Type:X-Identified-User:DomainKey-Status; b=JWkPrjZ3vhXWtLMzVxYyAdT+wjiIQopkthTSH9a6fuqvzfT44o3GKHPp0Y+YmiZZygRASq7CW8MT6GJ8rUt1cLATwqw3SOsbXOz/BTmErCGU+0it+XrhmOzK0IpJSNsM; Received: from adsl-69-106-235-168.dsl.pltn13.pacbell.net ([69.106.235.168] helo=[192.168.1.2]) by host46.hostmonster.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.68) (envelope-from ) id 1K7JRa-0000dX-88; Fri, 13 Jun 2008 18:16:34 -0600 Message-ID: <48530DDB.9020707@bennett.com> Date: Fri, 13 Jun 2008 17:16:27 -0700 From: Richard Bennett Organization: Network Strategies User-Agent: Thunderbird 2.0.0.14 (X11/20080501) MIME-Version: 1.0 References: <22F6A875-B548-4C65-AB68-B88E526CCA33@nokia.com> <6E1603B0-7116-45F9-A510-DC5F9040298B@nokia.com> <14F37DBB-BCF0-43C9-90D0-A8B7D4A9FD36@nokia.com> In-Reply-To: <14F37DBB-BCF0-43C9-90D0-A8B7D4A9FD36@nokia.com> X-Identified-User: {842:host46.hostmonster.com:bennett1:bennett.com} {sentby:smtp auth 69.106.235.168 authed with richard@bennett.com} DomainKey-Status: no signature Cc: P2PSIP Mailing List , p2pi@ietf.org, "iab@iab.org IAB" , TSV Area , "IESG \(\(E-mail\)\)" , p2prg@irtf.org Subject: Re: [p2pi] discussing P2PI-related standardization in Dublin X-BeenThere: p2pi@ietf.org X-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="===============0335405322==" Sender: p2pi-bounces@ietf.org Errors-To: p2pi-bounces@ietf.org This is a multi-part message in MIME format. --===============0335405322== Content-Type: multipart/alternative; boundary="------------070009080309060704070509" This is a multi-part message in MIME format. --------------070009080309060704070509 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Do we have a date for the proposed BOF in Dublin? RB Lars Eggert wrote: > Hi, > > On 2008-6-6, at 17:40, ext Lars Eggert wrote: > >> related to the work item below, I've just heard that some folks had >> already been discussing the submission of a more targeted BOF >> proposal. Depending on the details of that proposal (which I haven't >> seen yet), work item (3) might be subsumed by it. >> > > this BOF proposal has now materialized in form of ALTO (http://alto.tilab.com/ > ), a BOF proposal targeted at APP and RAI. > > It's hence somewhat likely that we may have a TANA BOF in TSV that > focuses on the work items (1) and (2) from my original email, and a > second ALTO BOF hosted by APP and RAI. > > (Note: this email is *not* an IESG approval of either the TANA or ALTO > BOF - those will come from the responsible ADs if and when they come.) > > ALTO is currently scoped a bit more broadly than the TANA work item > (3) was, and some of the broader proposals in the ALTO space could > lead to significant transport issues. A fraction of the ALTO > proponents argues to exchange information related to end-to-end > performance (bandwidth, RTT, congestion, transfer time estimates, > etc.) through the oracle, for example. > > I'd like to ask transport folks to participate in the discussion on > ALTO on the p2pi@ietf.org mailing list, in order to discuss the > transport implications of the various ALTO ideas. > > >> On 2008-6-6, at 15:58, Lars Eggert wrote: >> >>> (3) A mechanism that lets an application that can >>> transfer data from or to several potential peers (i.e., >>> servers, caches, end systems) select a subset of peers >>> for efficient transmission in a way that is aligned with >>> the dynamic interconnection structure of the network >>> operators that provide connectivity to those peers. >>> Application designers, network equipment vendors and >>> network operators will need to collaborate on this work >>> item to define what kinds of dynamic interconnection >>> information is useful to applications, how to obtain it, >>> and how to provide it to applications, resulting in a >>> generic mechanism that is broadly applicable to many >>> current and future applications. This work item has >>> obvious interactions with the IETF's Application, Routing >>> and Operations areas. In order to make this effort more >>> manageable, it may make sense to work out the >>> requirements for such a solution first, before discussing >>> individual proposals or breaking up the work into pieces >>> for specification in different areas or WGs. >>> > > Lars > _______________________________________________ > p2pi mailing list > p2pi@ietf.org > https://www.ietf.org/mailman/listinfo/p2pi > -- Richard Bennett --------------070009080309060704070509 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Do we have a date for the proposed BOF in Dublin?

RB

Lars Eggert wrote: 
Hi,

On 2008-6-6, at 17:40, ext Lars Eggert wrote:
  
related to the work item below, I've just heard that some folks had  
already been discussing the submission of a more targeted BOF  
proposal. Depending on the details of that proposal (which I haven't  
seen yet), work item (3) might be subsumed by it.
    

this BOF proposal has now materialized in form of ALTO (http://alto.tilab.com/ 
), a BOF proposal targeted at APP and RAI.

It's hence somewhat likely that we may have a TANA BOF in TSV that  
focuses on the work items (1) and (2) from my original email, and a  
second ALTO BOF hosted by APP and RAI.

(Note: this email is *not* an IESG approval of either the TANA or ALTO  
BOF - those will come from the responsible ADs if and when they come.)

ALTO is currently scoped a bit more broadly than the TANA work item  
(3) was, and some of the broader proposals in the ALTO space could  
lead to significant transport issues. A fraction of the ALTO  
proponents argues to exchange information related to end-to-end  
performance (bandwidth, RTT, congestion, transfer time estimates,  
etc.) through the oracle, for example.

I'd like to ask transport folks to participate in the discussion on  
ALTO on the p2pi@ietf.org mailing list, in order to discuss the  
transport implications of the various ALTO ideas.

  
On 2008-6-6, at 15:58, Lars Eggert wrote:
    
(3) A mechanism that lets an application that can
  transfer data from or to several potential peers (i.e.,
  servers, caches, end systems) select a subset of peers
  for efficient transmission in a way that is aligned with
  the dynamic interconnection structure of the network
  operators that provide connectivity to those peers.
  Application designers, network equipment vendors and
  network operators will need to collaborate on this work
  item to define what kinds of dynamic interconnection
  information is useful to applications, how to obtain it,
  and how to provide it to applications, resulting in a
  generic mechanism that is broadly applicable to many
  current and future applications. This work item has
  obvious interactions with the IETF's Application, Routing
  and Operations areas. In order to make this effort more
  manageable, it may make sense to work out the
  requirements for such a solution first, before discussing
  individual proposals or breaking up the work into pieces
  for specification in different areas or WGs.
      

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

-- 
Richard Bennett
--------------070009080309060704070509-- --===============0335405322== 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 --===============0335405322==-- From p2pi-bounces@ietf.org Sat Jun 14 01:24:13 2008 Return-Path: X-Original-To: p2pi-archive@ietf.org Delivered-To: ietfarch-p2pi-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 799573A69B2; Sat, 14 Jun 2008 01:24:13 -0700 (PDT) X-Original-To: p2pi@core3.amsl.com Delivered-To: p2pi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 84E603A67FA; Sat, 14 Jun 2008 01:24:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.484 X-Spam-Level: X-Spam-Status: No, score=-6.484 tagged_above=-999 required=5 tests=[AWL=0.115, 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 ZS2iTygaZ6Uv; Sat, 14 Jun 2008 01:24:11 -0700 (PDT) Received: from mgw-mx09.nokia.com (smtp.nokia.com [192.100.105.134]) by core3.amsl.com (Postfix) with ESMTP id 71D623A67B4; Sat, 14 Jun 2008 01:24:11 -0700 (PDT) Received: from esebh107.NOE.Nokia.com (esebh107.ntc.nokia.com [172.21.143.143]) by mgw-mx09.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id m5E8OYje030154; Sat, 14 Jun 2008 03:24:37 -0500 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Sat, 14 Jun 2008 11:24:34 +0300 Received: from [192.168.255.2] ([10.241.184.208]) by esebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Sat, 14 Jun 2008 11:24:33 +0300 Message-Id: <68E81235-AA20-4834-876C-2ED46281A236@nokia.com> From: Lars Eggert To: ext Richard Bennett In-Reply-To: <48530DDB.9020707@bennett.com> Mime-Version: 1.0 (Apple Message framework v924) Date: Sat, 14 Jun 2008 11:24:26 +0300 References: <22F6A875-B548-4C65-AB68-B88E526CCA33@nokia.com> <6E1603B0-7116-45F9-A510-DC5F9040298B@nokia.com> <14F37DBB-BCF0-43C9-90D0-A8B7D4A9FD36@nokia.com> <48530DDB.9020707@bennett.com> X-Mailer: Apple Mail (2.924) X-OriginalArrivalTime: 14 Jun 2008 08:24:33.0747 (UTC) FILETIME=[132EB230:01C8CDF8] X-Nokia-AV: Clean Cc: TSV Area , p2pi@ietf.org Subject: Re: [p2pi] discussing P2PI-related standardization in Dublin X-BeenThere: p2pi@ietf.org X-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 2008-6-14, at 3:16, ext Richard Bennett wrote: > Do we have a date for the proposed BOF in Dublin? Not yet. I've approved TANA (with work items 1 and 2 from the original email), but ALTO needs the approval of the ADs for the areas it was submitted to. > Lars Eggert wrote: >> (Note: this email is *not* an IESG approval of either the TANA or >> ALTO BOF - those will come from the responsible ADs if and when >> they come.) Lars _______________________________________________ p2pi mailing list p2pi@ietf.org https://www.ietf.org/mailman/listinfo/p2pi From p2pi-bounces@ietf.org Sat Jun 14 22:23: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 9B5E23A684E; Sat, 14 Jun 2008 22:23: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 EE3793A681E for ; Sat, 14 Jun 2008 22:23:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.284 X-Spam-Level: X-Spam-Status: No, score=-2.284 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, SARE_MILLIONSOF=0.315] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xLdT8QAenQDE for ; Sat, 14 Jun 2008 22:23:47 -0700 (PDT) Received: from netra.cs.yale.edu (netra.cs.yale.edu [128.36.229.21]) by core3.amsl.com (Postfix) with ESMTP id A74813A680F for ; Sat, 14 Jun 2008 22:23:46 -0700 (PDT) Received: from cyndra.cs.yale.edu (cyndra.cs.yale.edu [128.36.229.87]) by netra.cs.yale.edu (Postfix) with ESMTP id A517E409483; Sun, 15 Jun 2008 01:24:23 -0400 (EDT) Date: Sun, 15 Jun 2008 01:24:23 -0400 (EDT) From: "Y. R. Yang" To: p2pi@ietf.org Message-ID: MIME-Version: 1.0 Subject: Re: [p2pi] Refining the ALTO problem statement [Was: Re: discussing P2PI-related standardization in Dublin] X-BeenThere: p2pi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: P2P Infrastructure Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: p2pi-bounces@ietf.org Errors-To: p2pi-bounces@ietf.org Please see one pointer below. On Fri, 13 Jun 2008, 4:19pm -0400, Laird Popkin wrote: > Comments below. > > On Jun 13, 2008, at 9:01 AM, stefano previdi wrote: > > > Hi Laird, > > > > I understand your concern and let me try to answer from a routing > > implementation perspective. My thoughts are as follows: > > > > - the options of having a list of IP addresses to rank may be faced to > > some limitations but I probably have different view. I believe one > > alternative is to have a ranking of _pair_ of IP addresses (I > > believe there's a proposal made already on this direction). It > > doesn't address scalability per se but it allows other form of > > oracle/proximity capability. > > > > - From a routing algorithm perspective (and its implementation). The > > localization of 10 Vs. 1000 addresses may not incur an exponential > > complexity. I fact, routing algorithms/implementations are faced to > > this problem for years now... ;-) In the last years a lot of work > > has been done in the routing layer in order to improve performance > > and to minimize the impact of routing computations. We are now > > leveraging all this work in order to address other type of routing > > paradigms (using the same input). > > > > - State can be kept even if it results from different computations. > > This allows an "oracle/proximity" provider to minimize the amount of > > computation and to be able do deliver results on-the-fly. > > I'm not concerned about the computational cost of figuring out which > peers to connect to which - we do that now in our Trackers, and with > enough pre-computation it's remarkably fast, though of course not quite > as fast as picking random numbers from a list. But we don't mind a > little CPU overhead if it generates performance and efficiency. :-) > > The main concern that I have is that I can't take an extremely high > volume, fast, in-memory operation and turn it into a blocking external > message, because that makes my system orders of magnitude slower and > more fragile. > > The issue isn't the algorithm, it's where we draw the "line" through the > system where data crosses the wire. If the high-volume interactions > (mapping IP's to network locations, finding nearby locations, and > returning a sorted list of nearby IP's) can be done in memory, and only > periodic map updates are done over the wire, that's more efficient then > if the high-volume interactions all have to cross the wire. > > Now perhaps we can find a way to have "sorting lists of IP's" work > really well. As far as the ALTO BOF goes, I just don't want us to assume > that approach, because I tried it last year and hit a wall, and I don't > want us to collectively hit that wall without at least knowing that > there's a wall in the vicinity. Laird pointed out exactly the reason that we moved the computation from ISPs to applications. For example, in our original P4P overview article (http://www.dcia.info/documents/P4P_Overview.pdf section 3.1), the intelligtence was at the ISPs. In the current version (http://cs-www.cs.yale.edu/homes/yry/projects/p4p/p4p-sigcomm08.pdf), to be more scalable, extensible and application agonostic (see the beginning of Section 4 for a list of requirements), we moved application decisions to applications, where they should be. I can envision that both are possible but we prefer the current approach after our implementation effort last year. Sorting a list of IP addresses is a special case allowed by P4P but has its problems (please see ISP Use Cases and P2P Use Cases at page 4). Richard > > - There are apps models that have some form of hierarchy (e.g: > > trackers) and some others not. Should we have different models in > > the oracle too, or should we try to be as much as possible > > transparent/agnostic ? I'd vote for the latter. > > This is a very good question. In principle I agree that a single, more > 'generic' solution would be better. But the communication patterns for > tracker-based and trackerless p2p networks are quite different, and the > scaling requirements are so extreme, that it's not clear to me what a > single approach can work well for both. But that's what the ALTO > discussions will help explore. > > For a tracker-based system, my instinct is that a "map-based" approach > is more efficient, because there are a small number of Trackers and they > have plenty of resources to keep a map in memory. For a trackerless > system, my instinct is that a "sort IP list" approach might be more > appropriate, since each peer only knows about a small piece of the swarm > (so the lists aren't too big) and it seems inefficient to send a complex > "map" to millions of peers. > > > - I can't speak much about the legal/psychological issue (disclosing > > p2p addresses to SP) as I come from bottom layers, but what I can > > say is that, technically, the SP doesn't need any form of oracle in > > order to understand who among his customers is a p2p addicted... ;-) > > I am sure that's true - uplink utilization probably correlates pretty > well with p2p application usage. But if the p2p network sent IP lists > for every swarm to the oracle, that means that the ISP would know > exactly who was in each swarm for each unique piece of content in the > swarm, and which p2p network that piece of content was in, and (to some > degree) what the content is. This is broadcasting a level of detail > around user behavior that is, to be frank, a little unsettling. > > > - In one point we're in violent agreement: This is a great discussion. > > Yep. I am enjoying this quite a bit. > > > > Thanks. > > > > s. > > > > > >> From: Laird Popkin > >> > >> This is a great discussion. > >> > >> One point I'll make related to the signaling protocol for querying > >> the > >> "oracle" is that while the "send in a list of peer IP addresses and > >> receive a > >> sorted list back" approach is appealing in its simplicity, it has > >> some serious > >> limitations that would need to be taken into account. > >> > >> It's important to keep in mind that optimizing peer selection for p2p > >> transfers has the most impact for large swarms. That is, if there > >> are only 20 > >> people on the planet that can serve you data, (1) it doesn't take > >> too long to > >> connect to all of them so optimized peer selection doesn't save > >> much peer > >> connection time, and (2) the odds of any of them being in the same > >> ISP is > >> fairly low, so optimized peer selection doesn't affect data flow > >> much. > >> Optimizing peer selection is focused on swarms with very large > >> numbers of > >> peers. For example, we often see swarms with thousands or tens of > >> thousands of > >> peers. These are a small percentage of swarms, of course, but they > >> are > >> responsible for a disproportionately large volume of data. For > >> example, when > >> Yale surveyed "major tracker sites" they saw that a very small > >> percentage of > >> swarms had 100+ peers, but that those swarms were responsible for > >> well over > >> 50% of downloads. For perspective, at Pando, we see swarms with > >> thousands to > >> tens of thousands of peers fairly often. > >> > >> It is for these large sarms where the "list of IPs" approach runs > >> into some > >> pragmatic issues: > >> - The "oracle" must be sent the current complete set of IPs in each > >> swarm. > >> This means that the queries would be very large (e.g. a list of > >> 1,000 IP > >> addresses). This is not very cacheable, because swarm composition > >> is highly > >> dynamic. And it has to be a complete list, or the value of the > >> guidance > >> degrades dramatically. (Conceivable this could be implemented as > >> 'delta' > >> updates, but that raises oracle state issues, makes the software > >> and protocol > >> much more complex, etc.). > >> > >> - The "oracle" would have to maintain state (or recompute on every > >> query) for > >> every swarm in every p2p network. > >> - The volume of queries would be very large (perhaps on the order > >> of 100K > >> queries per second, across all p2p networks operating within an ISP). > >> - The queries cannot be cached (because the first announce is the > >> most > >> important to optimize, and following queries need to include all > >> new peers, > >> and each query generates a response unique to the peer being > >> provided the > >> guidance). > >> - The ISP would need to scale the "oracle" capacity to satisfy this > >> volume. > >> - It exposes the entire membership and data flow of the p2p network > >> to the > >> ISPs, which raises obvious legal and privacy issues. Imagine asking > >> your > >> lawyers whether they want to run Pirate's Bay's Trackers. > >> - It makes every Tracker announce slow, expensive and unreliable > >> instead of > >> fast, cheap and reliable. > >> > >> This is why we shifted (in the P4P approach) away from the more > >> obvious IP > >> list approach to moving the guidance into the Tracker's memory. > >> Admittedly > >> that does require ISPs to expose some abstract guidance information > >> (IP > >> prefixes and percentages), but in return: > >> - The communication from the "oracle" to the p2p network is a single > >> asynchronous update (e.g. as little as one message every hour) > >> instead of one > >> message per peer announce per swarm. > >> - The p2p network's Tracker can process peer requests in-memory, > >> without > >> having to make a blocking network call to an external "oracle". > >> This is > >> several orders of magnitude faster, more reliable, and far less > >> resource > >> intensive. > >> - There's minimal information exposed between the ISP and the P2P > >> network > >> (which is, from a legal and privacy angle, better for both P2P and > >> ISP). > >> > >> - Laird Popkin, CTO, Pando Networks > >> mobile: 646/465-0570 > >> > >> ----- Original Message ----- > >> From: "stefano previdi" > >> To: "Enrico Marocco" , p2pi@ietf.org > >> Sent: Friday, June 13, 2008 4:52:29 AM (GMT-0500) America/New_York > >> Subject: Re: [p2pi] Refining the ALTO problem statement [Was: Re: > >> discussing > >> P2PI-related standardization in Dublin] > >> > >> Enrico, > >> > >> I mostly agree mostly with everything below. My suggestion (as a > >> routing guy > >> more than an apps guy) is also to scope what could be extended/ > >> enhanced in > >> routing protocols in order to improve localization mechanisms > >> (whatever they > >> are). > >> > >> As an example, we have extended ISIS routing protocol in order to > >> carry some > >> application related information (at this stage is an empty > >> container) and > >> probably these kind of enhancements may have a use in localization/ > >> oracle > >> services. > >> > >> s. > >> > >> > >>> From: Enrico Marocco > >>> > >>> Peterson, Jon wrote: > >>>> The proposal for the ALTO BoF (which roughly covers (3)) is now > >>>> in the > >>>> BoF tracker. You can read about it at its home page: > >>>> > >>>> http://alto.tilab.com/ > >>> [...] > >>>> we hope that discussions surrounding the BoF could elucidate the > >>>> proper > >>>> division of labor and approach to this problem. > >>> > >>> To follow up on Jon's thoughts and to reflect discussions that > >>> happened > >>> during the MIT workshop and on the mailing list, Vijay and I are > >>> going > >>> to update the problem statement draft the ALTO BoF proposal is > >>> based on > >>> (draft-marocco-alto-problem-statement-00). > >>> > >>> As a prelude to focus the ALTO BoF, it would be great to start > >>> coalescing community agreement on ensuring that the scope of the > >>> problem > >>> is well defined and understood. > >>> > >>> Essentially, the problem that ALTO will attempt to solve is this: > >>> applications (P2P and otherwise) that make intensive use of the > >>> network > >>> bandwidth or want to make decisions to optimize some function (see > >>> use > >>> cases) may be interested in choosing all or some of their peers > >>> based on > >>> recommendations provided by some network entity -- colloquially > >>> called > >>> an oracle -- that has more of a global view on the peers in the > >>> network, > >>> their topological distances, and their capabilities than the > >>> application > >>> itself does. > >>> > >>> In thinking about the problem, it may help to consider the > >>> following: > >>> > >>> + Use cases: current version of the draft identifies four use > >>> cases for > >>> ALTO solutions (file-sharing, VoIP, p2p streaming and DHTs) but > >>> others > >>> come to mind (e.g. cache/http-mirror selection, CDN). At the MIT > >>> workshop, Ted Hardie coined the term "unattended consequences" of > >>> peer-to-peer nodes where traffic runs constantly for as long as the > >>> resources to that node are popular. Video feeds to remote stations > >>> were identified as a category. > >>> > >>> + Third-party services: even if topology information is directly > >>> available to network operators, nothing should prevent third- > >>> parties > >>> to provide peer selection services alternatively to or in > >>> competition > >>> with ISPs. An incomplete list of proposed solutions for providing > >>> such services is online at http://alto.tilab.com/resources.html; > >>> > >>> + Type(s) of information that are likely provided by the oracle > >>> (note > >>> that a third-party oracle may not have access to some of this > >>> information): > >>> * Given a list of peer candidate IP addresses, sort them > >>> according to > >>> preferences (topological proximity, bandwidth constraints, > >>> etc.) and > >>> return to querying application; > >>> * Ability for an application to determine its network location and > >>> proximity to other nodes; > >>> * Support for cost and charging information for application so that > >>> applications can make appropriate trade-offs; > >>> * Capabilities and characteristics of peers (i.e., last hop > >>> bandwidth, > >>> etc.); > >>> * Network policies; > >>> * ... > >>> > >>> + Type(s) of information that is provided to the oracle for > >>> rendering an > >>> equitable decision: > >>> * List of peer candidate IP addresses; > >>> * Parameter to optimize (cost, delay, ...); > >>> * ... > >>> > >>> This is mainly what we have captured so far; however, feedback, > >>> suggestions and contributions are not only welcome, but at this time > >>> even required for the successful setting of a BOF. > >>> > >>> Besides, the draft currently identifies two elements for which > >>> standardization work would be required, namely a discovery > >>> mechanisms > >>> for locating oracles and a signaling protocol for querying them. Do > >>> people think the core solution for ALTO should include anything > >>> else? > >>> > >>> -- > >>> Ciao, > >>> Enrico > >>> _______________________________________________ > >>> p2pi mailing list > >>> p2pi@ietf.org > >>> https://www.ietf.org/mailman/listinfo/p2pi > >> > >> > >> _______________________________________________ > >> p2pi mailing list > >> p2pi@ietf.org > >> https://www.ietf.org/mailman/listinfo/p2pi > > > > > > _______________________________________________ > p2pi mailing list > p2pi@ietf.org > https://www.ietf.org/mailman/listinfo/p2pi > _______________________________________________ p2pi mailing list p2pi@ietf.org https://www.ietf.org/mailman/listinfo/p2pi From p2pi-bounces@ietf.org Mon Jun 16 00:20:45 2008 Return-Path: X-Original-To: p2pi-archive@ietf.org Delivered-To: ietfarch-p2pi-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1063728C10C; Mon, 16 Jun 2008 00:20:45 -0700 (PDT) X-Original-To: p2pi@core3.amsl.com Delivered-To: p2pi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3A55528C10B for ; Mon, 16 Jun 2008 00:20:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.192 X-Spam-Level: X-Spam-Status: No, score=-6.192 tagged_above=-999 required=5 tests=[AWL=0.057, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lawQLekeN7kX for ; Mon, 16 Jun 2008 00:20:43 -0700 (PDT) Received: from mx2.nic.fr (mx2.nic.fr [192.134.4.11]) by core3.amsl.com (Postfix) with ESMTP id 1BCDA28C10A for ; Mon, 16 Jun 2008 00:20:43 -0700 (PDT) Received: from mx2.nic.fr (localhost [127.0.0.1]) by mx2.nic.fr (Postfix) with SMTP id 29B3E1C0127; Mon, 16 Jun 2008 09:21:21 +0200 (CEST) Received: from relay2.nic.fr (relay2.nic.fr [192.134.4.163]) by mx2.nic.fr (Postfix) with ESMTP id 247501C0122; Mon, 16 Jun 2008 09:21:21 +0200 (CEST) Received: from bortzmeyer.nic.fr (batilda.nic.fr [192.134.4.69]) by relay2.nic.fr (Postfix) with ESMTP id 1852C58ECBF; Mon, 16 Jun 2008 09:21:21 +0200 (CEST) Date: Mon, 16 Jun 2008 09:21:21 +0200 From: Stephane Bortzmeyer To: "Vijay K. Gurbani" Message-ID: <20080616072121.GA15513@nic.fr> References: <565621476.393261213359293462.JavaMail.root@dkny.pando.com> <4852862D.9030202@telecomitalia.it> <20080613151246.GA20314@nic.fr> <485290D5.1010909@alcatel-lucent.com> <20080613152850.GA25521@nic.fr> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20080613152850.GA25521@nic.fr> X-Operating-System: Debian GNU/Linux lenny/sid X-Kernel: Linux 2.6.24-1-686 i686 Organization: NIC France X-URL: http://www.nic.fr/ User-Agent: Mutt/1.5.18 (2008-05-17) Cc: p2pi@ietf.org Subject: Re: [p2pi] Refining the ALTO problem statement [Was: Re: discussing P2PI-related standardization in Dublin] X-BeenThere: p2pi@ietf.org X-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 > > http://idisk.mac.com/cullenfluffyjennings-Public?view=web > > Required Browsers And I'm not the only one having problems with this broken Web site: http://blogs.voxeo.com/speakingofstandards/2008/05/20/ietf-p2p-workshop-agenda-and-papers-now-available/ _______________________________________________ p2pi mailing list p2pi@ietf.org https://www.ietf.org/mailman/listinfo/p2pi From p2pi-bounces@ietf.org Mon Jun 16 01:41:34 2008 Return-Path: X-Original-To: p2pi-archive@ietf.org Delivered-To: ietfarch-p2pi-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ACEC83A685C; Mon, 16 Jun 2008 01:41:34 -0700 (PDT) X-Original-To: p2pi@core3.amsl.com Delivered-To: p2pi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5D3C23A685C for ; Mon, 16 Jun 2008 01:41:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.49 X-Spam-Level: X-Spam-Status: No, score=-6.49 tagged_above=-999 required=5 tests=[AWL=0.109, 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 YWIaidv1Ekks for ; Mon, 16 Jun 2008 01:41:28 -0700 (PDT) Received: from mgw-mx03.nokia.com (smtp.nokia.com [192.100.122.230]) by core3.amsl.com (Postfix) with ESMTP id 6C9B23A683B for ; Mon, 16 Jun 2008 01:41:28 -0700 (PDT) Received: from vaebh105.NOE.Nokia.com (vaebh105.europe.nokia.com [10.160.244.31]) by mgw-mx03.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id m5G8fhpx031806; Mon, 16 Jun 2008 11:42:03 +0300 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by vaebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 16 Jun 2008 11:42:03 +0300 Received: from net-82.nrpn.net ([10.241.184.208]) by esebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Mon, 16 Jun 2008 11:42:02 +0300 Message-Id: <3083CE1C-A219-4DB6-BAEC-E74DC3FD9C46@nokia.com> From: Lars Eggert To: ext Enrico Marocco In-Reply-To: <48541F91.1010306@telecomitalia.it> Mime-Version: 1.0 (Apple Message framework v924) Date: Mon, 16 Jun 2008 11:41:58 +0300 References: <22F6A875-B548-4C65-AB68-B88E526CCA33@nokia.com> <6E1603B0-7116-45F9-A510-DC5F9040298B@nokia.com> <48516BE2.2080901@telecomitalia.it> <48541F91.1010306@telecomitalia.it> X-Mailer: Apple Mail (2.924) X-OriginalArrivalTime: 16 Jun 2008 08:42:03.0210 (UTC) FILETIME=[D9898AA0:01C8CF8C] X-Nokia-AV: Clean Cc: "p2pi@ietf.org" Subject: Re: [p2pi] Refining the ALTO problem statement [Was: Re: discussing P2PI-related standardization in Dublin] X-BeenThere: p2pi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: P2P Infrastructure Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="windows-1252" Content-Transfer-Encoding: quoted-printable Sender: p2pi-bounces@ietf.org Errors-To: p2pi-bounces@ietf.org Hi, On 2008-6-14, at 22:44, ext Enrico Marocco wrote: >>> * Support for cost and charging information for application so that >>> applications can make appropriate trade-offs; >> Can you be a bit more explicit about whose costs this is about? Who = >> is >> paying whom, on what timescales and based on what resources? > > Sure. This was one bullet point that was made in Prof. = > Schulzrinne's paper. I quote the text from the paper: > > Cost-of-bandwidth information > > Relying on cooperative applications to be =93nice=94 is probably > insufficient unless there is an incentive. There are at least three > possibilities, namely either volume limiting, rate limiting or > volume-based charging. For example, a network could offer a tiered > tariff that allows unlimited bandwidth within the same AS, 100 kb/s > rate-limited but unlimited prioritized DiffServ to anywhere and > volume-limited bulk traffic to any AS. There are several ways to > convey this information to applications, allowing them to make > appropriate trade-offs. For example, a network could provide an > information service with a list of service descriptors, similar to > the RSVP TSpec. Alternatively, a protocol such as GIST could = > discover > the cost of particular destination. The service classes may change > over time. For example, a network may offer "midnight specials" when > the network is idle during off-hours, encouraging bulk downloads > during that time. thanks - that does make it clearer. I agree that it's interesting to = think through the possibilities here, but I don't see anything we = could immediately think about standardizing here. > > Also, why would an = > oracle >> know anything about the capabilities or characteristics of the peers? >> Are the peers supposed to register with the oracle? That goes far >> beyond what I thought this BOF was about. > > No, we are not suggesting that peers register with the oracle. This = > is more along the point of trying to generate some discussion. What = > if a peer is willing to publish its capabilities, either for other = > peers or for an oracle. It's more natural IMO for peers to advertise their capabilities to = each other as part of the P2P protocol, rather than going through the = oracle. As for peers wanting to advertise capabilities to the oracle, sure, = that's a possibility. > Is this something that is worth considering, if not for a = > standardization aspect, at least as a research problem? Definitely interesting from a research perspective, but not ready for = standardization IMO. >> Why is it useful to query the oracle for delay? An app can get a >> relatively accurate and more importantly timely RTT sample by sending >> a few packets to a peer. That practice causes no issues for = >> operators, >> since the traffic volume is so low. > > Well, the use case I had in mind here was the selection of media = > relays in real-time communication systems, when the list of = > candidate peers may have hundreds or thousands of elements (think of = > Skype). In such a case, provided the oracle can elaborate lists and = > not on single instances only, a one query would replace tons of RTT = > measurements. I think I remember reading some papers on choosing the best option out = of a small number of random candidate peers will result in a choice = that is reasonably good. (Obviously you wouldn't want to probe all the = candidates.) So the potential for savings is not large. In order for = the oracle to have a reasonably good view of delays between peers, I'd = need to perform a similar amount of probing, or it needs to arrange = peers in some virtual coordinate system and hope that that's accurate = enough. > On a side note, is it possible for RTT to be small on a high latency = > link one hop away when compared to a slightly higher RTT on low = > latency links six hops away? I think you mean transmission time when you say latency (RTT *is* = latency in both ways). > That is, the time it takes for a peer to download a large content = > from the peer with the lower RTT is actually higher than the time it = > takes to do the same from the peer with higher RTT. That is definitely possible. For example, low-RTT peers may be behind = other DSL boxes within your ISP, whereas the university with the big = pipe is a bit further away in RTT terms than those peers - who'd you = like to transfer from? I'd expect the correlation between RTT and = transmission time to be pretty weak (but have no data to back this up.) Lars _______________________________________________ p2pi mailing list p2pi@ietf.org https://www.ietf.org/mailman/listinfo/p2pi From p2pi-bounces@ietf.org Mon Jun 16 02:11: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 C3F283A68E3; Mon, 16 Jun 2008 02:11: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 559A63A6841 for ; Mon, 16 Jun 2008 02:11:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.492 X-Spam-Level: X-Spam-Status: No, score=-6.492 tagged_above=-999 required=5 tests=[AWL=0.107, 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 mb4CgDiWLMO3 for ; Mon, 16 Jun 2008 02:11:18 -0700 (PDT) Received: from mgw-mx06.nokia.com (smtp.nokia.com [192.100.122.233]) by core3.amsl.com (Postfix) with ESMTP id E1C6B3A68E3 for ; Mon, 16 Jun 2008 02:11:17 -0700 (PDT) Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-mx06.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id m5G9BbJX018311; Mon, 16 Jun 2008 12:11:54 +0300 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 16 Jun 2008 12:11:51 +0300 Received: from net-82.nrpn.net ([10.241.184.208]) by esebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Mon, 16 Jun 2008 12:11:50 +0300 Message-Id: <7335188A-BA0A-48E6-9D6B-9E4F6F09A4C6@nokia.com> From: Lars Eggert To: ext John Leslie In-Reply-To: <20080613225727.GC3759@verdi> Mime-Version: 1.0 (Apple Message framework v924) Date: Mon, 16 Jun 2008 12:11:45 +0300 References: <22F6A875-B548-4C65-AB68-B88E526CCA33@nokia.com> <6E1603B0-7116-45F9-A510-DC5F9040298B@nokia.com> <48516BE2.2080901@telecomitalia.it> <20080613225727.GC3759@verdi> X-Mailer: Apple Mail (2.924) X-OriginalArrivalTime: 16 Jun 2008 09:11:51.0187 (UTC) FILETIME=[03412E30:01C8CF91] X-Nokia-AV: Clean Cc: p2pi@ietf.org Subject: Re: [p2pi] Refining the ALTO problem statement X-BeenThere: p2pi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: P2P Infrastructure Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: p2pi-bounces@ietf.org Errors-To: p2pi-bounces@ietf.org Hi, On 2008-6-14, at 1:57, ext John Leslie wrote: > Lars Eggert wrote: >> The high level bit is that I believe that although it will be >> possible >> to provide information that changes on relatively large timescales >> (such as information about topological proximity), it will be both >> very difficult and potentially problematic to share performance- >> related information that changes on short timescales in the same >> fashion. > > That's an implementation issue. > We should do protocol design before we do implementation. > Besides, it's only a couple orders of magnitude "difficult." It > might > be quite practical five years from now. I think we're talking about two different things. I understood the proposal for the oracle to maintain performance-related information to be for actual, current load of a path (modulo quantization effects and communication latency). That has all sorts of timing- and accuracy- related issues. If I understand your email correctly (based on the quoted section below), you see the oracle as maintaining more coarse-grained, statistical load data about paths. Things like "this path is half idle on Saturday night." I agree that that information would be easier to provide. But I question whether such load data can be useful to applications (see below). > The application isn't particularly interested in one instantaneous > snapshot: it's interested in what's likely to be the case over an > extended period (or how long it is likely to take to transfer a known > amount of data. Statistical summaries are much more useful: and the > oracle is in a good position to provide those. Assuming for a moment we had an oracle that had such information, the only benefit to apps would be to not even try to establish connections to peers that had a projected low throughput. That's a minor optimization at best. Many P2P systems will drop that peer after a short time anyway. (And if the aggregate traffic to such peers would conflict with ISP interests, they'd rank the peer low in the oracle because of that anyway, independent of traffic statistics) >> So this information is unlikely to be useful to an app; >> and I can even construct cases where using this stale information >> leads to traffic oscillations, which is problematic. > > Traffic oscillations are indeed problematic. But can you construct > a case where statistical damping isn't sufficient to guard against > that? Who would dampen what? The apps are just using information provided by the oracle and see no oscillations. The oracle could observe that traffic shifts, but how does it differentiate if that is due to the information it provides or whether it is independent of that? And even if it could, what does it then do? Longer statistical aggregation decreases the frequency of oscillations, but also means that the load data will be even less indicative of current loads. >> I'm MUCH less convinced of the usefulness of the shopping list of >> things in the following bullets. For a lot of the things below, it's >> unclear to me why an application would want them and where an oracle >> would get them from. I don't think they should be part of any >> standardization effort at this time. > > We should be standardizing a protocol, not an implementation. Agreed, but spending cycles defining a protocol to exchange information that an oracle has no chance of gathering or that we aren't really sure what an app would do with isn't very practical. >>> * Support for cost and charging information for application so that >>> applications can make appropriate trade-offs; > > Clearly, applications have every reason to consider cost/charging > information provided by the supplier the user will have to pay. Agreed; *if* the charging isn't a flat fee. >> The bandwidth example is IMO again problematic (and it's not a peer >> characteristic, it's a path characteristic.) Also, why would an >> oracle >> know anything about the capabilities or characteristics of the peers? >> Are the peers supposed to register with the oracle? That goes far >> beyond what I thought this BOF was about. > > The peer might impose its own limits, beyond the limits of the path. > It might (or might not) be appropriate to standardize a way of > advertising these. See my email to Enrico; IMO such advertisements between peers should be handled inside a specific P2P protocol rather than by a protocol- agnostic oracle. > Because instantaneous delay isn't a good measure. An oracle will be > in a better position to know minimum latency, plus normal range for > minimal congestion. Clarification: When you say "delay", it sounds you mean "projected transmission time"? Because I think Enrico actually meant RTT. (See my email to him on why I don't think RTTs are useful for an oracle to maintain.) Lars _______________________________________________ p2pi mailing list p2pi@ietf.org https://www.ietf.org/mailman/listinfo/p2pi From p2pi-bounces@ietf.org Mon Jun 16 02:22: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 E113E3A68D8; Mon, 16 Jun 2008 02:22: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 3F0AF3A68D8 for ; Mon, 16 Jun 2008 02:22:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.417 X-Spam-Level: X-Spam-Status: No, score=-2.417 tagged_above=-999 required=5 tests=[AWL=-0.133, BAYES_00=-2.599, SARE_MILLIONSOF=0.315] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uOLbvyLs8Z9D for ; Mon, 16 Jun 2008 02:22:07 -0700 (PDT) Received: from av-tac-bru.cisco.com (odd-brew.cisco.com [144.254.15.119]) by core3.amsl.com (Postfix) with ESMTP id E1CB43A683B for ; Mon, 16 Jun 2008 02:22:06 -0700 (PDT) X-TACSUNS: Virus Scanned Received: from strange-brew.cisco.com (localhost [127.0.0.1]) by av-tac-bru.cisco.com (8.11.7p3+Sun/8.11.7) with ESMTP id m5G9Mkm15443; Mon, 16 Jun 2008 11:22:46 +0200 (CEST) Received: from [144.254.189.78] (dhcp-rom2-144-254-189-78.cisco.com [144.254.189.78]) by strange-brew.cisco.com (8.11.7p3+Sun/8.11.7) with ESMTP id m5G9MjA10452; Mon, 16 Jun 2008 11:22:46 +0200 (CEST) User-Agent: Microsoft-Entourage/11.4.0.080122 Date: Mon, 16 Jun 2008 11:22:21 +0200 From: stefano previdi To: Laird Popkin Message-ID: Thread-Topic: [p2pi] Refining the ALTO problem statement [Was: Re: discussing P2PI-related standardization in Dublin] Thread-Index: AcjPknqnuWunDDuFEd2n6gAX8vOM8g== In-Reply-To: <1101C5F1-9CDC-4E20-90FA-1F0CEE0547BC@pando.com> Mime-version: 1.0 Cc: p2pi@ietf.org Subject: Re: [p2pi] Refining the ALTO problem statement [Was: Re: discussing P2PI-related standardization in Dublin] X-BeenThere: p2pi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: P2P Infrastructure Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: p2pi-bounces@ietf.org Errors-To: p2pi-bounces@ietf.org > From: Laird Popkin > > Comments below. > > On Jun 13, 2008, at 9:01 AM, stefano previdi wrote: > >> Hi Laird, >> >> I understand your concern and let me try to answer from a routing >> implementation perspective. My thoughts are as follows: >> >> - the options of having a list of IP addresses to rank may be faced >> to some >> limitations but I probably have different view. I believe one >> alternative is >> to have a ranking of _pair_ of IP addresses (I believe there's a >> proposal >> made already on this direction). It doesn't address scalability per >> se but >> it allows other form of oracle/proximity capability. >> >> - From a routing algorithm perspective (and its implementation). The >> localization of 10 Vs. 1000 addresses may not incur an exponential >> complexity. I fact, routing algorithms/implementations are faced to >> this >> problem for years now... ;-) In the last years a lot of work has >> been done >> in the routing layer in order to improve performance and to minimize >> the >> impact of routing computations. We are now leveraging all this work >> in order >> to address other type of routing paradigms (using the same input). >> >> - State can be kept even if it results from different computations. >> This >> allows an "oracle/proximity" provider to minimize the amount of >> computation >> and to be able do deliver results on-the-fly. > > I'm not concerned about the computational cost of figuring out which > peers to connect to which - we do that now in our Trackers, and with > enough pre-computation it's remarkably fast, though of course not > quite as fast as picking random numbers from a list. But we don't mind > a little CPU overhead if it generates performance and efficiency. :-) indeed... I believe (from an implementation standpoint) it shouldn't cost more than a simple RIB lookup... but we're probably diverging from our purpose here... ;-) > The main concern that I have is that I can't take an extremely high > volume, fast, in-memory operation and turn it into a blocking external > message, because that makes my system orders of magnitude slower and > more fragile. > > The issue isn't the algorithm, it's where we draw the "line" through > the system where data crosses the wire. If the high-volume > interactions (mapping IP's to network locations, finding nearby > locations, and returning a sorted list of nearby IP's) can be done in > memory, and only periodic map updates are done over the wire, that's > more efficient then if the high-volume interactions all have to cross > the wire. > > Now perhaps we can find a way to have "sorting lists of IP's" work > really well. As far as the ALTO BOF goes, I just don't want us to > assume that approach, because I tried it last year and hit a wall, and > I don't want us to collectively hit that wall without at least knowing > that there's a wall in the vicinity. I tend to agree. But what's missing (at least to me) is a set of requirements. Having a time issue is possible only if you quantifies your time budged... My kids will tolerate an extra second or two prior to start their download, but in other contexts it may be less evident. >> - There are apps models that have some form of hierarchy (e.g: >> trackers) and >> some others not. Should we have different models in the oracle too, or >> should we try to be as much as possible transparent/agnostic ? I'd >> vote for >> the latter. > > This is a very good question. In principle I agree that a single, more > 'generic' solution would be better. But the communication patterns for > tracker-based and trackerless p2p networks are quite different, and > the scaling requirements are so extreme, that it's not clear to me > what a single approach can work well for both. But that's what the > ALTO discussions will help explore. I agree. > For a tracker-based system, my instinct is that a "map-based" approach > is more efficient, because there are a small number of Trackers and > they have plenty of resources to keep a map in memory. For a > trackerless system, my instinct is that a "sort IP list" approach > might be more appropriate, since each peer only knows about a small > piece of the swarm (so the lists aren't too big) and it seems > inefficient to send a complex "map" to millions of peers. > >> - I can't speak much about the legal/psychological issue (disclosing >> p2p >> addresses to SP) as I come from bottom layers, but what I can say is >> that, >> technically, the SP doesn't need any form of oracle in order to >> understand >> who among his customers is a p2p addicted... ;-) > > I am sure that's true - uplink utilization probably correlates pretty > well with p2p application usage. But if the p2p network sent IP lists > for every swarm to the oracle, that means that the ISP would know > exactly who was in each swarm for each unique piece of content in the > swarm, and which p2p network that piece of content was in, and (to > some degree) what the content is. This is broadcasting a level of > detail around user behavior that is, to be frank, a little unsettling. Bu this implies the client to communicate (in addition to peers list) also the piece of content related to the swarm. Isn't just the case of an embedded localization component inside an application-specific tracker ? thanks. s. > >> - In one point we're in violent agreement: This is a great discussion. > > Yep. I am enjoying this quite a bit. > > >> Thanks. >> >> s. >> >> >>> From: Laird Popkin >>> >>> This is a great discussion. >>> >>> One point I'll make related to the signaling protocol for querying >>> the >>> "oracle" is that while the "send in a list of peer IP addresses and >>> receive a >>> sorted list back" approach is appealing in its simplicity, it has >>> some serious >>> limitations that would need to be taken into account. >>> >>> It's important to keep in mind that optimizing peer selection for p2p >>> transfers has the most impact for large swarms. That is, if there >>> are only 20 >>> people on the planet that can serve you data, (1) it doesn't take >>> too long to >>> connect to all of them so optimized peer selection doesn't save >>> much peer >>> connection time, and (2) the odds of any of them being in the same >>> ISP is >>> fairly low, so optimized peer selection doesn't affect data flow >>> much. >>> Optimizing peer selection is focused on swarms with very large >>> numbers of >>> peers. For example, we often see swarms with thousands or tens of >>> thousands of >>> peers. These are a small percentage of swarms, of course, but they >>> are >>> responsible for a disproportionately large volume of data. For >>> example, when >>> Yale surveyed "major tracker sites" they saw that a very small >>> percentage of >>> swarms had 100+ peers, but that those swarms were responsible for >>> well over >>> 50% of downloads. For perspective, at Pando, we see swarms with >>> thousands to >>> tens of thousands of peers fairly often. >>> >>> It is for these large sarms where the "list of IPs" approach runs >>> into some >>> pragmatic issues: >>> - The "oracle" must be sent the current complete set of IPs in each >>> swarm. >>> This means that the queries would be very large (e.g. a list of >>> 1,000 IP >>> addresses). This is not very cacheable, because swarm composition >>> is highly >>> dynamic. And it has to be a complete list, or the value of the >>> guidance >>> degrades dramatically. (Conceivable this could be implemented as >>> 'delta' >>> updates, but that raises oracle state issues, makes the software >>> and protocol >>> much more complex, etc.). >>> >>> - The "oracle" would have to maintain state (or recompute on every >>> query) for >>> every swarm in every p2p network. >>> - The volume of queries would be very large (perhaps on the order >>> of 100K >>> queries per second, across all p2p networks operating within an ISP). >>> - The queries cannot be cached (because the first announce is the >>> most >>> important to optimize, and following queries need to include all >>> new peers, >>> and each query generates a response unique to the peer being >>> provided the >>> guidance). >>> - The ISP would need to scale the "oracle" capacity to satisfy this >>> volume. >>> - It exposes the entire membership and data flow of the p2p network >>> to the >>> ISPs, which raises obvious legal and privacy issues. Imagine asking >>> your >>> lawyers whether they want to run Pirate's Bay's Trackers. >>> - It makes every Tracker announce slow, expensive and unreliable >>> instead of >>> fast, cheap and reliable. >>> >>> This is why we shifted (in the P4P approach) away from the more >>> obvious IP >>> list approach to moving the guidance into the Tracker's memory. >>> Admittedly >>> that does require ISPs to expose some abstract guidance information >>> (IP >>> prefixes and percentages), but in return: >>> - The communication from the "oracle" to the p2p network is a single >>> asynchronous update (e.g. as little as one message every hour) >>> instead of one >>> message per peer announce per swarm. >>> - The p2p network's Tracker can process peer requests in-memory, >>> without >>> having to make a blocking network call to an external "oracle". >>> This is >>> several orders of magnitude faster, more reliable, and far less >>> resource >>> intensive. >>> - There's minimal information exposed between the ISP and the P2P >>> network >>> (which is, from a legal and privacy angle, better for both P2P and >>> ISP). >>> >>> - Laird Popkin, CTO, Pando Networks >>> mobile: 646/465-0570 >>> >>> ----- Original Message ----- >>> From: "stefano previdi" >>> To: "Enrico Marocco" , p2pi@ietf.org >>> Sent: Friday, June 13, 2008 4:52:29 AM (GMT-0500) America/New_York >>> Subject: Re: [p2pi] Refining the ALTO problem statement [Was: Re: >>> discussing >>> P2PI-related standardization in Dublin] >>> >>> Enrico, >>> >>> I mostly agree mostly with everything below. My suggestion (as a >>> routing guy >>> more than an apps guy) is also to scope what could be extended/ >>> enhanced in >>> routing protocols in order to improve localization mechanisms >>> (whatever they >>> are). >>> >>> As an example, we have extended ISIS routing protocol in order to >>> carry some >>> application related information (at this stage is an empty >>> container) and >>> probably these kind of enhancements may have a use in localization/ >>> oracle >>> services. >>> >>> s. >>> >>> >>>> From: Enrico Marocco >>>> >>>> Peterson, Jon wrote: >>>>> The proposal for the ALTO BoF (which roughly covers (3)) is now >>>>> in the >>>>> BoF tracker. You can read about it at its home page: >>>>> >>>>> http://alto.tilab.com/ >>>> [...] >>>>> we hope that discussions surrounding the BoF could elucidate the >>>>> proper >>>>> division of labor and approach to this problem. >>>> >>>> To follow up on Jon's thoughts and to reflect discussions that >>>> happened >>>> during the MIT workshop and on the mailing list, Vijay and I are >>>> going >>>> to update the problem statement draft the ALTO BoF proposal is >>>> based on >>>> (draft-marocco-alto-problem-statement-00). >>>> >>>> As a prelude to focus the ALTO BoF, it would be great to start >>>> coalescing community agreement on ensuring that the scope of the >>>> problem >>>> is well defined and understood. >>>> >>>> Essentially, the problem that ALTO will attempt to solve is this: >>>> applications (P2P and otherwise) that make intensive use of the >>>> network >>>> bandwidth or want to make decisions to optimize some function (see >>>> use >>>> cases) may be interested in choosing all or some of their peers >>>> based on >>>> recommendations provided by some network entity -- colloquially >>>> called >>>> an oracle -- that has more of a global view on the peers in the >>>> network, >>>> their topological distances, and their capabilities than the >>>> application >>>> itself does. >>>> >>>> In thinking about the problem, it may help to consider the >>>> following: >>>> >>>> + Use cases: current version of the draft identifies four use >>>> cases for >>>> ALTO solutions (file-sharing, VoIP, p2p streaming and DHTs) but >>>> others >>>> come to mind (e.g. cache/http-mirror selection, CDN). At the MIT >>>> workshop, Ted Hardie coined the term "unattended consequences" of >>>> peer-to-peer nodes where traffic runs constantly for as long as the >>>> resources to that node are popular. Video feeds to remote stations >>>> were identified as a category. >>>> >>>> + Third-party services: even if topology information is directly >>>> available to network operators, nothing should prevent third- >>>> parties >>>> to provide peer selection services alternatively to or in >>>> competition >>>> with ISPs. An incomplete list of proposed solutions for providing >>>> such services is online at http://alto.tilab.com/resources.html; >>>> >>>> + Type(s) of information that are likely provided by the oracle >>>> (note >>>> that a third-party oracle may not have access to some of this >>>> information): >>>> * Given a list of peer candidate IP addresses, sort them >>>> according to >>>> preferences (topological proximity, bandwidth constraints, >>>> etc.) and >>>> return to querying application; >>>> * Ability for an application to determine its network location and >>>> proximity to other nodes; >>>> * Support for cost and charging information for application so that >>>> applications can make appropriate trade-offs; >>>> * Capabilities and characteristics of peers (i.e., last hop >>>> bandwidth, >>>> etc.); >>>> * Network policies; >>>> * ... >>>> >>>> + Type(s) of information that is provided to the oracle for >>>> rendering an >>>> equitable decision: >>>> * List of peer candidate IP addresses; >>>> * Parameter to optimize (cost, delay, ...); >>>> * ... >>>> >>>> This is mainly what we have captured so far; however, feedback, >>>> suggestions and contributions are not only welcome, but at this time >>>> even required for the successful setting of a BOF. >>>> >>>> Besides, the draft currently identifies two elements for which >>>> standardization work would be required, namely a discovery >>>> mechanisms >>>> for locating oracles and a signaling protocol for querying them. Do >>>> people think the core solution for ALTO should include anything >>>> else? >>>> >>>> -- >>>> Ciao, >>>> Enrico >>>> _______________________________________________ >>>> p2pi mailing list >>>> p2pi@ietf.org >>>> https://www.ietf.org/mailman/listinfo/p2pi >>> >>> >>> _______________________________________________ >>> p2pi mailing list >>> p2pi@ietf.org >>> https://www.ietf.org/mailman/listinfo/p2pi >> >> _______________________________________________ p2pi mailing list p2pi@ietf.org https://www.ietf.org/mailman/listinfo/p2pi From p2pi-bounces@ietf.org Mon Jun 16 02:23:30 2008 Return-Path: X-Original-To: p2pi-archive@ietf.org Delivered-To: ietfarch-p2pi-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BDC503A68D8; Mon, 16 Jun 2008 02:23:30 -0700 (PDT) X-Original-To: p2pi@core3.amsl.com Delivered-To: p2pi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DA3703A6841 for ; Mon, 16 Jun 2008 02:23:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.548 X-Spam-Level: X-Spam-Status: No, score=-2.548 tagged_above=-999 required=5 tests=[AWL=0.052, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Lm1td-Ta922V for ; Mon, 16 Jun 2008 02:23:28 -0700 (PDT) Received: from av-tac-bru.cisco.com (odd-brew.cisco.com [144.254.15.119]) by core3.amsl.com (Postfix) with ESMTP id 451933A683B for ; Mon, 16 Jun 2008 02:23:28 -0700 (PDT) X-TACSUNS: Virus Scanned Received: from strange-brew.cisco.com (localhost [127.0.0.1]) by av-tac-bru.cisco.com (8.11.7p3+Sun/8.11.7) with ESMTP id m5G9O8O15512; Mon, 16 Jun 2008 11:24:08 +0200 (CEST) Received: from [144.254.189.78] (dhcp-rom2-144-254-189-78.cisco.com [144.254.189.78]) by strange-brew.cisco.com (8.11.7p3+Sun/8.11.7) with ESMTP id m5G9NnA13215; Mon, 16 Jun 2008 11:23:53 +0200 (CEST) User-Agent: Microsoft-Entourage/11.4.0.080122 Date: Mon, 16 Jun 2008 11:23:25 +0200 From: stefano previdi To: "Vijay K. Gurbani" Message-ID: Thread-Topic: [p2pi] Refining the ALTO problem statement [Was: Re: discussing P2PI-related standardization in Dublin] Thread-Index: AcjPkqDM351mSTuFEd2n6gAX8vOM8g== In-Reply-To: <48529822.2030101@alcatel-lucent.com> Mime-version: 1.0 Cc: "p2pi@ietf.org" Subject: Re: [p2pi] Refining the ALTO problem statement [Was: Re: discussing P2PI-related standardization in Dublin] X-BeenThere: p2pi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: P2P Infrastructure Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: p2pi-bounces@ietf.org Errors-To: p2pi-bounces@ietf.org > From: "Vijay K. Gurbani" > > stefano previdi wrote: >> Enrico, >> >> I mostly agree mostly with everything below. > > Stefano: Thank you. > >> My suggestion (as a routing guy more than an apps guy) is also to >> scope what could be extended/enhanced in routing protocols in order >> to improve localization mechanisms (whatever they are). > > I think the issue of scoping is something that we definitely > have to work on. > > I also suspect that ALTO solutions deployed by network operators > will probably make use of information carried in routing protocols > and, if it turns out that extensions to such protocols may be > beneficial, they should be specified in coordination with ALTO, but > probably in the Routing area. At the current time, the viewpoints > of the ADs appear to be that ALTO will be either in RAI or Apps. Well, I clearly won't start a debate here (on where to land the WG) ;-) As long as we have a good channel with the routing wg's it's ok to me. >> As an example, we have extended ISIS routing protocol in order to >> carry some application related information (at this stage is an empty >> container) and probably these kind of enhancements may have a use in >> localization/oracle services. > > It would be great if you could describe this in a draft. One of > the points we made in our workshop paper was the need for layer > cooperation. Your existing work would go a long way to provide > some illumination of feasibility in that area. ok. I'll try to come up with some documented ideas... thanks. s. > > Ciao. > > - vijay > -- > Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent > 2701 Lucent Lane, Rm. 9F-546, Lisle, Illinois 60532 (USA) > Email: vkg@{alcatel-lucent.com,bell-labs.com,acm.org} > WWW: http://www.alcatel-lucent.com/bell-labs _______________________________________________ p2pi mailing list p2pi@ietf.org https://www.ietf.org/mailman/listinfo/p2pi From p2pi-bounces@ietf.org Mon Jun 16 06:29:36 2008 Return-Path: X-Original-To: p2pi-archive@ietf.org Delivered-To: ietfarch-p2pi-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E8CB53A6879; Mon, 16 Jun 2008 06:29:36 -0700 (PDT) X-Original-To: p2pi@core3.amsl.com Delivered-To: p2pi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 51EE73A6879 for ; Mon, 16 Jun 2008 06:29:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.361 X-Spam-Level: X-Spam-Status: No, score=-2.361 tagged_above=-999 required=5 tests=[AWL=0.237, BAYES_00=-2.599, STOX_REPLY_TYPE=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 LshptXW22yx4 for ; Mon, 16 Jun 2008 06:29:34 -0700 (PDT) Received: from mout.perfora.net (mout.perfora.net [74.208.4.195]) by core3.amsl.com (Postfix) with ESMTP id 5DEDE3A684C for ; Mon, 16 Jun 2008 06:29:34 -0700 (PDT) Received: from s73602 (cpe-72-190-0-23.tx.res.rr.com [72.190.0.23]) by mrelay.perfora.net (node=mrus0) with ESMTP (Nemesis) id 0MKp8S-1K8Emh1mb8-00042E; Mon, 16 Jun 2008 09:30:12 -0400 Message-ID: <00b601c8cfb5$3aa68180$6401a8c0@china.huawei.com> From: "Spencer Dawkins" To: References: <22F6A875-B548-4C65-AB68-B88E526CCA33@nokia.com><6E1603B0-7116-45F9-A510-DC5F9040298B@nokia.com><48516BE2.2080901@telecomitalia.it><20080613225727.GC3759@verdi> <7335188A-BA0A-48E6-9D6B-9E4F6F09A4C6@nokia.com> Date: Mon, 16 Jun 2008 08:31:04 -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: V01U2FsdGVkX187PWeK75WixppDNJiM/qb7YGQj65bXa6xxSy6 1+UuHI63WcNiJ/+6CY0XkAaqQE+waQ5B7QPYdcFyW116fgFdsM 7kOy0aY3Mc/RZuteaS6n0Zm8kys2RwGraIUfD4OimA= Subject: Re: [p2pi] Refining the ALTO problem statement X-BeenThere: p2pi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: P2P Infrastructure Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: p2pi-bounces@ietf.org Errors-To: p2pi-bounces@ietf.org I don't actually think I'm good at channeling ADs, but for what it's worth... My understanding of what Lars is concerned about, is the idea of using an oracle to provide guidance about path characteristics on a timescale of less than many, many RTTs. He's concerned that a transmitter can respond to "good news" about a path from an oracle more quickly than the oracle can recognize that a transmitter has rapidly ramped up its transmit rate and start telling senders what it's seeing. My understanding of the discussion between John and Lars in this thread is that one key question is whether guidance about path selection has any relationship with congestion avoidance, detection, and recovery, or not. If I tell Lars "this path is usually uncongested on Saturday night", and he starts a large transfer on Saturday night, what does he do when he encounters congestion? - ignore it and keep transmitting as if the path was really uncongested (wrong answer!), - look for another path (but the guidance was that this is the best path most of the time), or - stay on this path and do TCPish loss-based bandwidth probing (even if the problem is that Magnus ALSO saw "this path is usually uncongested on Saturday night" and also selected this path for a large transfer - and this is even funnier if Magnus was congesting all the other paths LAST Saturday night, and decided to switch to this path "because it was uncongested") It seems helpful to discuss what the strategy is before we get very far into how the strategy might work... Thanks, Spencer _______________________________________________ p2pi mailing list p2pi@ietf.org https://www.ietf.org/mailman/listinfo/p2pi From p2pi-bounces@ietf.org Mon Jun 16 10:15:29 2008 Return-Path: X-Original-To: p2pi-archive@ietf.org Delivered-To: ietfarch-p2pi-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F09163A6A36; Mon, 16 Jun 2008 10: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 5DD933A6A3A for ; Mon, 16 Jun 2008 10:15:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.301 X-Spam-Level: X-Spam-Status: No, score=-2.301 tagged_above=-999 required=5 tests=[AWL=0.298, 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 OcOE5GpnZK1J for ; Mon, 16 Jun 2008 10:15:24 -0700 (PDT) Received: from mailhost.jlc.net (mailhost.jlc.net [199.201.159.9]) by core3.amsl.com (Postfix) with ESMTP id 59C5F3A6879 for ; Mon, 16 Jun 2008 10:15:21 -0700 (PDT) Received: by mailhost.jlc.net (Postfix, from userid 104) id 234B233C4B; Mon, 16 Jun 2008 13:16:03 -0400 (EDT) Date: Mon, 16 Jun 2008 13:16:03 -0400 From: John Leslie To: Lars Eggert Message-ID: <20080616171603.GE3759@verdi> References: <22F6A875-B548-4C65-AB68-B88E526CCA33@nokia.com> <6E1603B0-7116-45F9-A510-DC5F9040298B@nokia.com> <48516BE2.2080901@telecomitalia.it> <20080613225727.GC3759@verdi> <7335188A-BA0A-48E6-9D6B-9E4F6F09A4C6@nokia.com> Mime-Version: 1.0 Content-Disposition: inline In-Reply-To: <7335188A-BA0A-48E6-9D6B-9E4F6F09A4C6@nokia.com> User-Agent: Mutt/1.4.1i Cc: p2pi@ietf.org Subject: Re: [p2pi] Refining the ALTO problem statement X-BeenThere: p2pi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: P2P Infrastructure Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: p2pi-bounces@ietf.org Errors-To: p2pi-bounces@ietf.org Lars Eggert wrote: > On 2008-6-14, at 1:57, ext John Leslie wrote: >> Lars Eggert wrote: >> >>> it will be both very difficult and potentially problematic to share >>> performance-related information that changes on short timescales >>> in the same fashion. >> >> That's an implementation issue. >> We should do protocol design before we do implementation. >> Besides, it's only a couple orders of magnitude "difficult." It >> might be quite practical five years from now. > > I think we're talking about two different things. I understood the > proposal for the oracle to maintain performance-related information to > be for actual, current load of a path (modulo quantization effects and > communication latency). I understood the proposal to be maintaining performance-related information without specification of the time period it reflects. > That has all sorts of timing- and accuracy-related issues. Either way, yes... except that some characteristics like maximum bandwidth and minimum latency are pretty safe to report. > If I understand your email correctly (based on the quoted section > below), you see the oracle as maintaining more coarse-grained, > statistical load data about paths. Actually, I was more concerned that a protocol should support reporting such things, not wishing to get into how such information might be divined. > Things like "this path is half idle on Saturday night." (Actually, that's a bad example: while an oracle might be able to divine that parts of a path are in fact idle from 1800 to 2400 GMT on Saturdays, it couldn't reasonably say that about the _whole_ path. It _could_ say "latency above N milliseconds" indicates congestion.") > I agree that that information would be easier to provide. But I > question whether such load data can be useful to applications > (see below). > >> The application isn't particularly interested in one instantaneous >> snapshot: it's interested in what's likely to be the case over an >> extended period (or how long it is likely to take to transfer a known >> amount of data. Statistical summaries are much more useful: and the >> oracle is in a good position to provide those. > > Assuming for a moment we had an oracle that had such information, the > only benefit to apps would be to not even try to establish connections > to peers that had a projected low throughput. It's more a matter of which connection(s) to try _first_. > (And if the aggregate traffic to such peers would conflict with ISP > interests, they'd rank the peer low in the oracle because of that > anyway, independent of traffic statistics) Oracles will not _only_ be maintained by ISPs. ISP oracles will be used _only_ if the users perceive a benefit from using them. >>> So this information is unlikely to be useful to an app; I don't believe you've made your case for that... >>> and I can even construct cases where using this stale information >>> leads to traffic oscillations, which is problematic. >> >> Traffic oscillations are indeed problematic. But can you construct >> a case where statistical damping isn't sufficient to guard against >> that? > > Who would dampen what? Damping is inherent in statistical averaging. > The apps are just using information provided by the oracle and see > no oscillations. The oracle could observe that traffic shifts, but > how does it differentiate if that is due to the information it > provides or whether it is independent of that? It _should_ assume it is independent. > And even if it could, what does it then do? Unless it's the ISPs oracle, it should do nothing different. If it _is_ the ISPs oracle, we're getting pretty far into implementation... > Longer statistical aggregation decreases the frequency of oscillations, > but also means that the load data will be even less indicative of > current loads. Yes. (For many reasons, the p2p applications are likely to be in a better position to deal with instantaneous congestion.) >> Because instantaneous delay isn't a good measure. An oracle will be >> in a better position to know minimum latency, plus normal range for >> minimal congestion. > > Clarification: When you say "delay", it sounds you mean "projected > transmission time"? Because I think Enrico actually meant RTT. I was intentionally vague, but you guessed right: I think in terms of one-direction latency. P2P applications _could keep good enough clocks to make effective use of this. -- John Leslie _______________________________________________ p2pi mailing list p2pi@ietf.org https://www.ietf.org/mailman/listinfo/p2pi From p2pi-bounces@ietf.org Mon Jun 16 10:39:13 2008 Return-Path: X-Original-To: p2pi-archive@ietf.org Delivered-To: ietfarch-p2pi-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 398413A6AE4; Mon, 16 Jun 2008 10:39:13 -0700 (PDT) X-Original-To: p2pi@core3.amsl.com Delivered-To: p2pi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5D0403A6AE4 for ; Mon, 16 Jun 2008 10:39:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.328 X-Spam-Level: X-Spam-Status: No, score=-2.328 tagged_above=-999 required=5 tests=[AWL=0.271, 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 FmbhE1OZ29EX for ; Mon, 16 Jun 2008 10:39:11 -0700 (PDT) Received: from mailhost.jlc.net (mailhost.jlc.net [199.201.159.9]) by core3.amsl.com (Postfix) with ESMTP id 447853A6977 for ; Mon, 16 Jun 2008 10:39:11 -0700 (PDT) Received: by mailhost.jlc.net (Postfix, from userid 104) id 5940833C4C; Mon, 16 Jun 2008 13:39:53 -0400 (EDT) Date: Mon, 16 Jun 2008 13:39:53 -0400 From: John Leslie To: Spencer Dawkins Message-ID: <20080616173953.GF3759@verdi> References: <7335188A-BA0A-48E6-9D6B-9E4F6F09A4C6@nokia.com> <00b601c8cfb5$3aa68180$6401a8c0@china.huawei.com> Mime-Version: 1.0 Content-Disposition: inline In-Reply-To: <00b601c8cfb5$3aa68180$6401a8c0@china.huawei.com> User-Agent: Mutt/1.4.1i Cc: p2pi@ietf.org Subject: Re: [p2pi] Refining the ALTO problem statement X-BeenThere: p2pi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: P2P Infrastructure Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: p2pi-bounces@ietf.org Errors-To: p2pi-bounces@ietf.org Spencer Dawkins wrote: > > My understanding of what Lars is concerned about, is the idea of using > an oracle to provide guidance about path characteristics on a timescale > of less than many, many RTTs. He's concerned that a transmitter can > respond to "good news" about a path from an oracle more quickly than > the oracle can recognize that a transmitter has rapidly ramped up its > transmit rate and start telling senders what it's seeing. For a number of reasons, oracles _could_ be in a better position to know path characteristics. Congestion along a path tends to be concentrated at relatively few points along the path. Peers know what they're seeing (instantaneously) over the whole path, but generally lack any understanding about subpaths. > My understanding of the discussion between John and Lars in this thread > is that one key question is whether guidance about path selection has any > relationship with congestion avoidance, detection, and recovery, or not. > > If I tell Lars "this path is usually uncongested on Saturday night", and > he starts a large transfer on Saturday night, what does he do when he > encounters congestion? > > - ignore it and keep transmitting as if the path was really uncongested > (wrong answer!), Agreed. > - look for another path (but the guidance was that this is the best path > most of the time), or Abandoning the path based on instantaneous congestion may be wrong. Trying an alternate as an additional option may be wise. > - stay on this path and do TCPish loss-based bandwidth probing (even if > the problem is that Magnus ALSO saw "this path is usually uncongested > on Saturday night" and also selected this path for a large transfer It is reasonable to expect P2P applications to learn how to use more than one remote peer at a time. Statistical information is never a guarantee that you'll see exactly the predicted situation. (An ISPs oracle could, in principle, downgrade a recommendation after it has been issued to some number of customers. However, that is an implementation detail, and I don't mean to recommend it.) > - and this is even funnier if Magnus was congesting all the other > paths LAST Saturday night, and decided to switch to this path > "because it was uncongested") The world is, indeed, stranger than we _can_ imagine... > It seems helpful to discuss what the strategy is before we get very far > into how the strategy might work... P2P applications need not all use the same strategy for identifying congestion, nor even for responding to it. However, it is arguably "TCP-friendly" to switch half your bandwidth to an alternate path when congestion is experienced... -- John Leslie _______________________________________________ p2pi mailing list p2pi@ietf.org https://www.ietf.org/mailman/listinfo/p2pi From p2pi-bounces@ietf.org Mon Jun 16 10:47:54 2008 Return-Path: X-Original-To: p2pi-archive@ietf.org Delivered-To: ietfarch-p2pi-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 338253A6816; Mon, 16 Jun 2008 10:47:54 -0700 (PDT) X-Original-To: p2pi@core3.amsl.com Delivered-To: p2pi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8DE903A6765 for ; Mon, 16 Jun 2008 10:47:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.17 X-Spam-Level: X-Spam-Status: No, score=-10.17 tagged_above=-999 required=5 tests=[AWL=0.095, BAYES_00=-2.599, HABEAS_ACCREDITED_COI=-8, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OePJHYK6hc8Z for ; Mon, 16 Jun 2008 10:47:51 -0700 (PDT) Received: from dkny.pando.com (dkny.pando.com [67.99.55.163]) by core3.amsl.com (Postfix) with ESMTP id 990D33A6AF9 for ; Mon, 16 Jun 2008 10:47:46 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by dkny.pando.com (Postfix) with ESMTP id 26984E10AF0; Mon, 16 Jun 2008 13:48:23 -0400 (EDT) X-Virus-Scanned: amavisd-new at Received: from dkny.pando.com ([127.0.0.1]) by localhost (dkny.pando.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DQqJhf81MKjr; Mon, 16 Jun 2008 13:47:40 -0400 (EDT) Received: from dkny.pando.com (dkny.pando.com [10.10.60.11]) by dkny.pando.com (Postfix) with ESMTP id 67849E10ACA; Mon, 16 Jun 2008 13:47:40 -0400 (EDT) Date: Mon, 16 Jun 2008 13:47:40 -0400 (EDT) From: Laird Popkin To: Spencer Dawkins Message-ID: <460238709.401631213638460392.JavaMail.root@dkny.pando.com> In-Reply-To: <808736645.401551213637330822.JavaMail.root@dkny.pando.com> MIME-Version: 1.0 X-Originating-IP: [10.10.20.73] Cc: p2pi@ietf.org Subject: Re: [p2pi] Refining the ALTO problem statement X-BeenThere: p2pi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: P2P Infrastructure Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: p2pi-bounces@ietf.org Errors-To: p2pi-bounces@ietf.org Of the options that you lay out, I think that most p2p applications would want "look for another path (but the guidance was that this is the best path most of the time)". The other options don't reflect the fact that p2p networks continually look for new p2p connections to establish and utilize. So even if you tell Lars that "this path is available on Saturday nights" his software should make lots of other p2p connections. Given a well connected p2p mesh (which is our goal), p2p applications will always shift data transfers away from congested sources to more available sources. Right now this decision is usually made based on observed throughput, though I personally hope that ECN and Re-ECN can help us make better informed decisions. There's also a matter of timing. In the ALTO and P4P models proposed, the ISP guidance only affects which peers are introduced to each other. Once peers are connected, the data flow is managed by the p2p network. Since p2p connections can be very long lasting (often hours or even days), the ISP cannot really control the p2p network's real-time data flow. Keep in mind, though, that the ISP guidance will not replace whatever else the P2P networks do to optimize performance. At most, the oracle will provide some guidance that is hopefully of mutual benefit. But there will always be additional sources of peers (e.g. random peers, peer exchange) and other sources of information (e.g. observed throughput, RTT's). - Laird Popkin, CTO, Pando Networks mobile: 646/465-0570 ----- Original Message ----- From: "Spencer Dawkins" To: p2pi@ietf.org Sent: Monday, June 16, 2008 9:31:04 AM (GMT-0500) America/New_York Subject: Re: [p2pi] Refining the ALTO problem statement I don't actually think I'm good at channeling ADs, but for what it's worth... My understanding of what Lars is concerned about, is the idea of using an oracle to provide guidance about path characteristics on a timescale of less than many, many RTTs. He's concerned that a transmitter can respond to "good news" about a path from an oracle more quickly than the oracle can recognize that a transmitter has rapidly ramped up its transmit rate and start telling senders what it's seeing. My understanding of the discussion between John and Lars in this thread is that one key question is whether guidance about path selection has any relationship with congestion avoidance, detection, and recovery, or not. If I tell Lars "this path is usually uncongested on Saturday night", and he starts a large transfer on Saturday night, what does he do when he encounters congestion? - ignore it and keep transmitting as if the path was really uncongested (wrong answer!), - look for another path (but the guidance was that this is the best path most of the time), or - stay on this path and do TCPish loss-based bandwidth probing (even if the problem is that Magnus ALSO saw "this path is usually uncongested on Saturday night" and also selected this path for a large transfer - and this is even funnier if Magnus was congesting all the other paths LAST Saturday night, and decided to switch to this path "because it was uncongested") It seems helpful to discuss what the strategy is before we get very far into how the strategy might work... Thanks, Spencer _______________________________________________ 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 Jun 16 11:15:55 2008 Return-Path: X-Original-To: p2pi-archive@ietf.org Delivered-To: ietfarch-p2pi-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 52E1A3A69F2; Mon, 16 Jun 2008 11:15:55 -0700 (PDT) X-Original-To: p2pi@core3.amsl.com Delivered-To: p2pi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8CC4A3A69F2 for ; Mon, 16 Jun 2008 11:15:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.395 X-Spam-Level: X-Spam-Status: No, score=-2.395 tagged_above=-999 required=5 tests=[AWL=0.203, BAYES_00=-2.599, STOX_REPLY_TYPE=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 ywl8LOzuoQr3 for ; Mon, 16 Jun 2008 11:15:53 -0700 (PDT) Received: from mout.perfora.net (mout.perfora.net [74.208.4.197]) by core3.amsl.com (Postfix) with ESMTP id 845213A69E7 for ; Mon, 16 Jun 2008 11:15:53 -0700 (PDT) Received: from s73602 (cpe-72-190-0-23.tx.res.rr.com [72.190.0.23]) by mrelay.perfora.net (node=mrus1) with ESMTP (Nemesis) id 0MKpCa-1K8JFk3zCw-0004Mb; Mon, 16 Jun 2008 14:16:30 -0400 Message-ID: <01fd01c8cfdd$3dd8a770$6401a8c0@china.huawei.com> From: "Spencer Dawkins" To: References: <7335188A-BA0A-48E6-9D6B-9E4F6F09A4C6@nokia.com> <00b601c8cfb5$3aa68180$6401a8c0@china.huawei.com> <20080616173953.GF3759@verdi> Date: Mon, 16 Jun 2008 13:17:28 -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+ze6d9paMVdv8tB7VQlfYJLwFT5ZpYXUT6rx8 NZBGXVPdzSl6E+naQDZtTZOP2Gz8/DS8xl1Bi+WUnFqP0ORkLS ZoK9l85wLtCP5ZS3wkHA3CoX4HHU4QzjWvLYR+LAg8= Subject: Re: [p2pi] Refining the ALTO problem statement X-BeenThere: p2pi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: P2P Infrastructure Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: p2pi-bounces@ietf.org Errors-To: p2pi-bounces@ietf.org Hi, John, >> My understanding of what Lars is concerned about, is the idea of using >> an oracle to provide guidance about path characteristics on a timescale >> of less than many, many RTTs. He's concerned that a transmitter can >> respond to "good news" about a path from an oracle more quickly than >> the oracle can recognize that a transmitter has rapidly ramped up its >> transmit rate and start telling senders what it's seeing. > > For a number of reasons, oracles _could_ be in a better position to > know path characteristics. Congestion along a path tends to be > concentrated > at relatively few points along the path. Peers know what they're seeing > (instantaneously) over the whole path, but generally lack any > understanding > about subpaths. I agree that oracles could be in a better position to know path characteristics. What I thought Lars was concerned about was not what the oracle could know, but how quickly the oracle could share this knowledge with transmitters. If someone told Lars that we expect the oracle to adjust its suggestions every 30 minutes, he'd probably be happier than if someone told Lars that we expect the oracle to adjust its suggestions every 30 milliseconds... and I'm not sure that Lars knows which is more representative of what people are thinking. Thanks, Spencer _______________________________________________ p2pi mailing list p2pi@ietf.org https://www.ietf.org/mailman/listinfo/p2pi From p2pi-bounces@ietf.org Tue Jun 17 19:29:08 2008 Return-Path: X-Original-To: p2pi-archive@ietf.org Delivered-To: ietfarch-p2pi-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7ABF63A68ED; Tue, 17 Jun 2008 19:29:08 -0700 (PDT) X-Original-To: p2pi@core3.amsl.com Delivered-To: p2pi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D0EDF3A68ED for ; Tue, 17 Jun 2008 19:29:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.475 X-Spam-Level: X-Spam-Status: No, score=-3.475 tagged_above=-999 required=5 tests=[AWL=0.124, 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 etytKe1yci7L for ; Tue, 17 Jun 2008 19:29:06 -0700 (PDT) Received: from serrano.cc.columbia.edu (serrano.cc.columbia.edu [128.59.29.6]) by core3.amsl.com (Postfix) with ESMTP id 92C8D3A68E8 for ; Tue, 17 Jun 2008 19:29:06 -0700 (PDT) Received: from [192.168.0.61] (pool-71-250-62-209.nwrknj.east.verizon.net [71.250.62.209]) (user=hgs10 mech=PLAIN bits=0) by serrano.cc.columbia.edu (8.14.1/8.14.1) with ESMTP id m5I2TlXk026694 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 17 Jun 2008 22:29:48 -0400 (EDT) Message-Id: From: Henning Schulzrinne To: Lars Eggert In-Reply-To: <3083CE1C-A219-4DB6-BAEC-E74DC3FD9C46@nokia.com> Mime-Version: 1.0 (Apple Message framework v924) Date: Tue, 17 Jun 2008 22:29:46 -0400 References: <22F6A875-B548-4C65-AB68-B88E526CCA33@nokia.com> <6E1603B0-7116-45F9-A510-DC5F9040298B@nokia.com> <48516BE2.2080901@telecomitalia.it> <48541F91.1010306@telecomitalia.it> <3083CE1C-A219-4DB6-BAEC-E74DC3FD9C46@nokia.com> X-Mailer: Apple Mail (2.924) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.63 on 128.59.29.6 Cc: "p2pi@ietf.org" Subject: Re: [p2pi] Refining the ALTO problem statement [Was: Re: discussing P2PI-related standardization in Dublin] X-BeenThere: p2pi@ietf.org X-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 RSVP TSpec. Alternatively, a protocol such as GIST could >> discover >> the cost of particular destination. The service classes may change >> over time. For example, a network may offer "midnight specials" when >> the network is idle during off-hours, encouraging bulk downloads >> during that time. > > thanks - that does make it clearer. I agree that it's interesting to > think through the possibilities here, but I don't see anything we > could immediately think about standardizing here. > I do see a need for standardization here, namely conveying the current bandwidth price or total usage. (More complicated models are feasible, but I think something pretty simple would do the job and avoid getting into business models.) You'd want to get something like "Your current charge for priority X is Y currency units/byte, valid until time T." "You have used B bytes out of L bytes for priority X." "Your max. rate for priority X is S bits/second." This covers the major knobs that a provider can turn (quotas, rate limits and metering). > That is definitely possible. For example, low-RTT peers may be behind > other DSL boxes within your ISP, whereas the university with the big > pipe is a bit further away in RTT terms than those peers - who'd you > like to transfer from? I'd expect the correlation between RTT and > transmission time to be pretty weak (but have no data to back this > up.) Given that TCP throughput is inversely proportional to RTT, one would indeed expect a correlation. See http://www.slac.stanford.edu/comp/net/wan-mon/thru-vs-loss.html for a random related page. Obviously, capacity matters where a single flow is likely to occupy the whole pipe. Henning > > > Lars > _______________________________________________ > p2pi mailing list > p2pi@ietf.org > https://www.ietf.org/mailman/listinfo/p2pi _______________________________________________ p2pi mailing list p2pi@ietf.org https://www.ietf.org/mailman/listinfo/p2pi From p2pi-bounces@ietf.org Tue Jun 17 21:04: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 4DEC33A68E8; Tue, 17 Jun 2008 21:04: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 46AC53A68E8 for ; Tue, 17 Jun 2008 21:04:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5A6AB6j5RoVX for ; Tue, 17 Jun 2008 21:04:42 -0700 (PDT) Received: from yw-out-2324.google.com (yw-out-2324.google.com [74.125.46.28]) by core3.amsl.com (Postfix) with ESMTP id 32F9F3A68C5 for ; Tue, 17 Jun 2008 21:04:42 -0700 (PDT) Received: by yw-out-2324.google.com with SMTP id 3so39771ywj.49 for ; Tue, 17 Jun 2008 21:05:26 -0700 (PDT) Received: by 10.151.108.10 with SMTP id k10mr259418ybm.113.1213761926152; Tue, 17 Jun 2008 21:05:26 -0700 (PDT) Received: by 10.150.196.13 with HTTP; Tue, 17 Jun 2008 21:05:26 -0700 (PDT) Message-ID: Date: Tue, 17 Jun 2008 21:05:26 -0700 From: "Stanislav Shalunov" To: "Henning Schulzrinne" In-Reply-To: MIME-Version: 1.0 Content-Disposition: inline References: <22F6A875-B548-4C65-AB68-B88E526CCA33@nokia.com> <6E1603B0-7116-45F9-A510-DC5F9040298B@nokia.com> <48516BE2.2080901@telecomitalia.it> <48541F91.1010306@telecomitalia.it> <3083CE1C-A219-4DB6-BAEC-E74DC3FD9C46@nokia.com> X-Google-Sender-Auth: 1752b164c45fd55d Cc: p2pi@ietf.org Subject: Re: [p2pi] Refining the ALTO problem statement [Was: Re: discussing P2PI-related standardization in Dublin] X-BeenThere: p2pi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: P2P Infrastructure Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: p2pi-bounces@ietf.org Errors-To: p2pi-bounces@ietf.org On Tue, Jun 17, 2008 at 7:29 PM, Henning Schulzrinne wrote: > "Your current charge for priority X is Y currency units/byte, valid > until time T." > > "You have used B bytes out of L bytes for priority X." > > "Your max. rate for priority X is S bits/second." It might also be interesting to know the differences in provider costs between different destinations. > Given that TCP throughput is inversely proportional to RTT, one would > indeed expect a correlation. The small differences in Internet RTTs are drowned out by the huge extra delay indiced by TCP, and so wouldn't matter even in random or periodic loss model that this statement implies. In reality, of course, TCP throughput is related to bottleneck bitrate. -- Stanislav Shalunov http://shlang.com/ _______________________________________________ p2pi mailing list p2pi@ietf.org https://www.ietf.org/mailman/listinfo/p2pi From p2pi-bounces@ietf.org Tue Jun 17 22:56:37 2008 Return-Path: X-Original-To: p2pi-archive@ietf.org Delivered-To: ietfarch-p2pi-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 974493A6901; Tue, 17 Jun 2008 22:56:37 -0700 (PDT) X-Original-To: p2pi@core3.amsl.com Delivered-To: p2pi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1054D3A6901 for ; Tue, 17 Jun 2008 22:56:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.495 X-Spam-Level: X-Spam-Status: No, score=-6.495 tagged_above=-999 required=5 tests=[AWL=0.104, 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 OBqeh5Y7OCfB for ; Tue, 17 Jun 2008 22:56:36 -0700 (PDT) Received: from mgw-mx09.nokia.com (smtp.nokia.com [192.100.105.134]) by core3.amsl.com (Postfix) with ESMTP id 389D43A68A2 for ; Tue, 17 Jun 2008 22:56:36 -0700 (PDT) Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-mx09.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id m5I5qvbG002400; Wed, 18 Jun 2008 00:57:12 -0500 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 18 Jun 2008 08:57:01 +0300 Received: from [192.168.255.2] ([10.241.184.208]) by esebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Wed, 18 Jun 2008 08:57:00 +0300 Message-Id: <6F3A2A6A-70FC-4D67-AC73-3A05079341E5@nokia.com> From: Lars Eggert To: ext Henning Schulzrinne In-Reply-To: Mime-Version: 1.0 (Apple Message framework v924) Date: Wed, 18 Jun 2008 08:56:55 +0300 References: <22F6A875-B548-4C65-AB68-B88E526CCA33@nokia.com> <6E1603B0-7116-45F9-A510-DC5F9040298B@nokia.com> <48516BE2.2080901@telecomitalia.it> <48541F91.1010306@telecomitalia.it> <3083CE1C-A219-4DB6-BAEC-E74DC3FD9C46@nokia.com> X-Mailer: Apple Mail (2.924) X-OriginalArrivalTime: 18 Jun 2008 05:57:01.0334 (UTC) FILETIME=[2062AB60:01C8D108] X-Nokia-AV: Clean Cc: "p2pi@ietf.org" Subject: Re: [p2pi] Refining the ALTO problem statement [Was: Re: discussing P2PI-related standardization in Dublin] X-BeenThere: p2pi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: P2P Infrastructure Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: p2pi-bounces@ietf.org Errors-To: p2pi-bounces@ietf.org Hi, On 2008-6-18, at 5:29, ext Henning Schulzrinne wrote: > I do see a need for standardization here, namely conveying the > current bandwidth price or total usage. (More complicated models are > feasible, but I think something pretty simple would do the job and > avoid getting into business models.) > > You'd want to get something like > > "Your current charge for priority X is Y currency units/byte, valid > until time T." > > "You have used B bytes out of L bytes for priority X." > > "Your max. rate for priority X is S bits/second." > > This covers the major knobs that a provider can turn (quotas, rate > limits and metering). that seems reasonable - thanks for clarifying. >> That is definitely possible. For example, low-RTT peers may be behind >> other DSL boxes within your ISP, whereas the university with the big >> pipe is a bit further away in RTT terms than those peers - who'd you >> like to transfer from? I'd expect the correlation between RTT and >> transmission time to be pretty weak (but have no data to back this >> up.) > > Given that TCP throughput is inversely proportional to RTT, one > would indeed expect a correlation. TCP bandwidth is proportional to the RTT when different flows *share the same bottleneck*. But that isn't what matters here. Knowing the RTT to a potential peer will not allow an app to draw any conclusions about projected throughput, because the app knows neither the bottleneck capacity nor the RTTs of all other flows going through that bottleneck. Plus, the theoretical result is only valid when all flows are in steady state. Lars _______________________________________________ p2pi mailing list p2pi@ietf.org https://www.ietf.org/mailman/listinfo/p2pi From p2pi-bounces@ietf.org Mon Jun 23 07:51:58 2008 Return-Path: X-Original-To: p2pi-archive@ietf.org Delivered-To: ietfarch-p2pi-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 44B463A69C7; Mon, 23 Jun 2008 07:51:58 -0700 (PDT) X-Original-To: p2pi@core3.amsl.com Delivered-To: p2pi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E46D63A697E for ; Mon, 23 Jun 2008 07:51:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.519 X-Spam-Level: X-Spam-Status: No, score=-6.519 tagged_above=-999 required=5 tests=[AWL=0.080, 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 0poOrC9nAkcW for ; Mon, 23 Jun 2008 07:51:56 -0700 (PDT) Received: from mgw-mx09.nokia.com (smtp.nokia.com [192.100.105.134]) by core3.amsl.com (Postfix) with ESMTP id EFC3B3A68EB for ; Mon, 23 Jun 2008 07:51:52 -0700 (PDT) Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-mx09.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id m5NEpOUB009999; Mon, 23 Jun 2008 09:51:47 -0500 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 23 Jun 2008 17:51:32 +0300 Received: from [10.180.41.12] ([10.241.184.208]) by esebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Mon, 23 Jun 2008 17:51:31 +0300 Message-Id: From: Lars Eggert To: ext John Leslie In-Reply-To: <20080616173953.GF3759@verdi> Mime-Version: 1.0 (Apple Message framework v924) Date: Mon, 23 Jun 2008 17:51:24 +0300 References: <7335188A-BA0A-48E6-9D6B-9E4F6F09A4C6@nokia.com> <00b601c8cfb5$3aa68180$6401a8c0@china.huawei.com> <20080616173953.GF3759@verdi> X-Mailer: Apple Mail (2.924) X-OriginalArrivalTime: 23 Jun 2008 14:51:31.0858 (UTC) FILETIME=[9FF90720:01C8D540] X-Nokia-AV: Clean Cc: p2pi@ietf.org Subject: Re: [p2pi] Refining the ALTO problem statement X-BeenThere: p2pi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: P2P Infrastructure Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: p2pi-bounces@ietf.org Errors-To: p2pi-bounces@ietf.org Hi, sorry it took me a while to respond. On 2008-6-16, at 20:39, ext John Leslie wrote: > Spencer Dawkins wrote: >> >> My understanding of what Lars is concerned about, is the idea of >> using >> an oracle to provide guidance about path characteristics on a >> timescale >> of less than many, many RTTs. He's concerned that a transmitter can >> respond to "good news" about a path from an oracle more quickly than >> the oracle can recognize that a transmitter has rapidly ramped up its >> transmit rate and start telling senders what it's seeing. Spencer: sort of, yes. Basically, I'm concerned that this builds a high-layer control loop that acts on the same information on (as I understand it) roughly the same timescales. That's not necessarily problematic, but there's at least a ;arge potential for interactions. > For a number of reasons, oracles _could_ be in a better position to > know path characteristics. Congestion along a path tends to be > concentrated > at relatively few points along the path. Peers know what they're > seeing > (instantaneously) over the whole path, but generally lack any > understanding > about subpaths. John: But what matters for a given flow are the characteristics of the whole path. Why would sub-paths matter? Also, how would the oracle learn about the congestion levels of each router, and on what timescales is this information accurate? >> My understanding of the discussion between John and Lars in this >> thread >> is that one key question is whether guidance about path selection >> has any >> relationship with congestion avoidance, detection, and recovery, or >> not. >> >> If I tell Lars "this path is usually uncongested on Saturday >> night", and >> he starts a large transfer on Saturday night, what does he do when he >> encounters congestion? >> >> - ignore it and keep transmitting as if the path was really >> uncongested >> (wrong answer!), > > Agreed. > >> - look for another path (but the guidance was that this is the best >> path >> most of the time), or > > Abandoning the path based on instantaneous congestion may be wrong. > Trying an alternate as an additional option may be wise. > >> - stay on this path and do TCPish loss-based bandwidth probing >> (even if >> the problem is that Magnus ALSO saw "this path is usually >> uncongested >> on Saturday night" and also selected this path for a large transfer > > It is reasonable to expect P2P applications to learn how to use more > than one remote peer at a time. Statistical information is never a > guarantee that you'll see exactly the predicted situation. True, but unless the information is accurate much more often than not, why bother designing a mechanism to provide it? Apps will just ignore it then. I question whether we actually can design an oracle that is right much more often than wrong with regards to performance-related information. Trying to answer this question as a research effort is very interesting, doing standardization around it is IMO premature. Lars _______________________________________________ p2pi mailing list p2pi@ietf.org https://www.ietf.org/mailman/listinfo/p2pi From p2pi-bounces@ietf.org Mon Jun 23 09:09:47 2008 Return-Path: X-Original-To: p2pi-archive@ietf.org Delivered-To: ietfarch-p2pi-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C2EF53A6A17; Mon, 23 Jun 2008 09:09:47 -0700 (PDT) X-Original-To: p2pi@core3.amsl.com Delivered-To: p2pi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 827263A6A0A for ; Mon, 23 Jun 2008 09:09:46 -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=[BAYES_50=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 BPI2dtb+pe33 for ; Mon, 23 Jun 2008 09:09:45 -0700 (PDT) Received: from mout.perfora.net (mout.perfora.net [74.208.4.197]) by core3.amsl.com (Postfix) with ESMTP id A87723A69D5 for ; Mon, 23 Jun 2008 09:09:45 -0700 (PDT) Received: from s73602 (cpe-72-190-0-23.tx.res.rr.com [72.190.0.23]) by mrelay.perfora.net (node=mrus0) with ESMTP (Nemesis) id 0MKp8S-1KAobt3VP7-0003YY; Mon, 23 Jun 2008 12:09:45 -0400 Message-ID: <00c401c8d54b$ad624060$6501a8c0@china.huawei.com> From: "Spencer Dawkins" To: "Lars Eggert" , "ext John Leslie" References: <7335188A-BA0A-48E6-9D6B-9E4F6F09A4C6@nokia.com> <00b601c8cfb5$3aa68180$6401a8c0@china.huawei.com> <20080616173953.GF3759@verdi> Date: Mon, 23 Jun 2008 11:10:34 -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+4cbfDaazNC8E5nyW0UaDv9/txyxts1SUAuPO 5hLMI46EBfQmbEii8veNu3jZwXFP/0oNSQcN/yVYHweg+PWbmV ZQnzwgR1dAr0XTZh/mWvEGDwCCa21NfRpyB9ubU/tM= Cc: p2pi@ietf.org Subject: Re: [p2pi] Refining the ALTO problem statement X-BeenThere: p2pi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: P2P Infrastructure Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: p2pi-bounces@ietf.org Errors-To: p2pi-bounces@ietf.org For what it's worth... >> It is reasonable to expect P2P applications to learn how to use more >> than one remote peer at a time. Statistical information is never a >> guarantee that you'll see exactly the predicted situation. > > True, but unless the information is accurate much more often than not, > why bother designing a mechanism to provide it? Apps will just ignore it > then. This was actually the stake through the heart of TRIGTRAN, if anyone remembers that conversation - TCPs are complicated enough already, so if you have to treat non-loss indications as advisory, and you can figure out what the right answer is in a small number of RTTs without using the other indications anyway, the thought was that there wasn't enough reason for implementers to find TRIGTRAN interesting. > I question whether we actually can design an oracle that is right much > more often than wrong with regards to performance-related information. > Trying to answer this question as a research effort is very interesting, > doing standardization around it is IMO premature. You may very well be correct... :-) Spencer _______________________________________________ p2pi mailing list p2pi@ietf.org https://www.ietf.org/mailman/listinfo/p2pi From p2pi-bounces@ietf.org Mon Jun 23 09:45:26 2008 Return-Path: X-Original-To: p2pi-archive@ietf.org Delivered-To: ietfarch-p2pi-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BEA513A697E; Mon, 23 Jun 2008 09:45:26 -0700 (PDT) X-Original-To: p2pi@core3.amsl.com Delivered-To: p2pi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0875E3A6910 for ; Mon, 23 Jun 2008 09:45:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.299 X-Spam-Level: X-Spam-Status: No, score=-1.299 tagged_above=-999 required=5 tests=[AWL=1.300, 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 7i6VaLtll0uQ for ; Mon, 23 Jun 2008 09:45:24 -0700 (PDT) Received: from mailhost.jlc.net (mailhost.jlc.net [199.201.159.9]) by core3.amsl.com (Postfix) with ESMTP id 7EA033A68B5 for ; Mon, 23 Jun 2008 09:45:24 -0700 (PDT) Received: by mailhost.jlc.net (Postfix, from userid 104) id 4D5B833C1F; Mon, 23 Jun 2008 12:45:23 -0400 (EDT) Date: Mon, 23 Jun 2008 12:45:23 -0400 From: John Leslie To: Lars Eggert Message-ID: <20080623164523.GB26944@verdi> References: <7335188A-BA0A-48E6-9D6B-9E4F6F09A4C6@nokia.com> <00b601c8cfb5$3aa68180$6401a8c0@china.huawei.com> <20080616173953.GF3759@verdi> Mime-Version: 1.0 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.1i Cc: p2pi@ietf.org Subject: Re: [p2pi] Refining the ALTO problem statement X-BeenThere: p2pi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: P2P Infrastructure Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: p2pi-bounces@ietf.org Errors-To: p2pi-bounces@ietf.org Lars Eggert wrote: > On 2008-6-16, at 20:39, ext John Leslie wrote: > >> For a number of reasons, oracles _could_ be in a better position >> to know path characteristics. Congestion along a path tends to be >> concentrated at relatively few points along the path. Peers know >> what they're seeing (instantaneously) over the whole path, but >> generally lack any understanding about subpaths. > > John: But what matters for a given flow are the characteristics of > the whole path. Why would sub-paths matter? A good question, actually... Sub-paths matter because they're what gets congested. P2P applications have good reason to want to know (instantaneous) congestion, and what the likelihood is that the congestion will get better or worse soon. Oracles _could_ give them "This is what congestion looks like" information. This could be a big win. > Also, how would the oracle learn about the congestion levels of each > router, and on what timescales is this information accurate? Oracles, pretty much by definition, have access to characteristics over a _long_ time period. _How_ they learn congestion levels of each router is not in scope of this work. (Certainly there are standard tools ISPs use to divine congestion levels.) It's not important for us to say what timescales Oracles should use, we merely want to specify how they report their timescales. >> It is reasonable to expect P2P applications to learn how to use more >> than one remote peer at a time. Statistical information is never a >> guarantee that you'll see exactly the predicted situation. > > True, but unless the information is accurate much more often than not, This shouldn't be a difficult goal -- unless we do a poor job of defining a protocol to accurately communicate _what_ has been measured, on what timescale. > why bother designing a mechanism to provide it? Apps will just ignore > it then. ... giving other Oracles a shot at the market... > I question whether we actually can design an oracle that is right much > more often than wrong with regards to performance-related information. It really isn't hard! Oracles can almost trivially find maximum bandwidth and minimum latency along subpaths, and unless the routing changes, these will stay rather constant. The apps, given just that much information, can make a much better judgment of instantaneous congestion than they could without it. Anything an Oracle could do about predicting future trends in congestion would be icing on the cake, hardly even necessary to prove their worth. > Trying to answer this question as a research effort is very > interesting, doing standardization around it is IMO premature. There's certainly room for a lot of research; but standardizing the _interface_ between oracle and P2P app would be a _major_ benefit to that research, while giving some immediate benefit to the apps and the ISPs. -- John Leslie _______________________________________________ p2pi mailing list p2pi@ietf.org https://www.ietf.org/mailman/listinfo/p2pi From p2pi-bounces@ietf.org Mon Jun 23 13:15: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 444B13A697B; Mon, 23 Jun 2008 13:15: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 0D54A3A688D for ; Mon, 23 Jun 2008 13:15:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f2kk2zZ6HoIP for ; Mon, 23 Jun 2008 13:15:12 -0700 (PDT) Received: from mx20.brocade.com (mx20.brocade.com [66.243.153.19]) by core3.amsl.com (Postfix) with ESMTP id 0EBAC3A6910 for ; Mon, 23 Jun 2008 13:15:12 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.27,692,1204531200"; d="scan'208";a="51690436" Received: from discus.brocade.com ([192.168.126.240]) by mx20.brocade.com with ESMTP; 23 Jun 2008 13:15:02 -0700 Received: from HQ-EXCHFE-2.corp.brocade.com (hq-plato-6 [192.168.126.214]) by discus.brocade.com (Postfix) with ESMTP id CED09238407; Mon, 23 Jun 2008 13:15:02 -0700 (PDT) Received: from HQ-EXCH-5.corp.brocade.com ([10.3.8.83]) by HQ-EXCHFE-2.corp.brocade.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 23 Jun 2008 13:15:02 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 23 Jun 2008 13:15:01 -0700 Message-ID: <81B8FED9AC5F024A9506BB706F69227803C89535@HQ-EXCH-5.corp.brocade.com> In-Reply-To: <20080623164523.GB26944@verdi> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [p2pi] Refining the ALTO problem statement thread-index: AcjVUI49KaCyRt0ISPCVvHTpUmSjGgAESnCA References: <7335188A-BA0A-48E6-9D6B-9E4F6F09A4C6@nokia.com><00b601c8cfb5$3aa68180$6401a8c0@china.huawei.com><20080616173953.GF3759@verdi> <20080623164523.GB26944@verdi> From: "Robert Snively" To: "John Leslie" , "Lars Eggert" X-OriginalArrivalTime: 23 Jun 2008 20:15:02.0794 (UTC) FILETIME=[D1CACEA0:01C8D56D] Cc: p2pi@ietf.org Subject: Re: [p2pi] Refining the ALTO problem statement X-BeenThere: p2pi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: P2P Infrastructure Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: p2pi-bounces@ietf.org Errors-To: p2pi-bounces@ietf.org One thing I have not seen directly addressed is that congestion is only a second-order symptom of the demand profile. It indicates what managed to get into the network, not what people really wanted to pass through the network. How do we address that broader question? Bob -----Original Message----- From: p2pi-bounces@ietf.org [mailto:p2pi-bounces@ietf.org] On Behalf Of John Leslie Sent: Monday, June 23, 2008 9:45 AM To: Lars Eggert Cc: p2pi@ietf.org Subject: Re: [p2pi] Refining the ALTO problem statement Lars Eggert wrote: > On 2008-6-16, at 20:39, ext John Leslie wrote: > >> For a number of reasons, oracles _could_ be in a better position >> to know path characteristics. Congestion along a path tends to be >> concentrated at relatively few points along the path. Peers know >> what they're seeing (instantaneously) over the whole path, but >> generally lack any understanding about subpaths. > > John: But what matters for a given flow are the characteristics of > the whole path. Why would sub-paths matter? A good question, actually... Sub-paths matter because they're what gets congested. P2P applications have good reason to want to know (instantaneous) congestion, and what the likelihood is that the congestion will get better or worse soon. Oracles _could_ give them "This is what congestion looks like" information. This could be a big win. > Also, how would the oracle learn about the congestion levels of each > router, and on what timescales is this information accurate? Oracles, pretty much by definition, have access to characteristics over a _long_ time period. _How_ they learn congestion levels of each router is not in scope of this work. (Certainly there are standard tools ISPs use to divine congestion levels.) It's not important for us to say what timescales Oracles should use, we merely want to specify how they report their timescales. >> It is reasonable to expect P2P applications to learn how to use more >> than one remote peer at a time. Statistical information is never a >> guarantee that you'll see exactly the predicted situation. > > True, but unless the information is accurate much more often than not, This shouldn't be a difficult goal -- unless we do a poor job of defining a protocol to accurately communicate _what_ has been measured, on what timescale. > why bother designing a mechanism to provide it? Apps will just ignore > it then. ... giving other Oracles a shot at the market... > I question whether we actually can design an oracle that is right much > more often than wrong with regards to performance-related information. It really isn't hard! Oracles can almost trivially find maximum bandwidth and minimum latency along subpaths, and unless the routing changes, these will stay rather constant. The apps, given just that much information, can make a much better judgment of instantaneous congestion than they could without it. Anything an Oracle could do about predicting future trends in congestion would be icing on the cake, hardly even necessary to prove their worth. > Trying to answer this question as a research effort is very > interesting, doing standardization around it is IMO premature. There's certainly room for a lot of research; but standardizing the _interface_ between oracle and P2P app would be a _major_ benefit to that research, while giving some immediate benefit to the apps and the ISPs. -- John Leslie _______________________________________________ p2pi mailing list p2pi@ietf.org https://www.ietf.org/mailman/listinfo/p2pi _______________________________________________ p2pi mailing list p2pi@ietf.org https://www.ietf.org/mailman/listinfo/p2pi From p2pi-bounces@ietf.org Wed Jun 25 17:43: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 178B13A68F8; Wed, 25 Jun 2008 17:43: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 6FE0D3A6813 for ; Mon, 23 Jun 2008 16:58:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f81EXcL4Yftv for ; Mon, 23 Jun 2008 16:58:39 -0700 (PDT) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.233]) by core3.amsl.com (Postfix) with ESMTP id 24BBA3A67FB for ; Mon, 23 Jun 2008 16:58:39 -0700 (PDT) Received: by rv-out-0506.google.com with SMTP id b25so7702945rvf.49 for ; Mon, 23 Jun 2008 16:58:39 -0700 (PDT) Received: by 10.141.197.14 with SMTP id z14mr13584276rvp.283.1214265519582; Mon, 23 Jun 2008 16:58:39 -0700 (PDT) Received: by 10.150.196.13 with HTTP; Mon, 23 Jun 2008 16:58:39 -0700 (PDT) Message-ID: Date: Mon, 23 Jun 2008 16:58:39 -0700 From: "Stanislav Shalunov" To: "John Leslie" In-Reply-To: <20080623164523.GB26944@verdi> MIME-Version: 1.0 Content-Disposition: inline References: <7335188A-BA0A-48E6-9D6B-9E4F6F09A4C6@nokia.com> <00b601c8cfb5$3aa68180$6401a8c0@china.huawei.com> <20080616173953.GF3759@verdi> <20080623164523.GB26944@verdi> X-Mailman-Approved-At: Wed, 25 Jun 2008 17:43:40 -0700 Cc: p2pi@ietf.org Subject: Re: [p2pi] Refining the ALTO problem statement X-BeenThere: p2pi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: P2P Infrastructure Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: p2pi-bounces@ietf.org Errors-To: p2pi-bounces@ietf.org On Mon, Jun 23, 2008 at 9:45 AM, John Leslie wrote: > P2P applications have good reason to want to know (instantaneous) > congestion, and what the likelihood is that the congestion will get > better or worse soon. This is the function of transport. P2P apps, by doing e2e measurements, already have pretty decent information about state of congestion, and use it just the way you'd expect. What P2P apps don't have, and what ALTO should provide, is new information -- not whether a path is congested, but whether a path is preferred by the ISP. Some simple notion of cost or preferred ASes or IP prefixes or whatnot. This is information that the routing layer has and that the overlay routing in P2P has no access to. -- Stanislav Shalunov http://shlang.com/ _______________________________________________ p2pi mailing list p2pi@ietf.org https://www.ietf.org/mailman/listinfo/p2pi From p2pi-bounces@ietf.org Thu Jun 26 10: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 2091A3A6A39; Thu, 26 Jun 2008 10: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 900173A6A1A for ; Thu, 26 Jun 2008 10:55:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.265 X-Spam-Level: X-Spam-Status: No, score=-10.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HABEAS_ACCREDITED_COI=-8, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2QMeYo6JO2Ik for ; Thu, 26 Jun 2008 10:55:07 -0700 (PDT) Received: from dkny.pando.com (dkny.pando.com [67.99.55.163]) by core3.amsl.com (Postfix) with ESMTP id B7AEB3A6947 for ; Thu, 26 Jun 2008 10:55:04 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by dkny.pando.com (Postfix) with ESMTP id A0EB8E10C1E; Thu, 26 Jun 2008 13:55:03 -0400 (EDT) X-Virus-Scanned: amavisd-new at Received: from dkny.pando.com ([127.0.0.1]) by localhost (dkny.pando.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kk1e+1hE+n6k; Thu, 26 Jun 2008 13:54:48 -0400 (EDT) Received: from dkny.pando.com (dkny.pando.com [10.10.60.11]) by dkny.pando.com (Postfix) with ESMTP id E9EFCE10B99; Thu, 26 Jun 2008 13:54:48 -0400 (EDT) Date: Thu, 26 Jun 2008 13:54:48 -0400 (EDT) From: Laird Popkin To: Stanislav Shalunov Message-ID: <1656028167.439081214502888936.JavaMail.root@dkny.pando.com> In-Reply-To: MIME-Version: 1.0 X-Originating-IP: [71.187.207.81] Cc: p2pi@ietf.org Subject: Re: [p2pi] Refining the ALTO problem statement X-BeenThere: p2pi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: P2P Infrastructure Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: p2pi-bounces@ietf.org Errors-To: p2pi-bounces@ietf.org I agree with Stanislav's main point (ALTO should focus on providing new information). We've had extensive email chains listing such opportunities, so no need to repeat them here. That being said, there's some value in knowing about congestion more precisely than we do now. In particular, it would be good to know when: 1) The user's internet connection is saturated (and in which direction) so that the application as a whole can reduce bandwidth to de-saturate the link. Many p2p apps do this now, but the techniques for attempting to indirectly detect 'edge' link saturation are inconsistent in their effectiveness. If the edge router could tell app's the precise situation, that would help app's avoid saturating links while maximizing performance. 2) A specific TCP stream to a specific peer is saturated, in which case we should slow down that stream and pull more data from elsewhere. Re-ECN looks like it'll address the latter scenario. What's the relationship (if any) between Re-ECN and ALTO? - Laird Popkin, CTO, Pando Networks mobile: 646/465-0570 ----- Original Message ----- From: "Stanislav Shalunov" To: "John Leslie" Cc: p2pi@ietf.org Sent: Monday, June 23, 2008 7:58:39 PM (GMT-0500) America/New_York Subject: Re: [p2pi] Refining the ALTO problem statement On Mon, Jun 23, 2008 at 9:45 AM, John Leslie wrote: > P2P applications have good reason to want to know (instantaneous) > congestion, and what the likelihood is that the congestion will get > better or worse soon. This is the function of transport. P2P apps, by doing e2e measurements, already have pretty decent information about state of congestion, and use it just the way you'd expect. What P2P apps don't have, and what ALTO should provide, is new information -- not whether a path is congested, but whether a path is preferred by the ISP. Some simple notion of cost or preferred ASes or IP prefixes or whatnot. This is information that the routing layer has and that the overlay routing in P2P has no access to. -- Stanislav Shalunov http://shlang.com/ _______________________________________________ p2pi mailing list p2pi@ietf.org https://www.ietf.org/mailman/listinfo/p2pi _______________________________________________ p2pi mailing list p2pi@ietf.org https://www.ietf.org/mailman/listinfo/p2pi From p2pi-bounces@ietf.org Thu Jun 26 11:17:08 2008 Return-Path: X-Original-To: p2pi-archive@ietf.org Delivered-To: ietfarch-p2pi-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 103BF3A6B19; Thu, 26 Jun 2008 11:17:08 -0700 (PDT) X-Original-To: p2pi@core3.amsl.com Delivered-To: p2pi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8E8B83A690C for ; Thu, 26 Jun 2008 11:17:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PPmNZ+80up1v for ; Thu, 26 Jun 2008 11:17:06 -0700 (PDT) Received: from av-tac-bru.cisco.com (odd-brew.cisco.com [144.254.15.119]) by core3.amsl.com (Postfix) with ESMTP id EAF5D3A6872 for ; Thu, 26 Jun 2008 11:16:13 -0700 (PDT) X-TACSUNS: Virus Scanned Received: from strange-brew.cisco.com (localhost [127.0.0.1]) by av-tac-bru.cisco.com (8.11.7p3+Sun/8.11.7) with ESMTP id m5QIGBn02848; Thu, 26 Jun 2008 20:16:11 +0200 (CEST) Received: from [192.168.0.100] (ams3-vpn-dhcp4148.cisco.com [10.61.80.51]) by strange-brew.cisco.com (8.11.7p3+Sun/8.11.7) with ESMTP id m5QIGAA23004; Thu, 26 Jun 2008 20:16:10 +0200 (CEST) User-Agent: Microsoft-Entourage/11.4.0.080122 Date: Thu, 26 Jun 2008 20:16:02 +0200 From: stefano previdi To: Laird Popkin , Stanislav Shalunov Message-ID: Thread-Topic: [p2pi] Refining the ALTO problem statement Thread-Index: AcjXuLDJ75rIyUOrEd2D2QAX8vOM8g== In-Reply-To: <1656028167.439081214502888936.JavaMail.root@dkny.pando.com> Mime-version: 1.0 Cc: p2pi@ietf.org Subject: Re: [p2pi] Refining the ALTO problem statement X-BeenThere: p2pi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: P2P Infrastructure Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: p2pi-bounces@ietf.org Errors-To: p2pi-bounces@ietf.org > From: Laird Popkin > > I agree with Stanislav's main point (ALTO should focus on providing new > information). We've had extensive email chains listing such opportunities, so > no need to repeat them here. > > That being said, there's some value in knowing about congestion more precisely > than we do now. In particular, it would be good to know when: > > 1) The user's internet connection is saturated (and in which direction) so > that the application as a whole can reduce bandwidth to de-saturate the link. > Many p2p apps do this now, but the techniques for attempting to indirectly > detect 'edge' link saturation are inconsistent in their effectiveness. If the > edge router could tell app's the precise situation, that would help app's > avoid saturating links while maximizing performance. it's a matter of trade-off in terms of complexity for retrieving the information at that granularity level you need it and the improved correctness/usefulness of it. IOW: what you get now may be good enough already. > 2) A specific TCP stream to a specific peer is saturated, in which case we > should slow down that stream and pull more data from elsewhere. Re-ECN looks > like it'll address the latter scenario. What's the relationship (if any) > between Re-ECN and ALTO? I wonder if we have a granularity problem here. A given app/p2p client may be interested into path characteristics for the flow is going to originate/receive. However, the provider infrastructure may not (easily/consistently) deliver this level of visibility (measuring the impact of a few Mb flow over a multi-Gb backbone). > From: "Stanislav Shalunov" > > This is the function of transport. P2P apps, by doing e2e > measurements, already have pretty decent information about state of > congestion, and use it just the way you'd expect. > > What P2P apps don't have, and what ALTO should provide, is new > information -- not whether a path is congested, but whether a path is > preferred by the ISP. Some simple notion of cost or preferred ASes or > IP prefixes or whatnot. > > This is information that the routing layer has and that the overlay > routing in P2P has no access to. I definitely subscribe to this. s. > > -- > Stanislav Shalunov > http://shlang.com/ > _______________________________________________ > p2pi mailing list > p2pi@ietf.org > https://www.ietf.org/mailman/listinfo/p2pi > _______________________________________________ > p2pi mailing list > p2pi@ietf.org > https://www.ietf.org/mailman/listinfo/p2pi _______________________________________________ p2pi mailing list p2pi@ietf.org https://www.ietf.org/mailman/listinfo/p2pi From p2pi-bounces@ietf.org Thu Jun 26 11:56: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 14F963A6802; Thu, 26 Jun 2008 11:56: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 56B0F3A6937 for ; Thu, 26 Jun 2008 11:56:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.265 X-Spam-Level: X-Spam-Status: No, score=-10.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HABEAS_ACCREDITED_COI=-8, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aMrp3jBbwVpT for ; Thu, 26 Jun 2008 11:56:04 -0700 (PDT) Received: from dkny.pando.com (dkny.pando.com [67.99.55.163]) by core3.amsl.com (Postfix) with ESMTP id BBF2C3A6802 for ; Thu, 26 Jun 2008 11:56:03 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by dkny.pando.com (Postfix) with ESMTP id AC4ABE10C3A; Thu, 26 Jun 2008 14:56:04 -0400 (EDT) X-Virus-Scanned: amavisd-new at Received: from dkny.pando.com ([127.0.0.1]) by localhost (dkny.pando.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5zj0dEHaYMU1; Thu, 26 Jun 2008 14:55:46 -0400 (EDT) Received: from dkny.pando.com (dkny.pando.com [10.10.60.11]) by dkny.pando.com (Postfix) with ESMTP id 6350FE10C2A; Thu, 26 Jun 2008 14:55:46 -0400 (EDT) Date: Thu, 26 Jun 2008 14:55:46 -0400 (EDT) From: Laird Popkin To: stefano previdi Message-ID: <1919377032.439661214506546365.JavaMail.root@dkny.pando.com> In-Reply-To: <868806184.439611214506011794.JavaMail.root@dkny.pando.com> MIME-Version: 1.0 X-Originating-IP: [71.187.207.81] Cc: p2pi@ietf.org, Stanislav Shalunov Subject: Re: [p2pi] Refining the ALTO problem statement X-BeenThere: p2pi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: P2P Infrastructure Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: p2pi-bounces@ietf.org Errors-To: p2pi-bounces@ietf.org - Laird Popkin, CTO, Pando Networks mobile: 646/465-0570 ----- Original Message ----- From: "stefano previdi" To: "Laird Popkin" , "Stanislav Shalunov" Cc: p2pi@ietf.org Sent: Thursday, June 26, 2008 2:16:02 PM (GMT-0500) America/New_York Subject: Re: [p2pi] Refining the ALTO problem statement > From: Laird Popkin > > I agree with Stanislav's main point (ALTO should focus on providing new > information). We've had extensive email chains listing such opportunities, so > no need to repeat them here. > > That being said, there's some value in knowing about congestion more precisely > than we do now. In particular, it would be good to know when: > > 1) The user's internet connection is saturated (and in which direction) so > that the application as a whole can reduce bandwidth to de-saturate the link. > Many p2p apps do this now, but the techniques for attempting to indirectly > detect 'edge' link saturation are inconsistent in their effectiveness. If the > edge router could tell app's the precise situation, that would help app's > avoid saturating links while maximizing performance. it's a matter of trade-off in terms of complexity for retrieving the information at that granularity level you need it and the improved correctness/usefulness of it. IOW: what you get now may be good enough already. LP: The techniques for detecting edge link saturation are pretty inconsistent. For example, if you ping a router near the edge, the ping times might vary due to link saturation, or due to the router being busy doing more important things than responding to a ping (e.g. routing other traffic, router reconfiguration), etc. So (unless I've missed some fantastic technique that I'd love to know about) the current strategies aren't very good, so there's room for improvement. At any rate, the RTT time numbers for users behind saturated home/edge routers that Stanislav presented at the P2Pi Workshop were alarming enough to me that I think we should think about ways to alleviate this issue. > 2) A specific TCP stream to a specific peer is saturated, in which case we > should slow down that stream and pull more data from elsewhere. Re-ECN looks > like it'll address the latter scenario. What's the relationship (if any) > between Re-ECN and ALTO? I wonder if we have a granularity problem here. A given app/p2p client may be interested into path characteristics for the flow is going to originate/receive. However, the provider infrastructure may not (easily/consistently) deliver this level of visibility (measuring the impact of a few Mb flow over a multi-Gb backbone). LP: Re-ECN (http://www.cs.ucl.ac.uk/staff/bbriscoe/projects/refb/) doesn't predict anything, and (unless I misread the doc's) has no global knowledge - it's a mechanism allowing routers to report to the endpoints of a TCP stream that the stream is currently dropping packets due to congestion. This is useful because p2p apps could then differentiate between a slow but reliable stream that should continue as-is and a congested link where we may want to 'back off' so that the congestion can potentially be alleviated. This could (for example) allow downloaders to request less data from uploaders with saturated links, making them (and potentially their neighbors) happier. Admittedly the saturation could occur anywhere in the stream, but as long as there are a sufficient number of peer data sources, pulling less data from saturated streams seems like it's good for everyone. Certainly having the information exposed so that applications could at least have the potential to alleviate congestion seems like a good idea. > From: "Stanislav Shalunov" > > This is the function of transport. P2P apps, by doing e2e > measurements, already have pretty decent information about state of > congestion, and use it just the way you'd expect. > > What P2P apps don't have, and what ALTO should provide, is new > information -- not whether a path is congested, but whether a path is > preferred by the ISP. Some simple notion of cost or preferred ASes or > IP prefixes or whatnot. > > This is information that the routing layer has and that the overlay > routing in P2P has no access to. I definitely subscribe to this. s. > > -- > Stanislav Shalunov > http://shlang.com/ > _______________________________________________ > p2pi mailing list > p2pi@ietf.org > https://www.ietf.org/mailman/listinfo/p2pi > _______________________________________________ > p2pi mailing list > p2pi@ietf.org > https://www.ietf.org/mailman/listinfo/p2pi _______________________________________________ p2pi mailing list p2pi@ietf.org https://www.ietf.org/mailman/listinfo/p2pi From p2pi-bounces@ietf.org Thu Jun 26 14:21: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 7C4533A68F8; Thu, 26 Jun 2008 14:21: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 A53F03A68F8 for ; Thu, 26 Jun 2008 14:21:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AZjwzjT-Tdya for ; Thu, 26 Jun 2008 14:21:26 -0700 (PDT) Received: from wf-out-1314.google.com (wf-out-1314.google.com [209.85.200.171]) by core3.amsl.com (Postfix) with ESMTP id 5F2033A67D0 for ; Thu, 26 Jun 2008 14:21:26 -0700 (PDT) Received: by wf-out-1314.google.com with SMTP id 27so193162wfd.31 for ; Thu, 26 Jun 2008 14:21:29 -0700 (PDT) Received: by 10.143.31.4 with SMTP id i4mr152398wfj.87.1214515289831; Thu, 26 Jun 2008 14:21:29 -0700 (PDT) Received: from ?192.168.1.103? ( [67.188.243.194]) by mx.google.com with ESMTPS id 30sm1051478wfd.1.2008.06.26.14.21.28 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 26 Jun 2008 14:21:29 -0700 (PDT) Message-Id: <0E777DCE-2C7D-4026-996C-F26839D3F18D@bittorrent.com> From: Stanislav Shalunov To: Laird Popkin In-Reply-To: <1656028167.439081214502888936.JavaMail.root@dkny.pando.com> Mime-Version: 1.0 (Apple Message framework v924) Date: Thu, 26 Jun 2008 14:21:27 -0700 References: <1656028167.439081214502888936.JavaMail.root@dkny.pando.com> X-Mailer: Apple Mail (2.924) Cc: p2pi@ietf.org Subject: Re: [p2pi] Refining the ALTO problem statement X-BeenThere: p2pi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: P2P Infrastructure Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: p2pi-bounces@ietf.org Errors-To: p2pi-bounces@ietf.org Knowledge about congestion is a transport topic. Improvements in transport are possible, and, I would argue, necessary. Congestion information is useful on entirely different timescales and is a very different problem. An uncongested path may well be congested seconds later. An inexpensive path is likely to remain such tomorrow and even a week later. Congestion pricing and variations of ECN to achieve it is a very interesting topic, but not an ALTO topic. -- Stanislav Shalunov http://shlang.com On Jun 26, 2008, at 10:54 AM, Laird Popkin wrote: > I agree with Stanislav's main point (ALTO should focus on providing > new information). We've had extensive email chains listing such > opportunities, so no need to repeat them here. > > That being said, there's some value in knowing about congestion more > precisely than we do now. In particular, it would be good to know > when: > > 1) The user's internet connection is saturated (and in which > direction) so that the application as a whole can reduce bandwidth > to de-saturate the link. Many p2p apps do this now, but the > techniques for attempting to indirectly detect 'edge' link > saturation are inconsistent in their effectiveness. If the edge > router could tell app's the precise situation, that would help app's > avoid saturating links while maximizing performance. > > 2) A specific TCP stream to a specific peer is saturated, in which > case we should slow down that stream and pull more data from > elsewhere. Re-ECN looks like it'll address the latter scenario. > What's the relationship (if any) between Re-ECN and ALTO? > > - Laird Popkin, CTO, Pando Networks > mobile: 646/465-0570 > > ----- Original Message ----- > From: "Stanislav Shalunov" > To: "John Leslie" > Cc: p2pi@ietf.org > Sent: Monday, June 23, 2008 7:58:39 PM (GMT-0500) America/New_York > Subject: Re: [p2pi] Refining the ALTO problem statement > > On Mon, Jun 23, 2008 at 9:45 AM, John Leslie wrote: >> P2P applications have good reason to want to know (instantaneous) >> congestion, and what the likelihood is that the congestion will get >> better or worse soon. > > This is the function of transport. P2P apps, by doing e2e > measurements, already have pretty decent information about state of > congestion, and use it just the way you'd expect. > > What P2P apps don't have, and what ALTO should provide, is new > information -- not whether a path is congested, but whether a path is > preferred by the ISP. Some simple notion of cost or preferred ASes or > IP prefixes or whatnot. > > This is information that the routing layer has and that the overlay > routing in P2P has no access to. > > -- > Stanislav Shalunov > http://shlang.com/ > _______________________________________________ > p2pi mailing list > p2pi@ietf.org > https://www.ietf.org/mailman/listinfo/p2pi _______________________________________________ p2pi mailing list p2pi@ietf.org https://www.ietf.org/mailman/listinfo/p2pi From p2pi-bounces@ietf.org Fri Jun 27 00:15:05 2008 Return-Path: X-Original-To: p2pi-archive@ietf.org Delivered-To: ietfarch-p2pi-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 63B203A6A00; Fri, 27 Jun 2008 00:15:05 -0700 (PDT) X-Original-To: p2pi@core3.amsl.com Delivered-To: p2pi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 311BF3A6A31 for ; Fri, 27 Jun 2008 00:15:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.525 X-Spam-Level: X-Spam-Status: No, score=-6.525 tagged_above=-999 required=5 tests=[AWL=0.074, 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 Cu8PF7ZkXIHN for ; Fri, 27 Jun 2008 00:15:03 -0700 (PDT) Received: from mgw-mx06.nokia.com (smtp.nokia.com [192.100.122.233]) by core3.amsl.com (Postfix) with ESMTP id C0EBC3A6A00 for ; Fri, 27 Jun 2008 00:14:59 -0700 (PDT) Received: from esebh107.NOE.Nokia.com (esebh107.ntc.nokia.com [172.21.143.143]) by mgw-mx06.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id m5R7EMTS017876; Fri, 27 Jun 2008 10:14:26 +0300 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 27 Jun 2008 10:14:21 +0300 Received: from net-99.nrpn.net ([10.241.184.208]) by esebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Fri, 27 Jun 2008 10:14:20 +0300 Message-Id: <461904A5-603E-4F66-A982-5078E6EA1895@nokia.com> From: Lars Eggert To: ext Stanislav Shalunov In-Reply-To: <0E777DCE-2C7D-4026-996C-F26839D3F18D@bittorrent.com> Mime-Version: 1.0 (Apple Message framework v924) Date: Fri, 27 Jun 2008 10:14:15 +0300 References: <1656028167.439081214502888936.JavaMail.root@dkny.pando.com> <0E777DCE-2C7D-4026-996C-F26839D3F18D@bittorrent.com> X-Mailer: Apple Mail (2.924) X-OriginalArrivalTime: 27 Jun 2008 07:14:21.0233 (UTC) FILETIME=[6BB2D210:01C8D825] X-Nokia-AV: Clean Cc: p2pi@ietf.org Subject: Re: [p2pi] Refining the ALTO problem statement X-BeenThere: p2pi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: P2P Infrastructure Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: p2pi-bounces@ietf.org Errors-To: p2pi-bounces@ietf.org On 2008-6-27, at 0:21, ext Stanislav Shalunov wrote: > Knowledge about congestion is a transport topic. Improvements in > transport are possible, and, I would argue, necessary. Congestion > information is useful on entirely different timescales and is a very > different problem. An uncongested path may well be congested > seconds later. An inexpensive path is likely to remain such > tomorrow and even a week later. > > Congestion pricing and variations of ECN to achieve it is a very > interesting topic, but not an ALTO topic. It will surprise nobody that I fully agree with Stas. Lars > > > -- > Stanislav Shalunov > http://shlang.com > > On Jun 26, 2008, at 10:54 AM, Laird Popkin wrote: > >> I agree with Stanislav's main point (ALTO should focus on providing >> new information). We've had extensive email chains listing such >> opportunities, so no need to repeat them here. >> >> That being said, there's some value in knowing about congestion >> more precisely than we do now. In particular, it would be good to >> know when: >> >> 1) The user's internet connection is saturated (and in which >> direction) so that the application as a whole can reduce bandwidth >> to de-saturate the link. Many p2p apps do this now, but the >> techniques for attempting to indirectly detect 'edge' link >> saturation are inconsistent in their effectiveness. If the edge >> router could tell app's the precise situation, that would help >> app's avoid saturating links while maximizing performance. >> >> 2) A specific TCP stream to a specific peer is saturated, in which >> case we should slow down that stream and pull more data from >> elsewhere. Re-ECN looks like it'll address the latter scenario. >> What's the relationship (if any) between Re-ECN and ALTO? >> >> - Laird Popkin, CTO, Pando Networks >> mobile: 646/465-0570 >> >> ----- Original Message ----- >> From: "Stanislav Shalunov" >> To: "John Leslie" >> Cc: p2pi@ietf.org >> Sent: Monday, June 23, 2008 7:58:39 PM (GMT-0500) America/New_York >> Subject: Re: [p2pi] Refining the ALTO problem statement >> >> On Mon, Jun 23, 2008 at 9:45 AM, John Leslie wrote: >>> P2P applications have good reason to want to know (instantaneous) >>> congestion, and what the likelihood is that the congestion will get >>> better or worse soon. >> >> This is the function of transport. P2P apps, by doing e2e >> measurements, already have pretty decent information about state of >> congestion, and use it just the way you'd expect. >> >> What P2P apps don't have, and what ALTO should provide, is new >> information -- not whether a path is congested, but whether a path is >> preferred by the ISP. Some simple notion of cost or preferred ASes >> or >> IP prefixes or whatnot. >> >> This is information that the routing layer has and that the overlay >> routing in P2P has no access to. >> >> -- >> Stanislav Shalunov >> http://shlang.com/ >> _______________________________________________ >> p2pi mailing list >> p2pi@ietf.org >> https://www.ietf.org/mailman/listinfo/p2pi > > _______________________________________________ > p2pi mailing list > p2pi@ietf.org > https://www.ietf.org/mailman/listinfo/p2pi _______________________________________________ p2pi mailing list p2pi@ietf.org https://www.ietf.org/mailman/listinfo/p2pi From p2pi-bounces@ietf.org Fri Jun 27 05:42: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 43B743A67F5; Fri, 27 Jun 2008 05:42: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 BAB893A67F5 for ; Fri, 27 Jun 2008 05:42:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.265 X-Spam-Level: X-Spam-Status: No, score=-10.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HABEAS_ACCREDITED_COI=-8, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7smN+hedGdHC for ; Fri, 27 Jun 2008 05:42:16 -0700 (PDT) Received: from dkny.pando.com (dkny.pando.com [67.99.55.163]) by core3.amsl.com (Postfix) with ESMTP id 723FA3A67A7 for ; Fri, 27 Jun 2008 05:42:13 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by dkny.pando.com (Postfix) with ESMTP id 47AF8E10AFD; Fri, 27 Jun 2008 08:42:05 -0400 (EDT) X-Virus-Scanned: amavisd-new at Received: from dkny.pando.com ([127.0.0.1]) by localhost (dkny.pando.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NuRLek3kJ31o; Fri, 27 Jun 2008 08:41:52 -0400 (EDT) Received: from dkny.pando.com (dkny.pando.com [10.10.60.11]) by dkny.pando.com (Postfix) with ESMTP id 04660E10AFB; Fri, 27 Jun 2008 08:41:52 -0400 (EDT) Date: Fri, 27 Jun 2008 08:41:51 -0400 (EDT) From: Laird Popkin To: Lars Eggert Message-ID: <1896440527.443251214570511993.JavaMail.root@dkny.pando.com> In-Reply-To: <2135807016.443091214569923186.JavaMail.root@dkny.pando.com> MIME-Version: 1.0 X-Originating-IP: [71.187.207.81] Cc: p2pi@ietf.org Subject: Re: [p2pi] Refining the ALTO problem statement X-BeenThere: p2pi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: P2P Infrastructure Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: p2pi-bounces@ietf.org Errors-To: p2pi-bounces@ietf.org I think that we're all in violent agreement in the distinction between long-term network status (e.g. topology, capacity, distance, cost) and transient status (e.g. congestion). Specifically, I think that we agress that "oracles" should focus on long-term network status and not transient status (e.g. congestion). But where I'm not sure that we agree is in the definition of ALTO's scope. There are many kinds of transport-level information that are valuable to expose to the application layer that aren't being addressed by other efforts (AFAIK). So while Re-ECN communicates stream-level congestion status, I believe that there is also value in exposing "last mile" link status (and capacity, quotas, etc.) to applications to assist them in making better decisions (e.g. avoiding 'last mile' link congestion, avoiding running consumers over their quotas, etc.). So while arguably last-mile link congestion is a "transport layer" issue, if it's not addressed elsewhere, perhaps ALTO should address it? - Laird Popkin, CTO, Pando Networks mobile: 646/465-0570 ----- Original Message ----- From: "Lars Eggert" To: "ext Stanislav Shalunov" Cc: "Laird Popkin" , p2pi@ietf.org Sent: Friday, June 27, 2008 3:14:15 AM (GMT-0500) America/New_York Subject: Re: [p2pi] Refining the ALTO problem statement On 2008-6-27, at 0:21, ext Stanislav Shalunov wrote: > Knowledge about congestion is a transport topic. Improvements in > transport are possible, and, I would argue, necessary. Congestion > information is useful on entirely different timescales and is a very > different problem. An uncongested path may well be congested > seconds later. An inexpensive path is likely to remain such > tomorrow and even a week later. > > Congestion pricing and variations of ECN to achieve it is a very > interesting topic, but not an ALTO topic. It will surprise nobody that I fully agree with Stas. Lars > > > -- > Stanislav Shalunov > http://shlang.com > > On Jun 26, 2008, at 10:54 AM, Laird Popkin wrote: > >> I agree with Stanislav's main point (ALTO should focus on providing >> new information). We've had extensive email chains listing such >> opportunities, so no need to repeat them here. >> >> That being said, there's some value in knowing about congestion >> more precisely than we do now. In particular, it would be good to >> know when: >> >> 1) The user's internet connection is saturated (and in which >> direction) so that the application as a whole can reduce bandwidth >> to de-saturate the link. Many p2p apps do this now, but the >> techniques for attempting to indirectly detect 'edge' link >> saturation are inconsistent in their effectiveness. If the edge >> router could tell app's the precise situation, that would help >> app's avoid saturating links while maximizing performance. >> >> 2) A specific TCP stream to a specific peer is saturated, in which >> case we should slow down that stream and pull more data from >> elsewhere. Re-ECN looks like it'll address the latter scenario. >> What's the relationship (if any) between Re-ECN and ALTO? >> >> - Laird Popkin, CTO, Pando Networks >> mobile: 646/465-0570 >> >> ----- Original Message ----- >> From: "Stanislav Shalunov" >> To: "John Leslie" >> Cc: p2pi@ietf.org >> Sent: Monday, June 23, 2008 7:58:39 PM (GMT-0500) America/New_York >> Subject: Re: [p2pi] Refining the ALTO problem statement >> >> On Mon, Jun 23, 2008 at 9:45 AM, John Leslie wrote: >>> P2P applications have good reason to want to know (instantaneous) >>> congestion, and what the likelihood is that the congestion will get >>> better or worse soon. >> >> This is the function of transport. P2P apps, by doing e2e >> measurements, already have pretty decent information about state of >> congestion, and use it just the way you'd expect. >> >> What P2P apps don't have, and what ALTO should provide, is new >> information -- not whether a path is congested, but whether a path is >> preferred by the ISP. Some simple notion of cost or preferred ASes >> or >> IP prefixes or whatnot. >> >> This is information that the routing layer has and that the overlay >> routing in P2P has no access to. >> >> -- >> Stanislav Shalunov >> http://shlang.com/ >> _______________________________________________ >> p2pi mailing list >> p2pi@ietf.org >> https://www.ietf.org/mailman/listinfo/p2pi > > _______________________________________________ > p2pi mailing list > p2pi@ietf.org > https://www.ietf.org/mailman/listinfo/p2pi _______________________________________________ p2pi mailing list p2pi@ietf.org https://www.ietf.org/mailman/listinfo/p2pi From p2pi-bounces@ietf.org Fri Jun 27 06:01:39 2008 Return-Path: X-Original-To: p2pi-archive@ietf.org Delivered-To: ietfarch-p2pi-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2655E3A6846; Fri, 27 Jun 2008 06:01:39 -0700 (PDT) X-Original-To: p2pi@core3.amsl.com Delivered-To: p2pi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5BF553A67A7 for ; Fri, 27 Jun 2008 06:01:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.537 X-Spam-Level: X-Spam-Status: No, score=-6.537 tagged_above=-999 required=5 tests=[AWL=0.062, 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 SDRIRouCmwpD for ; Fri, 27 Jun 2008 06:01:36 -0700 (PDT) Received: from mgw-mx06.nokia.com (smtp.nokia.com [192.100.122.233]) by core3.amsl.com (Postfix) with ESMTP id 43C673A63EC for ; Fri, 27 Jun 2008 06:01:36 -0700 (PDT) Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-mx06.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id m5RD0xxR000366; Fri, 27 Jun 2008 16:01:09 +0300 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 27 Jun 2008 16:00:47 +0300 Received: from net-99.nrpn.net ([10.241.184.208]) by esebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Fri, 27 Jun 2008 16:00:46 +0300 Message-Id: From: Lars Eggert To: ext Laird Popkin In-Reply-To: <1896440527.443251214570511993.JavaMail.root@dkny.pando.com> Mime-Version: 1.0 (Apple Message framework v924) Date: Fri, 27 Jun 2008 16:00:41 +0300 References: <1896440527.443251214570511993.JavaMail.root@dkny.pando.com> X-Mailer: Apple Mail (2.924) X-OriginalArrivalTime: 27 Jun 2008 13:00:47.0466 (UTC) FILETIME=[D14244A0:01C8D855] X-Nokia-AV: Clean Cc: p2pi@ietf.org Subject: Re: [p2pi] Refining the ALTO problem statement X-BeenThere: p2pi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: P2P Infrastructure Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: p2pi-bounces@ietf.org Errors-To: p2pi-bounces@ietf.org Hi, On 2008-6-27, at 15:41, ext Laird Popkin wrote: > I think that we're all in violent agreement in the distinction > between long-term network status (e.g. topology, capacity, distance, > cost) and transient status (e.g. congestion). I think we are, although I'd question whether capacity is long-term status. If you mean capacity as in "the potential capacity of the bottleneck link along a path", then probably yes, but if you mean "currently available bottleneck capacity", then likely not. > I believe that there is also value in exposing "last mile" link > status (and capacity, quotas, etc.) to applications to assist them > in making better decisions (e.g. avoiding 'last mile' link > congestion, avoiding running consumers over their quotas, etc.). So > while arguably last-mile link congestion is a "transport layer" > issue, if it's not addressed elsewhere, perhaps ALTO should address > it? ALTO, as a BOF targeted at the RAI and APP areas, is not the right place to discuss these issues. Transport area topics do need to be discussed in transport area meetings. The original proposal for the transport-area TANA BOF, which came out before there was public information about ALTO, had a similar work item, because it seemed likely after the P2PI workshop that folks would want to discuss mechanisms related to transient network status. When the ALTO proposal was submitted, the ADs decided it would make more sense to split the work items identified at the P2PI workshop into things for TANA and things for ALTO, but it was at least my understanding that this split came with an agreement that obviously transport-related topics would be out of scope for ALTO. Lars _______________________________________________ p2pi mailing list p2pi@ietf.org https://www.ietf.org/mailman/listinfo/p2pi From p2pi-bounces@ietf.org Fri Jun 27 07:31: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 A44073A699A; Fri, 27 Jun 2008 07:31:18 -0700 (PDT) X-Original-To: p2pi@core3.amsl.com Delivered-To: p2pi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E80AE3A699A for ; Fri, 27 Jun 2008 07:31:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.265 X-Spam-Level: X-Spam-Status: No, score=-10.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HABEAS_ACCREDITED_COI=-8, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J0EyO4K1fMau for ; Fri, 27 Jun 2008 07:31:14 -0700 (PDT) Received: from dkny.pando.com (dkny.pando.com [67.99.55.163]) by core3.amsl.com (Postfix) with ESMTP id 124633A6861 for ; Fri, 27 Jun 2008 07:31:12 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by dkny.pando.com (Postfix) with ESMTP id 60729E10B17; Fri, 27 Jun 2008 10:31:07 -0400 (EDT) X-Virus-Scanned: amavisd-new at Received: from dkny.pando.com ([127.0.0.1]) by localhost (dkny.pando.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d0y-qT9tD+Qy; Fri, 27 Jun 2008 10:30:59 -0400 (EDT) Received: from dkny.pando.com (dkny.pando.com [10.10.60.11]) by dkny.pando.com (Postfix) with ESMTP id 1D641E10AFB; Fri, 27 Jun 2008 10:30:59 -0400 (EDT) Date: Fri, 27 Jun 2008 10:30:59 -0400 (EDT) From: Laird Popkin To: Lars Eggert Message-ID: <762072025.443831214577059088.JavaMail.root@dkny.pando.com> In-Reply-To: <112114914.443811214576908025.JavaMail.root@dkny.pando.com> MIME-Version: 1.0 X-Originating-IP: [71.187.207.81] Cc: p2pi@ietf.org Subject: Re: [p2pi] Refining the ALTO problem statement X-BeenThere: p2pi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: P2P Infrastructure Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: p2pi-bounces@ietf.org Errors-To: p2pi-bounces@ietf.org - Laird Popkin, CTO, Pando Networks mobile: 646/465-0570 ----- Original Message ----- From: "Lars Eggert" To: "ext Laird Popkin" Cc: p2pi@ietf.org, "ext Stanislav Shalunov" Sent: Friday, June 27, 2008 9:00:41 AM (GMT-0500) America/New_York Subject: Re: [p2pi] Refining the ALTO problem statement Hi, On 2008-6-27, at 15:41, ext Laird Popkin wrote: > I think that we're all in violent agreement in the distinction > between long-term network status (e.g. topology, capacity, distance, > cost) and transient status (e.g. congestion). I think we are, although I'd question whether capacity is long-term status. If you mean capacity as in "the potential capacity of the bottleneck link along a path", then probably yes, but if you mean "currently available bottleneck capacity", then likely not. LP: I was thinking of "capacity that an ISP wants to direct P2P through", which would be a combination of typical available capacity and business policies (e.g. run p2p through peering links to balance traffic, keep p2p downloads off of links intended for VOIP). This information would be slowly changing, perhaps varying by time of day (e.g. daytime and nighttime traffic are different) or as network physical infrastructure is deployed (or links go down, etc.). > I believe that there is also value in exposing "last mile" link > status (and capacity, quotas, etc.) to applications to assist them > in making better decisions (e.g. avoiding 'last mile' link > congestion, avoiding running consumers over their quotas, etc.). So > while arguably last-mile link congestion is a "transport layer" > issue, if it's not addressed elsewhere, perhaps ALTO should address > it? ALTO, as a BOF targeted at the RAI and APP areas, is not the right place to discuss these issues. Transport area topics do need to be discussed in transport area meetings. The original proposal for the transport-area TANA BOF, which came out before there was public information about ALTO, had a similar work item, because it seemed likely after the P2PI workshop that folks would want to discuss mechanisms related to transient network status. When the ALTO proposal was submitted, the ADs decided it would make more sense to split the work items identified at the P2PI workshop into things for TANA and things for ALTO, but it was at least my understanding that this split came with an agreement that obviously transport-related topics would be out of scope for ALTO. LP: Thanks, this is very helpful. I wasn't clear on the distinction between ALTO and TANA BOF's - the descriptions in the email archives seem to overlap somewhat. Is there a list of which items from the P2Pi Workshop are ALTO and which are TANA? Is there a TANA BOF meeting scheduled? If both TANA and ALTO are on the agenda in Dublin, that'd be convenient. :-) Lars _______________________________________________ p2pi mailing list p2pi@ietf.org https://www.ietf.org/mailman/listinfo/p2pi From p2pi-bounces@ietf.org Fri Jun 27 07:41:25 2008 Return-Path: X-Original-To: p2pi-archive@ietf.org Delivered-To: ietfarch-p2pi-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 59DC33A6B0B; Fri, 27 Jun 2008 07:41:25 -0700 (PDT) X-Original-To: p2pi@core3.amsl.com Delivered-To: p2pi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 773913A6B0B for ; Fri, 27 Jun 2008 07:41:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.382 X-Spam-Level: X-Spam-Status: No, score=-2.382 tagged_above=-999 required=5 tests=[AWL=0.217, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dshed6M2bcwZ for ; Fri, 27 Jun 2008 07:41:23 -0700 (PDT) Received: from ihemail1.lucent.com (ihemail1.lucent.com [135.245.0.33]) by core3.amsl.com (Postfix) with ESMTP id 5C8F33A6B04 for ; Fri, 27 Jun 2008 07:41:23 -0700 (PDT) Received: from umail.lucent.com (h135-3-40-61.lucent.com [135.3.40.61]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id m5REfNOi007548 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 27 Jun 2008 09:41:23 -0500 (CDT) Received: from [135.185.244.90] (il0015vkg1.ih.lucent.com [135.185.244.90]) by umail.lucent.com (8.13.8/TPES) with ESMTP id m5REfKA9002506; Fri, 27 Jun 2008 09:41:20 -0500 (CDT) Message-ID: <4864FC12.5040207@alcatel-lucent.com> Date: Fri, 27 Jun 2008 09:41:22 -0500 From: "Vijay K. Gurbani" Organization: Bell Labs Security Technology Research Group User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Laird Popkin References: <762072025.443831214577059088.JavaMail.root@dkny.pando.com> In-Reply-To: <762072025.443831214577059088.JavaMail.root@dkny.pando.com> X-Scanned-By: MIMEDefang 2.57 on 135.245.2.33 Cc: p2pi@ietf.org Subject: Re: [p2pi] Refining the ALTO problem statement X-BeenThere: p2pi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: P2P Infrastructure Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: p2pi-bounces@ietf.org Errors-To: p2pi-bounces@ietf.org Laird Popkin wrote: > LP: Thanks, this is very helpful. I wasn't clear on the distinction > between ALTO and TANA BOF's - the descriptions in the email archives > seem to overlap somewhat. Is there a list of which items from the > P2Pi Workshop are ALTO and which are TANA? Laird: I believe that figuring out what things go on the ALTO list and what things go on the TANA list will be one of the things to be done at the BoFs in Dublin. So far, we have the high level characterization that Lars had posted to the p2pi mailing list shortly after the MIT workshop (please see http://www.ietf.org/mail-archive/web/p2pi/current/msg00068.html). From that email, (3) is deemed to be within the purview of ALTO and (1) TANA. (2) could conceivably be split up as a set of guideline documents, some applicable to TANA and others to ALTO. > Is there a TANA BOF meeting scheduled? If both TANA and ALTO are on > the agenda in Dublin, that'd be convenient. :-) Both the BoFs have been approved by their respective ADs, and are now with the agenda director, waiting to match time slots that minimize overlaps with other WGs and AD availability. Thanks, - vijay -- Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent 2701 Lucent Lane, Rm. 9F-546, Lisle, Illinois 60532 (USA) Email: vkg@{alcatel-lucent.com,bell-labs.com,acm.org} WWW: http://www.alcatel-lucent.com/bell-labs _______________________________________________ p2pi mailing list p2pi@ietf.org https://www.ietf.org/mailman/listinfo/p2pi From p2pi-bounces@ietf.org Fri Jun 27 08:19:31 2008 Return-Path: X-Original-To: p2pi-archive@ietf.org Delivered-To: ietfarch-p2pi-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3FF2A3A6B30; Fri, 27 Jun 2008 08:19:31 -0700 (PDT) X-Original-To: p2pi@core3.amsl.com Delivered-To: p2pi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D6DED3A6B30 for ; Fri, 27 Jun 2008 08:19:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.535 X-Spam-Level: X-Spam-Status: No, score=-6.535 tagged_above=-999 required=5 tests=[AWL=0.064, 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 7N8oQt-XSloX for ; Fri, 27 Jun 2008 08:19:29 -0700 (PDT) Received: from mgw-mx06.nokia.com (smtp.nokia.com [192.100.122.233]) by core3.amsl.com (Postfix) with ESMTP id 5A64F3A6903 for ; Fri, 27 Jun 2008 08:19:29 -0700 (PDT) Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-mx06.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id m5RFJJAX032342; Fri, 27 Jun 2008 18:19:29 +0300 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 27 Jun 2008 18:10:45 +0300 Received: from net-99.nrpn.net ([10.241.184.208]) by esebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Fri, 27 Jun 2008 18:10:44 +0300 Message-Id: <77D6EDD8-779B-4887-93A6-19E4E8953334@nokia.com> From: Lars Eggert To: "ext Vijay K. Gurbani" In-Reply-To: <4864FC12.5040207@alcatel-lucent.com> Mime-Version: 1.0 (Apple Message framework v924) Date: Fri, 27 Jun 2008 18:10:39 +0300 References: <762072025.443831214577059088.JavaMail.root@dkny.pando.com> <4864FC12.5040207@alcatel-lucent.com> X-Mailer: Apple Mail (2.924) X-OriginalArrivalTime: 27 Jun 2008 15:10:45.0428 (UTC) FILETIME=[F934D740:01C8D867] X-Nokia-AV: Clean Cc: p2pi@ietf.org Subject: Re: [p2pi] Refining the ALTO problem statement X-BeenThere: p2pi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: P2P Infrastructure Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: p2pi-bounces@ietf.org Errors-To: p2pi-bounces@ietf.org Hi, On 2008-6-27, at 17:41, ext Vijay K. Gurbani wrote: > Laird Popkin wrote: >> LP: Thanks, this is very helpful. I wasn't clear on the distinction >> between ALTO and TANA BOF's - the descriptions in the email archives >> seem to overlap somewhat. Is there a list of which items from the >> P2Pi Workshop are ALTO and which are TANA? > > Laird: I believe that figuring out what things go on the ALTO list > and what things go on the TANA list will be one of the > things to be done at the BoFs in Dublin. So far, we have the > high level characterization that Lars had posted to the p2pi > mailing list shortly after the MIT workshop (please see > http://www.ietf.org/mail-archive/web/p2pi/current/msg00068.html). > From that email, (3) is deemed to be within the purview of > ALTO and (1) TANA. Exactly. > (2) could conceivably be split up as > a set of guideline documents, some applicable to TANA and > others to ALTO. I think the current plan is to discuss (2) during TANA, but that doesn't necessarily mean that any follow-up will need to only happen in whatever comes out of the TANA BOF. >> Is there a TANA BOF meeting scheduled? If both TANA and ALTO are on >> the agenda in Dublin, that'd be convenient. :-) > > Both the BoFs have been approved by their respective ADs, and are > now with the agenda director, waiting to match time slots that > minimize overlaps with other WGs and AD availability. Yup. Scheduling this will be a mess. The secretariat is currently working out things. Ideally, we'd schedule TSVAREA first, because it has an overview talk by Stas on how BitTorrent transports data, which not everyone in the IETF community is very familiar with, and which could provide some background knowledge to the wider community before they go off to participate in TANA and ALTO. Those two BOFs obviously MUST NOT conflict. Lars _______________________________________________ p2pi mailing list p2pi@ietf.org https://www.ietf.org/mailman/listinfo/p2pi From p2pi-bounces@ietf.org Fri Jun 27 11:36: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 E62203A6813; Fri, 27 Jun 2008 11:36: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 206453A679C for ; Fri, 27 Jun 2008 11:36:28 -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 OTF6hq0++B2m for ; Fri, 27 Jun 2008 11:36:27 -0700 (PDT) Received: from wa-out-1112.google.com (wa-out-1112.google.com [209.85.146.178]) by core3.amsl.com (Postfix) with ESMTP id 450013A6813 for ; Fri, 27 Jun 2008 11:36:24 -0700 (PDT) Received: by wa-out-1112.google.com with SMTP id k34so508666wah.25 for ; Fri, 27 Jun 2008 11:36:29 -0700 (PDT) Received: by 10.114.89.1 with SMTP id m1mr1856983wab.146.1214591789298; Fri, 27 Jun 2008 11:36:29 -0700 (PDT) Received: from ?192.168.1.103? ( [67.188.243.194]) by mx.google.com with ESMTPS id m5sm3008183wag.52.2008.06.27.11.36.28 (version=TLSv1/SSLv3 cipher=RC4-MD5); Fri, 27 Jun 2008 11:36:28 -0700 (PDT) Message-Id: <2F7B5A91-D3BF-4BCB-AC5F-AE9389F3291E@bittorrent.com> From: Stanislav Shalunov To: Laird Popkin In-Reply-To: <762072025.443831214577059088.JavaMail.root@dkny.pando.com> Mime-Version: 1.0 (Apple Message framework v924) Date: Fri, 27 Jun 2008 11:36:26 -0700 References: <762072025.443831214577059088.JavaMail.root@dkny.pando.com> X-Mailer: Apple Mail (2.924) Cc: p2pi@ietf.org Subject: Re: [p2pi] Refining the ALTO problem statement X-BeenThere: p2pi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: P2P Infrastructure Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: p2pi-bounces@ietf.org Errors-To: p2pi-bounces@ietf.org On Jun 27, 2008, at 7:30 AM, Laird Popkin wrote: > Is there a TANA BOF meeting scheduled? If both TANA and ALTO are on > the agenda in Dublin, that'd be convenient. :-) TANA is not yet scheduled, but should be soon now. And last-mile congestion is totally within scope for TANA. -- Stanislav Shalunov http://shlang.com _______________________________________________ p2pi mailing list p2pi@ietf.org https://www.ietf.org/mailman/listinfo/p2pi From p2pi-bounces@ietf.org Mon Jun 30 09:28:06 2008 Return-Path: X-Original-To: p2pi-archive@ietf.org Delivered-To: ietfarch-p2pi-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7DA2F3A6AF9; Mon, 30 Jun 2008 09:28:06 -0700 (PDT) X-Original-To: p2pi@core3.amsl.com Delivered-To: p2pi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2BAD03A67F4 for ; Mon, 30 Jun 2008 09:28:05 -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 O3ljwRLBf9cb for ; Mon, 30 Jun 2008 09:28:04 -0700 (PDT) Received: from maild.telecomitalia.it (maild.telecomitalia.it [156.54.233.30]) by core3.amsl.com (Postfix) with ESMTP id BF85F3A677D for ; Mon, 30 Jun 2008 09:28:03 -0700 (PDT) Received: from ptpxch008ba020.idc.cww.telecomitalia.it ([156.54.240.51]) by maild.telecomitalia.it with Microsoft SMTPSVC(6.0.3790.1830); Mon, 30 Jun 2008 18:28:13 +0200 Received: from grfhub701ba020.griffon.local ([10.188.101.111]) by ptpxch008ba020.idc.cww.telecomitalia.it with Microsoft SMTPSVC(6.0.3790.1830); Mon, 30 Jun 2008 18:28:13 +0200 Received: from [10.229.8.44] (10.229.8.44) by smtp.telecomitalia.it (10.188.101.114) with Microsoft SMTP Server (TLS) id 8.1.278.0; Mon, 30 Jun 2008 18:28:12 +0200 Message-ID: <48690985.4000906@telecomitalia.it> Date: Mon, 30 Jun 2008 18:27:49 +0200 From: Enrico Marocco User-Agent: Mozilla-Thunderbird 2.0.0.14 (X11/20080509) MIME-Version: 1.0 To: "p2pi@ietf.org" X-Enigmail-Version: 0.95.0 X-OriginalArrivalTime: 30 Jun 2008 16:28:13.0062 (UTC) FILETIME=[4AA6C260:01C8DACE] Subject: [p2pi] New version of the problem statement X-BeenThere: p2pi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: P2P Infrastructure Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1756215299==" Sender: p2pi-bounces@ietf.org Errors-To: p2pi-bounces@ietf.org --===============1756215299== Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms040008080606030108060900" --------------ms040008080606030108060900 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit An updated version of the problem statement is available at the following link: http://www.ietf.org/internet-drafts/draft-marocco-alto-problem-statement-01.txt Diffs from the previous version may be viewed at: http://tools.ietf.org//rfcdiff?url1=http://tools.ietf.org/id/draft-marocco-alto-problem-statement-00&url2=http://www.ietf.org/internet-drafts/draft-marocco-alto-problem-statement-01.txt So far, it seems there is agreement on the fact that ALTO will focus on an application-layer interface for exposing some kind of topology information to be used for optimizing traffic generated by a wide range of applications (including file-sharing, VoIP, real-time streaming.) What is probably less agreed at this time is what kind of information the protocols specified in ALTO are going to provide, whether it should be static information (e.g. from AS1, AS2 is always preferred to AS3,) dynamic information (e.g. right now the link between AS1 and AS2 is congested, peers in AS1 should prefer peers in AS3) or both. Even if such a decision is likely to be discussed after a working group is created, we would like to encourage people who have a strong opinion which they think would impact a potential charter, to express it now. Any other comments -- both substantial and editorial -- are of course welcome too. -- Ciao, Enrico --------------ms040008080606030108060900 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 hkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wODA2MzAxNjI3NDlaMCMG CSqGSIb3DQEJBDEWBBTHyb49m4UyAAsvA7U4ZT5YBo5fBzBfBgkqhkiG9w0BCQ8xUjBQMAsG CWCGSAFlAwQBAjAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAw BwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgYUGCSsGAQQBgjcQBDF4MHYwYjELMAkGA1UEBhMC WkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1Ro YXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAhAeTAANDUMJU97n0e1AWxu4MIGH BgsqhkiG9w0BCRACCzF4oHYwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25z dWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJ c3N1aW5nIENBAhAeTAANDUMJU97n0e1AWxu4MA0GCSqGSIb3DQEBAQUABIIBAELiXxUK7TTl oMEjGhiAVbrip4V9EsoTAPlLw7B5n+K6f8o39qw3mcMEgOu50BY0JsM27BX9lhM8amZcApGm inHfWw2GEiRgjqAFHIoRMhNw2Vq1JWHZ4zwx8vFXSaG1VNRMyE2altmS//f3BUjSrjq1ztCb SQ4C7HFyVQNenGXaHgTGFqn8hzA4I8NnhbMdyJTkD3hd4qyw/OqkcGt/9jIzI6tjtcBGRce9 o97DgkY3hxosu4Rg1HG3+MClwlqy7KjY79EKRdM+huHldh76w4hHu6OgnYipcylndoqIKu83 Mf0GX5KyWOhypXAYH38y07qkixZG36ybNvn2ozgaXj8AAAAAAAA= --------------ms040008080606030108060900-- --===============1756215299== 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 --===============1756215299==-- From p2pi-bounces@ietf.org Mon Jun 30 09:51: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 506213A67B6; Mon, 30 Jun 2008 09:51: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 1976B3A67B6 for ; Mon, 30 Jun 2008 09:51:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[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 h8KfhSj5jxte for ; Mon, 30 Jun 2008 09:51:07 -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 176CD3A63EC for ; Mon, 30 Jun 2008 09:51:07 -0700 (PDT) Received: by wf-out-1314.google.com with SMTP id 27so1660163wfd.31 for ; Mon, 30 Jun 2008 09:51:16 -0700 (PDT) Received: by 10.142.78.10 with SMTP id a10mr1990098wfb.37.1214844676833; Mon, 30 Jun 2008 09:51:16 -0700 (PDT) Received: from ?192.168.1.103? ( [67.188.243.194]) by mx.google.com with ESMTPS id 31sm11633683wff.16.2008.06.30.09.51.15 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 30 Jun 2008 09:51:15 -0700 (PDT) Message-Id: <54883F9F-8548-48A3-AC44-1FD3E261FEFB@bittorrent.com> From: Stanislav Shalunov To: Enrico Marocco In-Reply-To: <48690985.4000906@telecomitalia.it> Mime-Version: 1.0 (Apple Message framework v924) Date: Mon, 30 Jun 2008 09:51:13 -0700 References: <48690985.4000906@telecomitalia.it> X-Mailer: Apple Mail (2.924) Cc: "p2pi@ietf.org" Subject: Re: [p2pi] New version of the problem statement X-BeenThere: p2pi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: P2P Infrastructure Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: p2pi-bounces@ietf.org Errors-To: p2pi-bounces@ietf.org Enrico, The problem statement generally looks good. Some comments: 1. The popular metrics used by P2P applications are based on obtained goodput, not RTT. This doesn't ignore bitrate and reliability -- if it did, P2P would work much worse than it does today. It ignores cost and desires of the ISP, which is the problem ALTO needs to solve. 2. Cache location is clearly the low-hanging fruit that requires no research. It's a matter of engineering, and any decent choice of mechanism will work. We just need to agree on the mechanism. I'd like to see this stressed and moved up. 3. Would it not help to have an actual formulation of the problem somewhere? Like a sentence or a paragraph? I've trouble finding this spot. All the text says the right things, but it'd help to start with something like ALTO will solve two problems: (1) finding application caches and (2) conveying some of the information about the network already available to the routing layer up to application layer so that applications can choose better and lower-cost paths for their data. Is this the problem that your document describes? If so, it should say it. If not, it should say what the problem is. 4. Multiple solutions have indeed been proposed, and it's too early to talk about them, but given how different the approaches are, it makes sense to explore agreement on the general principles -- do we expect that it is possible to solve the problem of conveying information about routing layer in a way that leaves ISPs happy and is practical? How complicated can a solution be before it becomes flaky and fragile? What is the smallest, most general-purpose standard that we can come up with that conveys this information. Good job with getting it out, -- Stas On Jun 30, 2008, at 9:27 AM, Enrico Marocco wrote: > An updated version of the problem statement is available at the > following link: > http://www.ietf.org/internet-drafts/draft-marocco-alto-problem-statement-01.txt > > Diffs from the previous version may be viewed at: > http://tools.ietf.org//rfcdiff?url1=http://tools.ietf.org/id/draft-marocco-alto-problem-statement-00&url2=http://www.ietf.org/internet-drafts/draft-marocco-alto-problem-statement-01.txt > > So far, it seems there is agreement on the fact that ALTO will focus > on > an application-layer interface for exposing some kind of topology > information to be used for optimizing traffic generated by a wide > range > of applications (including file-sharing, VoIP, real-time streaming.) > > What is probably less agreed at this time is what kind of information > the protocols specified in ALTO are going to provide, whether it > should > be static information (e.g. from AS1, AS2 is always preferred to AS3,) > dynamic information (e.g. right now the link between AS1 and AS2 is > congested, peers in AS1 should prefer peers in AS3) or both. Even if > such a decision is likely to be discussed after a working group is > created, we would like to encourage people who have a strong opinion > which they think would impact a potential charter, to express it now. > > Any other comments -- both substantial and editorial -- are of course > welcome too. > > -- > Ciao, > Enrico > -- Stanislav Shalunov http://shlang.com _______________________________________________ p2pi mailing list p2pi@ietf.org https://www.ietf.org/mailman/listinfo/p2pi From p2pi-bounces@ietf.org Mon Jun 30 10:42:05 2008 Return-Path: X-Original-To: p2pi-archive@ietf.org Delivered-To: ietfarch-p2pi-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6B50E3A6832; Mon, 30 Jun 2008 10:42:05 -0700 (PDT) X-Original-To: p2pi@core3.amsl.com Delivered-To: p2pi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 25A413A6832 for ; Mon, 30 Jun 2008 10:42:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.949 X-Spam-Level: X-Spam-Status: No, score=-1.949 tagged_above=-999 required=5 tests=[AWL=0.650, 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 1svB2n5FB+fD for ; Mon, 30 Jun 2008 10:42:03 -0700 (PDT) Received: from mailhost.jlc.net (mailhost.jlc.net [199.201.159.9]) by core3.amsl.com (Postfix) with ESMTP id 44E133A67E9 for ; Mon, 30 Jun 2008 10:42:03 -0700 (PDT) Received: by mailhost.jlc.net (Postfix, from userid 104) id 40B0833C20; Mon, 30 Jun 2008 13:42:14 -0400 (EDT) Date: Mon, 30 Jun 2008 13:42:14 -0400 From: John Leslie To: Enrico Marocco Message-ID: <20080630174214.GA3847@verdi> References: <48690985.4000906@telecomitalia.it> Mime-Version: 1.0 Content-Disposition: inline In-Reply-To: <48690985.4000906@telecomitalia.it> User-Agent: Mutt/1.4.1i Cc: p2pi@ietf.org Subject: Re: [p2pi] New version of the problem statement X-BeenThere: p2pi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: P2P Infrastructure Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: p2pi-bounces@ietf.org Errors-To: p2pi-bounces@ietf.org Enrico Marocco wrote: > > An updated version of the problem statement is available at the > following link: > > http://www.ietf.org/internet-drafts/draft-marocco-alto-problem-statement-01.txt Looks pretty good! :^) > So far, it seems there is agreement on the fact that ALTO will focus on > an application-layer interface for exposing some kind of topology > information to be used for optimizing traffic generated by a wide range > of applications (including file-sharing, VoIP, real-time streaming.) Agreed. > What is probably less agreed at this time is what kind of information > the protocols specified in ALTO are going to provide, My strongest desire is that it be easily extensible. > whether it should be static information (e.g. from AS1, AS2 is always > preferred to AS3,) I believe an ISP should be able to choose static vs. dynamic. > dynamic information (e.g. right now the link between AS1 and AS2 is > congested, peers in AS1 should prefer peers in AS3) or both. Obviously, benefits _could_ accrue from dynamic information. > Even if such a decision is likely to be discussed after a working group > is created, we would like to encourage people who have a strong opinion > which they think would impact a potential charter, to express it now. I would like the charter to allow designing a protocol which _could_ provide dynamic information; but I don't think we should _require_ any oracle operator to provide it. > Any other comments -- both substantial and editorial -- are of course > welcome too. One thing which caught my eye was the third paragraph of the Introduction where it says: " " ... file sharing applications... tend to ignore bandwidth and reliability " of underlying links..." I don't think that's quite right, but the issue is correctly raised. Certainly in the case of wireless links there will be non-congestion packet loss; and there are other issues which _might_ be thought of as "reliability" issues. I guess I wonder whether there's a better way to raise this concern. (I don't mean to require reporting any of these: this might better be left for an extension.) -- John Leslie _______________________________________________ p2pi mailing list p2pi@ietf.org https://www.ietf.org/mailman/listinfo/p2pi From p2pi-bounces@ietf.org Mon Jun 30 11:05: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 3C37528C111; Mon, 30 Jun 2008 11:05: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 D760228C111 for ; Mon, 30 Jun 2008 11:05:08 -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 8mC3xm2r2qZJ for ; Mon, 30 Jun 2008 11:05:08 -0700 (PDT) Received: from mailm.telecomitalia.it (mailm.telecomitalia.it [217.169.121.53]) by core3.amsl.com (Postfix) with ESMTP id 575C928C104 for ; Mon, 30 Jun 2008 11:05:07 -0700 (PDT) Received: from ptpxch007rm001.idc.cww.telecomitalia.it ([156.54.205.169]) by mailm.telecomitalia.it with Microsoft SMTPSVC(6.0.3790.1830); Mon, 30 Jun 2008 20:05:17 +0200 Received: from grfhub701rm001.griffon.local ([10.19.3.8]) by ptpxch007rm001.idc.cww.telecomitalia.it with Microsoft SMTPSVC(6.0.3790.1830); Mon, 30 Jun 2008 20:05:17 +0200 Received: from [10.229.8.44] (10.229.8.44) by smtp.telecomitalia.it (10.19.3.40) with Microsoft SMTP Server (TLS) id 8.1.278.0; Mon, 30 Jun 2008 20:05:16 +0200 Message-ID: <48692045.7060807@telecomitalia.it> Date: Mon, 30 Jun 2008 20:04:53 +0200 From: Enrico Marocco User-Agent: Mozilla-Thunderbird 2.0.0.14 (X11/20080509) MIME-Version: 1.0 To: Stanislav Shalunov References: <48690985.4000906@telecomitalia.it> <54883F9F-8548-48A3-AC44-1FD3E261FEFB@bittorrent.com> In-Reply-To: <54883F9F-8548-48A3-AC44-1FD3E261FEFB@bittorrent.com> X-Enigmail-Version: 0.95.0 X-OriginalArrivalTime: 30 Jun 2008 18:05:17.0046 (UTC) FILETIME=[DA043160:01C8DADB] Cc: "p2pi@ietf.org" Subject: Re: [p2pi] New version of the problem statement X-BeenThere: p2pi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: P2P Infrastructure Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1862884676==" Sender: p2pi-bounces@ietf.org Errors-To: p2pi-bounces@ietf.org --===============1862884676== Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms000800020709050408060001" --------------ms000800020709050408060001 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Stanislav Shalunov wrote: > The problem statement generally looks good. Thank you very much for the comments and for a quick response. > 1. The popular metrics used by P2P applications are based on obtained > goodput, not RTT. This doesn't ignore bitrate and reliability -- if > it did, P2P would work much worse than it does today. It ignores cost > and desires of the ISP, which is the problem ALTO needs to solve. Well, I guess you are right. Here we probably messed up with coordinate-based systems described in literature, which are sometimes used before actually starting transmissions. We will fix this in the next version. > 2. Cache location is clearly the low-hanging fruit that requires no > research. It's a matter of engineering, and any decent choice of > mechanism will work. We just need to agree on the mechanism. I'd > like to see this stressed and moved up. Are you suggesting to mention earlier in the draft (in the Introduction?) the benefit that would come from an ALTO solution when used in conjunction with (or even just aware of) application caches, or are you just asking to move S3.5 to S3.1 or S3.2? Both of the two make sense to me, but the latter seems to assume some kind of rational order in section 3, which so far has not been the case. > 3. Would it not help to have an actual formulation of the problem > somewhere? Like a sentence or a paragraph? I've trouble finding this > spot. All the text says the right things, but it'd help to start with > something like > > ALTO will solve two problems: (1) finding application caches and (2) > conveying some of the information about the network already available > to the routing layer up to application layer so that applications can > choose better and lower-cost paths for their data. > > Is this the problem that your document describes? If so, it > should say it. If not, it should say what the problem is. Finding application caches is something very application-specific, while we try to keep the problem statement a bit more general. So, instead of saying something like "(a) finding application caches, and (b) finding best VoIP relays, and (c) finding closest DHT nodes", we prefer to say "finding the best peer, for some reasonable value of best". Then, if an ALTO service is aware of BitTorrent caches, it will do a good job in redirecting querying peers to them. > 4. Multiple solutions have indeed been proposed, and it's too early to > talk about them, but given how different the approaches are, it makes > sense to explore agreement on the general principles -- do we expect > that it is possible to solve the problem of conveying information > about routing layer in a way that leaves ISPs happy and is practical? In this version we tried to stress that an ALTO solution should be deployable also by third-parties other than ISPs. However, it seems quite a shared feeling that deployment of ALTO would bring ISPs and P2P systems to a win-win situation, so I'd tend to say yes, it should leave ISPs happy. Do you have any issue in mind why this may not be the case? > How complicated can a solution be before it becomes flaky and > fragile? What is the smallest, most general-purpose standard that we > can come up with that conveys this information. Those are probably questions a working group should try to answer, but we still don't have one. -- Ciao, Enrico --------------ms000800020709050408060001 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 hkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wODA2MzAxODA0NTNaMCMG CSqGSIb3DQEJBDEWBBRqlVps5yXOCjfCyT+15ckaxfCGpjBfBgkqhkiG9w0BCQ8xUjBQMAsG CWCGSAFlAwQBAjAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAw BwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgYUGCSsGAQQBgjcQBDF4MHYwYjELMAkGA1UEBhMC WkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1Ro YXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAhAeTAANDUMJU97n0e1AWxu4MIGH BgsqhkiG9w0BCRACCzF4oHYwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25z dWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJ c3N1aW5nIENBAhAeTAANDUMJU97n0e1AWxu4MA0GCSqGSIb3DQEBAQUABIIBAIwboFMoGAkA 98XR3eghV7M/oiZBilmAhqzYA/j2UMIPDH8uujZF/VNFmsGyOV4Nd1MYTewqGFgeWAN+pziE Hg4vxc5eBeb/67cfWGFei9bDyZ59ymHcvFaicY+3y7wSFSQk8iQ8Di/z47cs2my/GCDJATA7 s3L/yc8jw5vyv5I2DOdyYb6pi5MgXCpsMryQGB0puTBK1l+IUZmCUNzXBTV0aLvXo8I24yzT 8msCPETNAP1OfvG25eB6vLEccRJsVMrzOJdfP9kcg0zWmYHs026dbQtMCCm85uXbicCFADa6 n/2qGJ0uEjntTZVsopqo0jR1GGMmmQsX6uXKCBuDJtIAAAAAAAA= --------------ms000800020709050408060001-- --===============1862884676== 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 --===============1862884676==-- From p2pi-bounces@ietf.org Mon Jun 30 11:18:32 2008 Return-Path: X-Original-To: p2pi-archive@ietf.org Delivered-To: ietfarch-p2pi-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B25D23A691B; Mon, 30 Jun 2008 11:18:32 -0700 (PDT) X-Original-To: p2pi@core3.amsl.com Delivered-To: p2pi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BAAD73A67B6 for ; Mon, 30 Jun 2008 11:18:31 -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 hLS0SF1COcly for ; Mon, 30 Jun 2008 11:18:31 -0700 (PDT) Received: from mailm.telecomitalia.it (mailm.telecomitalia.it [217.169.121.53]) by core3.amsl.com (Postfix) with ESMTP id 81C283A691B for ; Mon, 30 Jun 2008 11:18:30 -0700 (PDT) Received: from ptpxch009rm001.idc.cww.telecomitalia.it ([156.54.205.171]) by mailm.telecomitalia.it with Microsoft SMTPSVC(6.0.3790.1830); Mon, 30 Jun 2008 20:18:41 +0200 Received: from grfhub703rm001.griffon.local ([10.19.3.10]) by ptpxch009rm001.idc.cww.telecomitalia.it with Microsoft SMTPSVC(6.0.3790.1830); Mon, 30 Jun 2008 20:18:41 +0200 Received: from [10.229.8.44] (10.229.8.44) by smtp.telecomitalia.it (10.19.3.42) with Microsoft SMTP Server (TLS) id 8.1.278.0; Mon, 30 Jun 2008 20:18:40 +0200 Message-ID: <48692369.20004@telecomitalia.it> Date: Mon, 30 Jun 2008 20:18:17 +0200 From: Enrico Marocco User-Agent: Mozilla-Thunderbird 2.0.0.14 (X11/20080509) MIME-Version: 1.0 To: John Leslie References: <48690985.4000906@telecomitalia.it> <20080630174214.GA3847@verdi> In-Reply-To: <20080630174214.GA3847@verdi> X-Enigmail-Version: 0.95.0 X-OriginalArrivalTime: 30 Jun 2008 18:18:41.0242 (UTC) FILETIME=[B95AC3A0:01C8DADD] Cc: "p2pi@ietf.org" Subject: Re: [p2pi] New version of the problem statement X-BeenThere: p2pi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: P2P Infrastructure Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1053018689==" Sender: p2pi-bounces@ietf.org Errors-To: p2pi-bounces@ietf.org --===============1053018689== Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms010102080907020502070609" --------------ms010102080907020502070609 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit John Leslie wrote: > One thing which caught my eye was the third paragraph of the Introduction > where it says: > " > " ... file sharing applications... tend to ignore bandwidth and reliability > " of underlying links..." > > I don't think that's quite right, but the issue is correctly raised. Right, we'll fix it in the next version. > Certainly in the case of wireless links there will be non-congestion > packet loss; and there are other issues which _might_ be thought of as > "reliability" issues. > > I guess I wonder whether there's a better way to raise this concern. > (I don't mean to require reporting any of these: this might better be > left for an extension.) Yes, extensibility will probably be the key. -- Ciao, Enrico --------------ms010102080907020502070609 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 hkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wODA2MzAxODE4MTdaMCMG CSqGSIb3DQEJBDEWBBSg15Dd9S5Fap+D2adgaSaQrmeSzTBfBgkqhkiG9w0BCQ8xUjBQMAsG CWCGSAFlAwQBAjAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAw BwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgYUGCSsGAQQBgjcQBDF4MHYwYjELMAkGA1UEBhMC WkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1Ro YXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAhAeTAANDUMJU97n0e1AWxu4MIGH BgsqhkiG9w0BCRACCzF4oHYwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25z dWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJ c3N1aW5nIENBAhAeTAANDUMJU97n0e1AWxu4MA0GCSqGSIb3DQEBAQUABIIBAHVsObha2oPS R8xZ8ptgSPHbBFeW4oelZh16CcqAw8cy78cC0EtQ9eRw7MlBbcbUAeJS5ziYhDhvYxOvB/B9 LvXuYesEdiZhrchj7JuxEewv+24mPnTONTCeadHgNy0jti+hTF9hq2wB/nJghh5RghLXJ8uI bNc5Kf9ac5OAarpir0eEfUs1WFUt0ocZyAI/FOICna7NwP+AndVDOcER6Poa1FvTupYtXWcv 1qbtqr/pn8B6lqXV1o5gtQprverFcykKrnQW3SgkjRLZSisEZ2PbhGmrE5SA+MgL8WIrlT6c kEqfOFsBN8KMEYeYdkOUZc7UJhOUCzTAYYis0cLnvI8AAAAAAAA= --------------ms010102080907020502070609-- --===============1053018689== 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 --===============1053018689==-- From p2pi-bounces@ietf.org Mon Jun 30 13:02: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 929453A691B; Mon, 30 Jun 2008 13:02: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 B66A93A691B for ; Mon, 30 Jun 2008 13:02:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QmF26BtiKerk for ; Mon, 30 Jun 2008 13:02:20 -0700 (PDT) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.231]) by core3.amsl.com (Postfix) with ESMTP id B17523A679F for ; Mon, 30 Jun 2008 13:02:20 -0700 (PDT) Received: by rv-out-0506.google.com with SMTP id b25so1363686rvf.49 for ; Mon, 30 Jun 2008 13:02:30 -0700 (PDT) Received: by 10.114.144.1 with SMTP id r1mr4732607wad.97.1214856149900; Mon, 30 Jun 2008 13:02:29 -0700 (PDT) Received: from ?192.168.1.103? ( [67.188.243.194]) by mx.google.com with ESMTPS id k39sm8606638wah.3.2008.06.30.13.02.24 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 30 Jun 2008 13:02:28 -0700 (PDT) Message-Id: From: Stanislav Shalunov To: Enrico Marocco In-Reply-To: <48692045.7060807@telecomitalia.it> Mime-Version: 1.0 (Apple Message framework v924) Date: Mon, 30 Jun 2008 13:02:22 -0700 References: <48690985.4000906@telecomitalia.it> <54883F9F-8548-48A3-AC44-1FD3E261FEFB@bittorrent.com> <48692045.7060807@telecomitalia.it> X-Mailer: Apple Mail (2.924) Cc: "p2pi@ietf.org" Subject: Re: [p2pi] New version of the problem statement X-BeenThere: p2pi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: P2P Infrastructure Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: p2pi-bounces@ietf.org Errors-To: p2pi-bounces@ietf.org On Jun 30, 2008, at 11:04 AM, Enrico Marocco wrote: >> 2. Cache location is clearly the low-hanging fruit that requires no >> research. It's a matter of engineering, and any decent choice of >> mechanism will work. We just need to agree on the mechanism. I'd >> like to see this stressed and moved up. > > Are you suggesting to mention earlier in the draft (in the > Introduction?) the benefit that would come from an ALTO solution > when used in conjunction with (or even just aware of) application > caches, or are you just asking to move S3.5 to S3.1 or S3.2? Both > of the two make sense to me, but the latter seems to assume some > kind of rational order in section 3, which so far has not been the > case. I'd say both. Right now, it's treated as an afterthought. Given how easy it is to engineer and the immense payoffs that it promises to both the ISP and the P2P app user, it should be given more prominent display. This is the easy stuff that we probably very easily all agree on. >> 3. Would it not help to have an actual formulation of the problem >> somewhere? Like a sentence or a paragraph? I've trouble finding >> this >> spot. All the text says the right things, but it'd help to start >> with >> something like >> ALTO will solve two problems: (1) finding application caches >> and (2) >> conveying some of the information about the network already available >> to the routing layer up to application layer so that applications can >> choose better and lower-cost paths for their data. >> Is this the problem that your document describes? If so, it >> should say it. If not, it should say what the problem is. > > Finding application caches is something very application-specific, > while we try to keep the problem statement a bit more general. So, > instead of saying something like "(a) finding application caches, > and (b) finding best VoIP relays, and (c) finding closest DHT > nodes", we prefer to say "finding the best peer, for some reasonable > value of best". Then, if an ALTO service is aware of BitTorrent > caches, it will do a good job in redirecting querying peers to them. I agree with the need to keep the mechanisms general-purpose. When I say "application caches" I mean more generally than BitTorrent. I'm not aware of a general mechanism other than hard-to- modify DSCP for discovery of local application-specific resources. We could do that. So it might be even more general than "best peer". Whatever the goal is and however it's phrased, it would help focus to add it in the most concise form in the very beginning of the document. >> 4. Multiple solutions have indeed been proposed, and it's too early >> to >> talk about them, but given how different the approaches are, it makes >> sense to explore agreement on the general principles -- do we expect >> that it is possible to solve the problem of conveying information >> about routing layer in a way that leaves ISPs happy and is practical? > > In this version we tried to stress that an ALTO solution should be > deployable also by third-parties other than ISPs. It's good if it can be made deployable by entities other than ISPs. Who might be such third parties? > However, it seems quite a shared feeling that deployment of ALTO > would bring ISPs and P2P systems to a win-win situation, so I'd tend > to say yes, it should leave ISPs happy. Do you have any issue in > mind why this may not be the case? I stress ISP happiness because to me that's one of the key drivers for ALTO. P2P systems already work and ALTO information might improve their performance somewhat, but not radically. The ISPs' costs, on the other hand, might be substantially reduced. (This is a bit different from caching, which would also radically improve P2P app performance potentially.) >> How complicated can a solution be before it becomes flaky and >> fragile? What is the smallest, most general-purpose standard that we >> can come up with that conveys this information. > > Those are probably questions a working group should try to answer, > but we still don't have one. OK, agreed. -- Stanislav Shalunov http://shlang.com _______________________________________________ p2pi mailing list p2pi@ietf.org https://www.ietf.org/mailman/listinfo/p2pi From p2pi-bounces@ietf.org Mon Jun 30 13:24: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 344793A68DA; Mon, 30 Jun 2008 13:24: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 51EB43A69BD for ; Mon, 30 Jun 2008 13:24:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.265 X-Spam-Level: X-Spam-Status: No, score=-10.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HABEAS_ACCREDITED_COI=-8, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yERBAQxqhImE for ; Mon, 30 Jun 2008 13:24:11 -0700 (PDT) Received: from dkny.pando.com (dkny.pando.com [67.99.55.163]) by core3.amsl.com (Postfix) with ESMTP id 07C563A68DA for ; Mon, 30 Jun 2008 13:24:10 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by dkny.pando.com (Postfix) with ESMTP id 0B158E10BAD; Mon, 30 Jun 2008 16:24:22 -0400 (EDT) X-Virus-Scanned: amavisd-new at Received: from dkny.pando.com ([127.0.0.1]) by localhost (dkny.pando.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I1se6ZuFRMZy; Mon, 30 Jun 2008 16:23:59 -0400 (EDT) Received: from dkny.pando.com (dkny.pando.com [10.10.60.11]) by dkny.pando.com (Postfix) with ESMTP id B223DE10BBE; Mon, 30 Jun 2008 16:23:59 -0400 (EDT) Date: Mon, 30 Jun 2008 16:23:59 -0400 (EDT) From: Laird Popkin To: Stanislav Shalunov Message-ID: <531723172.454861214857439689.JavaMail.root@dkny.pando.com> In-Reply-To: MIME-Version: 1.0 X-Originating-IP: [10.10.20.73] Cc: p2pi@ietf.org Subject: Re: [p2pi] New version of the problem statement X-BeenThere: p2pi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: P2P Infrastructure Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: p2pi-bounces@ietf.org Errors-To: p2pi-bounces@ietf.org I view cache discovery as a particularly valuable case of ALTO's general goal, which (IMO) is to allow network providers to provide guidance so that applications that can choose from multiple potential data sources to make better informed selections. I suggest that both ISPs and the P2P platforms have a strong incentive to optimize p2p traffic. The ISPs save network resources (and eventually money), which is a strong direct driver. It's true that p2p performance improvements may not be as dramatic an incentive for a pure p2p network, the hybrid P2P networks (e.g. Pando, BitTorrent DNA, Kontiki) do save money when the p2p performance is improved, because it allows them to pull less data from the CDN servers. But more importantly (IMO) I think that it's fairly safe to say that the p2p networks don't want ISPs to throttle or block their applications, and if working together to optimize traffic reduced the incentive for ISPs to shape traffic, etc., that's good for the entire p2p industry. - Laird Popkin, CTO, Pando Networks mobile: 646/465-0570 ----- Original Message ----- From: "Stanislav Shalunov" To: "Enrico Marocco" Cc: p2pi@ietf.org Sent: Monday, June 30, 2008 4:02:22 PM (GMT-0500) America/New_York Subject: Re: [p2pi] New version of the problem statement On Jun 30, 2008, at 11:04 AM, Enrico Marocco wrote: >> 2. Cache location is clearly the low-hanging fruit that requires no >> research. It's a matter of engineering, and any decent choice of >> mechanism will work. We just need to agree on the mechanism. I'd >> like to see this stressed and moved up. > > Are you suggesting to mention earlier in the draft (in the > Introduction?) the benefit that would come from an ALTO solution > when used in conjunction with (or even just aware of) application > caches, or are you just asking to move S3.5 to S3.1 or S3.2? Both > of the two make sense to me, but the latter seems to assume some > kind of rational order in section 3, which so far has not been the > case. I'd say both. Right now, it's treated as an afterthought. Given how easy it is to engineer and the immense payoffs that it promises to both the ISP and the P2P app user, it should be given more prominent display. This is the easy stuff that we probably very easily all agree on. >> 3. Would it not help to have an actual formulation of the problem >> somewhere? Like a sentence or a paragraph? I've trouble finding >> this >> spot. All the text says the right things, but it'd help to start >> with >> something like >> ALTO will solve two problems: (1) finding application caches >> and (2) >> conveying some of the information about the network already available >> to the routing layer up to application layer so that applications can >> choose better and lower-cost paths for their data. >> Is this the problem that your document describes? If so, it >> should say it. If not, it should say what the problem is. > > Finding application caches is something very application-specific, > while we try to keep the problem statement a bit more general. So, > instead of saying something like "(a) finding application caches, > and (b) finding best VoIP relays, and (c) finding closest DHT > nodes", we prefer to say "finding the best peer, for some reasonable > value of best". Then, if an ALTO service is aware of BitTorrent > caches, it will do a good job in redirecting querying peers to them. I agree with the need to keep the mechanisms general-purpose. When I say "application caches" I mean more generally than BitTorrent. I'm not aware of a general mechanism other than hard-to- modify DSCP for discovery of local application-specific resources. We could do that. So it might be even more general than "best peer". Whatever the goal is and however it's phrased, it would help focus to add it in the most concise form in the very beginning of the document. >> 4. Multiple solutions have indeed been proposed, and it's too early >> to >> talk about them, but given how different the approaches are, it makes >> sense to explore agreement on the general principles -- do we expect >> that it is possible to solve the problem of conveying information >> about routing layer in a way that leaves ISPs happy and is practical? > > In this version we tried to stress that an ALTO solution should be > deployable also by third-parties other than ISPs. It's good if it can be made deployable by entities other than ISPs. Who might be such third parties? > However, it seems quite a shared feeling that deployment of ALTO > would bring ISPs and P2P systems to a win-win situation, so I'd tend > to say yes, it should leave ISPs happy. Do you have any issue in > mind why this may not be the case? I stress ISP happiness because to me that's one of the key drivers for ALTO. P2P systems already work and ALTO information might improve their performance somewhat, but not radically. The ISPs' costs, on the other hand, might be substantially reduced. (This is a bit different from caching, which would also radically improve P2P app performance potentially.) >> How complicated can a solution be before it becomes flaky and >> fragile? What is the smallest, most general-purpose standard that we >> can come up with that conveys this information. > > Those are probably questions a working group should try to answer, > but we still don't have one. OK, agreed. -- Stanislav Shalunov http://shlang.com _______________________________________________ p2pi mailing list p2pi@ietf.org https://www.ietf.org/mailman/listinfo/p2pi _______________________________________________ p2pi mailing list p2pi@ietf.org https://www.ietf.org/mailman/listinfo/p2pi From p2pi-bounces@ietf.org Mon Jun 30 13:46:13 2008 Return-Path: X-Original-To: p2pi-archive@ietf.org Delivered-To: ietfarch-p2pi-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0AF5C3A6AC3; Mon, 30 Jun 2008 13:46:13 -0700 (PDT) X-Original-To: p2pi@core3.amsl.com Delivered-To: p2pi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 82D6F3A67CE for ; Mon, 30 Jun 2008 13:46:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.507 X-Spam-Level: X-Spam-Status: No, score=-1.507 tagged_above=-999 required=5 tests=[AWL=-0.720, BAYES_00=-2.599, SARE_SPEC_REPLICA_OBFU=1.812] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zvEUivXlAVmK for ; Mon, 30 Jun 2008 13:46:10 -0700 (PDT) Received: from ihemail3.lucent.com (ihemail3.lucent.com [135.245.0.37]) by core3.amsl.com (Postfix) with ESMTP id 4057C3A68DA for ; Mon, 30 Jun 2008 13:46:07 -0700 (PDT) Received: from umail.lucent.com (h135-3-40-61.lucent.com [135.3.40.61]) by ihemail3.lucent.com (8.13.8/IER-o) with ESMTP id m5UKkDiE026563 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 30 Jun 2008 15:46:15 -0500 (CDT) Received: from [135.185.244.90] (il0015vkg1.ih.lucent.com [135.185.244.90]) by umail.lucent.com (8.13.8/TPES) with ESMTP id m5UKk9Vt001956; Mon, 30 Jun 2008 15:46:09 -0500 (CDT) Message-ID: <48694614.7080703@alcatel-lucent.com> Date: Mon, 30 Jun 2008 15:46:12 -0500 From: "Vijay K. Gurbani" Organization: Bell Labs Security Technology Research Group User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Stanislav Shalunov References: <48690985.4000906@telecomitalia.it> <54883F9F-8548-48A3-AC44-1FD3E261FEFB@bittorrent.com> <48692045.7060807@telecomitalia.it> In-Reply-To: X-Scanned-By: MIMEDefang 2.57 on 135.245.2.37 Cc: "p2pi@ietf.org" Subject: Re: [p2pi] New version of the problem statement X-BeenThere: p2pi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: P2P Infrastructure Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: p2pi-bounces@ietf.org Errors-To: p2pi-bounces@ietf.org Stanislav Shalunov wrote: > I'd say both. Right now, it's treated as an afterthought. Given how > easy it is to engineer and the immense payoffs that it promises to both > the ISP and the P2P app user, it should be given more prominent > display. This is the easy stuff that we probably very easily all agree on. Stanislav: OK. > Whatever the goal is and however it's phrased, it would help focus to > add it in the most concise form in the very beginning of the document. Agreed; hence getting this document out for early review for maybe one more iteration before the submission deadline. >> In this version we tried to stress that an ALTO solution should be >> deployable also by third-parties other than ISPs. > > It's good if it can be made deployable by entities other than ISPs. Who > might be such third parties? One model is espoused by Ono, from Northwestern University. Ono, as I am sure you may be aware of, is an Azureus plug-in that uses Akamai's CDN to derive hints on how clients are redirected to replica servers and thus bias a peer selection algorithm (their paper is in Sigcomm 2008 conference and can be accessed from http://www.aqualab.cs.northwestern.edu/publications/DChoffnes08Sigcomm.pdf). We posit that a neutral third party may be someone that uses techniques like this that are not ISP-dependent. Thanks, - vijay -- Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent 2701 Lucent Lane, Rm. 9F-546, Lisle, Illinois 60532 (USA) Email: vkg@{alcatel-lucent.com,bell-labs.com,acm.org} WWW: http://www.alcatel-lucent.com/bell-labs _______________________________________________ p2pi mailing list p2pi@ietf.org https://www.ietf.org/mailman/listinfo/p2pi From p2pi-bounces@ietf.org Mon Jun 30 14:00:31 2008 Return-Path: X-Original-To: p2pi-archive@ietf.org Delivered-To: ietfarch-p2pi-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 164B33A6AB0; Mon, 30 Jun 2008 14:00:31 -0700 (PDT) X-Original-To: p2pi@core3.amsl.com Delivered-To: p2pi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 20AC93A6A73 for ; Mon, 30 Jun 2008 14:00:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.265 X-Spam-Level: X-Spam-Status: No, score=-10.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HABEAS_ACCREDITED_COI=-8, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n7sryjYV7mmn for ; Mon, 30 Jun 2008 14:00:29 -0700 (PDT) Received: from dkny.pando.com (dkny.pando.com [67.99.55.163]) by core3.amsl.com (Postfix) with ESMTP id F07B63A6A40 for ; Mon, 30 Jun 2008 14:00:28 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by dkny.pando.com (Postfix) with ESMTP id 2C0B5E10BAE; Mon, 30 Jun 2008 17:00:40 -0400 (EDT) X-Virus-Scanned: amavisd-new at Received: from dkny.pando.com ([127.0.0.1]) by localhost (dkny.pando.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TcDtvlFVBYiz; Mon, 30 Jun 2008 17:00:39 -0400 (EDT) Received: from dkny.pando.com (dkny.pando.com [10.10.60.11]) by dkny.pando.com (Postfix) with ESMTP id 92BD0E10BAD; Mon, 30 Jun 2008 17:00:39 -0400 (EDT) Date: Mon, 30 Jun 2008 17:00:39 -0400 (EDT) From: Laird Popkin To: Enrico Marocco Message-ID: <374690192.455401214859639577.JavaMail.root@dkny.pando.com> In-Reply-To: <1619650565.455321214858912475.JavaMail.root@dkny.pando.com> MIME-Version: 1.0 X-Originating-IP: [10.10.20.73] Cc: p2pi@ietf.org, Stanislav Shalunov Subject: Re: [p2pi] New version of the problem statement X-BeenThere: p2pi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: P2P Infrastructure Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: p2pi-bounces@ietf.org Errors-To: p2pi-bounces@ietf.org Responding to "> 1. The popular metrics used by P2P applications are based on obtained > goodput, not RTT. This doesn't ignore bitrate and reliability -- if > it did, P2P would work much worse than it does today. It ignores cost > and desires of the ISP, which is the problem ALTO needs to solve. Well, I guess you are right. Here we probably messed up with coordinate-based systems described in literature, which are sometimes used before actually starting transmissions. We will fix this in the next version." I think that it's important for ALTO to provide guidance before starting transmissions. In fact, I'd suggest that once transmission is started, the p2p networks won't benefit too much from ALTO, because they will prefer to use the actual measured throughput to optimize p2p transfers rather than guidance. I think that the biggest "win" for ALSO is in picking good peers from a large potential pool of peers to form the initial connections. I think of it as a time savings issue. Imagine, for example, that I'm downloading from a swarm with 10,000 peers in it. How long it will take me to connect to the closest peer? If I find out about 50 new peers every minute (i.e. announce, get response, connect to all new peers, move data, measure throughput), it will take me 138 minutes to have a 50% chance of finding the closest peer. But if I have accurate guidance about which peers are near me, I connect to the closest peer on the first announce. So the download is likely to be faster sooner with network guidance than without. Looking at getting guidance related to the 50 peers that I know about, there's some savings in being told which of the 50 are closest, but it's less dramatic a win because it doesn't take me terribly long to connect to all 50 peers and measure actual throughput. (Note: I made some simplifying assumptions above. For example, it may not always be the case that the closest peer is the best data source (though it seems to be generally true in the P4P tests, there are obvious exceptions, such as people on a DSL provider who are better off connecting to a fiber provider's customers than other DSL customers). And while most swarms' peer discovery and measurement isn't 50 per minute (so that number is optimistic) I also ignored Peer Exchange, which will help speed things up. But I think that the basic idea stands. :-) - Laird Popkin, CTO, Pando Networks mobile: 646/465-0570 _______________________________________________ p2pi mailing list p2pi@ietf.org https://www.ietf.org/mailman/listinfo/p2pi From p2pi-bounces@ietf.org Mon Jun 30 14:04:12 2008 Return-Path: X-Original-To: p2pi-archive@ietf.org Delivered-To: ietfarch-p2pi-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C42E03A689B; Mon, 30 Jun 2008 14:04:12 -0700 (PDT) X-Original-To: p2pi@core3.amsl.com Delivered-To: p2pi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 05B0E3A6806 for ; Mon, 30 Jun 2008 14:04:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.359 X-Spam-Level: X-Spam-Status: No, score=-9.359 tagged_above=-999 required=5 tests=[AWL=-0.906, BAYES_00=-2.599, HABEAS_ACCREDITED_COI=-8, IP_NOT_FRIENDLY=0.334, SARE_SPEC_REPLICA_OBFU=1.812] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IUbzSZuVEr-4 for ; Mon, 30 Jun 2008 14:04:11 -0700 (PDT) Received: from dkny.pando.com (dkny.pando.com [67.99.55.163]) by core3.amsl.com (Postfix) with ESMTP id D92933A6838 for ; Mon, 30 Jun 2008 14:04:10 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by dkny.pando.com (Postfix) with ESMTP id 9CB90E10BAB; Mon, 30 Jun 2008 17:04:21 -0400 (EDT) X-Virus-Scanned: amavisd-new at Received: from dkny.pando.com ([127.0.0.1]) by localhost (dkny.pando.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PzGG25gXtH0J; Mon, 30 Jun 2008 17:04:08 -0400 (EDT) Received: from dkny.pando.com (dkny.pando.com [10.10.60.11]) by dkny.pando.com (Postfix) with ESMTP id 55281E10BA5; Mon, 30 Jun 2008 17:04:08 -0400 (EDT) Date: Mon, 30 Jun 2008 17:04:08 -0400 (EDT) From: Laird Popkin To: "Vijay K. Gurbani" Message-ID: <1043388994.455491214859848323.JavaMail.root@dkny.pando.com> In-Reply-To: <48694614.7080703@alcatel-lucent.com> MIME-Version: 1.0 X-Originating-IP: [10.10.20.73] Cc: p2pi@ietf.org, Stanislav Shalunov Subject: Re: [p2pi] New version of the problem statement X-BeenThere: p2pi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: P2P Infrastructure Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: p2pi-bounces@ietf.org Errors-To: p2pi-bounces@ietf.org Other possible third party providers would be a trusted third party such as ARIN, or a service provider that's used by ISP's to outsource the service (e.g. the way some smaller ISPs outsource email, etc.). - Laird Popkin, CTO, Pando Networks mobile: 646/465-0570 ----- Original Message ----- From: "Vijay K. Gurbani" To: "Stanislav Shalunov" Cc: p2pi@ietf.org Sent: Monday, June 30, 2008 4:46:12 PM (GMT-0500) America/New_York Subject: Re: [p2pi] New version of the problem statement Stanislav Shalunov wrote: > I'd say both. Right now, it's treated as an afterthought. Given how > easy it is to engineer and the immense payoffs that it promises to both > the ISP and the P2P app user, it should be given more prominent > display. This is the easy stuff that we probably very easily all agree on. Stanislav: OK. > Whatever the goal is and however it's phrased, it would help focus to > add it in the most concise form in the very beginning of the document. Agreed; hence getting this document out for early review for maybe one more iteration before the submission deadline. >> In this version we tried to stress that an ALTO solution should be >> deployable also by third-parties other than ISPs. > > It's good if it can be made deployable by entities other than ISPs. Who > might be such third parties? One model is espoused by Ono, from Northwestern University. Ono, as I am sure you may be aware of, is an Azureus plug-in that uses Akamai's CDN to derive hints on how clients are redirected to replica servers and thus bias a peer selection algorithm (their paper is in Sigcomm 2008 conference and can be accessed from http://www.aqualab.cs.northwestern.edu/publications/DChoffnes08Sigcomm.pdf). We posit that a neutral third party may be someone that uses techniques like this that are not ISP-dependent. Thanks, - vijay -- Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent 2701 Lucent Lane, Rm. 9F-546, Lisle, Illinois 60532 (USA) Email: vkg@{alcatel-lucent.com,bell-labs.com,acm.org} WWW: http://www.alcatel-lucent.com/bell-labs _______________________________________________ p2pi mailing list p2pi@ietf.org https://www.ietf.org/mailman/listinfo/p2pi _______________________________________________ p2pi mailing list p2pi@ietf.org https://www.ietf.org/mailman/listinfo/p2pi From p2pi-bounces@ietf.org Mon Jun 30 14:17: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 3E1A73A69A5; Mon, 30 Jun 2008 14:17: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 491943A69A5 for ; Mon, 30 Jun 2008 14:17:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.787 X-Spam-Level: X-Spam-Status: No, score=-4.787 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, SARE_SPEC_REPLICA_OBFU=1.812] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gm2mgbKG2vAn for ; Mon, 30 Jun 2008 14:17:13 -0700 (PDT) Received: from exprod7og102.obsmtp.com (exprod7og102.obsmtp.com [64.18.2.157]) by core3.amsl.com (Postfix) with ESMTP id D4CD53A699C for ; Mon, 30 Jun 2008 14:17:11 -0700 (PDT) Received: from source ([66.129.228.6]) by exprod7ob102.postini.com ([64.18.6.12]) with SMTP; Mon, 30 Jun 2008 14:17:22 PDT Received: from p-emlb01-sac.jnpr.net ([66.129.254.46]) by p-emsmtp03.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Mon, 30 Jun 2008 14:17:00 -0700 Received: from emailwf1.jnpr.net ([10.10.2.33]) by p-emlb01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Mon, 30 Jun 2008 14:17:00 -0700 Received: from proton.jnpr.net ([10.10.2.37]) by emailwf1.jnpr.net with Microsoft SMTPSVC(6.0.3790.1830); Mon, 30 Jun 2008 17:16:58 -0400 Received: from 172.23.1.57 ([172.23.1.57]) by proton.jnpr.net ([10.10.2.37]) with Microsoft Exchange Server HTTP-DAV ; Mon, 30 Jun 2008 21:16:58 +0000 User-Agent: Microsoft-Entourage/12.10.0.080409 Date: Mon, 30 Jun 2008 14:16:46 -0700 From: Reinaldo Penno To: "Vijay K. Gurbani" , Stanislav Shalunov Message-ID: Thread-Topic: [p2pi] New version of the problem statement Thread-Index: Acja9pn309eRRsMdk0+SkHXAytwdvA== In-Reply-To: <48694614.7080703@alcatel-lucent.com> Mime-version: 1.0 X-OriginalArrivalTime: 30 Jun 2008 21:16:58.0937 (UTC) FILETIME=[A1AD7A90:01C8DAF6] Cc: "p2pi@ietf.org" Subject: Re: [p2pi] New version of the problem statement X-BeenThere: p2pi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: P2P Infrastructure Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: p2pi-bounces@ietf.org Errors-To: p2pi-bounces@ietf.org Hi, although P2P peer selection geared towards keeping the traffic local (as in the same AS) is a major driver there are other cases as well that we should keep in mind so the solution is general. And sometimes the interest of the client is not necessarily the same as the ISP. * There are ISPs that want traffic within its AS because of cross-ISP transit costs. Here traffic locality and caching would be good solutions. * There are ISPs where transit cost is not the major problem. The most pressing problem is upload/download between subscribers within its AS. Peer locality might not to help much here (actually could be make the problem worse). Caching or downloading from peers outside your own AS might be a better fit. * Then there are ISPs that actually want peers outside its AS to download from them. This allows them to argue for settlement free peering since now then send as much traffic as they receive from their upstream provider. * The other dimension is that with the exception of caches, the closest peer from a pure coordinate perspective is not necessarily the best peer. At least not from the client perspective due to bw limitations. But I'm guessing the results from P2P CDNs like DNA vs. open would be quite different in this aspect. * Then of course as it was mentioned the needs of streaming P2P vs. file transfer vs. replication are quite different. Thanks, On 6/30/08 1:46 PM, "Vijay K. Gurbani" wrote: > Stanislav Shalunov wrote: >> I'd say both. Right now, it's treated as an afterthought. Given how >> easy it is to engineer and the immense payoffs that it promises to both >> the ISP and the P2P app user, it should be given more prominent >> display. This is the easy stuff that we probably very easily all agree on. > > Stanislav: OK. > >> Whatever the goal is and however it's phrased, it would help focus to >> add it in the most concise form in the very beginning of the document. > > Agreed; hence getting this document out for early review for > maybe one more iteration before the submission deadline. > >>> In this version we tried to stress that an ALTO solution should be >>> deployable also by third-parties other than ISPs. >> >> It's good if it can be made deployable by entities other than ISPs. Who >> might be such third parties? > > One model is espoused by Ono, from Northwestern University. Ono, as > I am sure you may be aware of, is an Azureus plug-in that uses > Akamai's CDN to derive hints on how clients are redirected to > replica servers and thus bias a peer selection algorithm (their > paper is in Sigcomm 2008 conference and can be accessed from > http://www.aqualab.cs.northwestern.edu/publications/DChoffnes08Sigcomm.pdf). > > We posit that a neutral third party may be someone that uses > techniques like this that are not ISP-dependent. > > Thanks, > > - vijay _______________________________________________ p2pi mailing list p2pi@ietf.org https://www.ietf.org/mailman/listinfo/p2pi From p2pi-bounces@ietf.org Mon Jun 30 15:08:33 2008 Return-Path: X-Original-To: p2pi-archive@ietf.org Delivered-To: ietfarch-p2pi-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E8EFC3A6AE2; Mon, 30 Jun 2008 15:08:33 -0700 (PDT) X-Original-To: p2pi@core3.amsl.com Delivered-To: p2pi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B70C43A6AC3 for ; Mon, 30 Jun 2008 15:08:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wEbtQYTQj8s8 for ; Mon, 30 Jun 2008 15:08:31 -0700 (PDT) Received: from wa-out-1112.google.com (wa-out-1112.google.com [209.85.146.183]) by core3.amsl.com (Postfix) with ESMTP id DBFD53A6A4D for ; Mon, 30 Jun 2008 15:08:31 -0700 (PDT) Received: by wa-out-1112.google.com with SMTP id k34so1571495wah.25 for ; Mon, 30 Jun 2008 15:08:43 -0700 (PDT) Received: by 10.114.89.1 with SMTP id m1mr4834556wab.146.1214863723231; Mon, 30 Jun 2008 15:08:43 -0700 (PDT) Received: from ?192.168.1.103? ( [67.188.243.194]) by mx.google.com with ESMTPS id k14sm6741999waf.29.2008.06.30.15.08.42 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 30 Jun 2008 15:08:42 -0700 (PDT) Message-Id: From: Stanislav Shalunov To: Laird Popkin In-Reply-To: <374690192.455401214859639577.JavaMail.root@dkny.pando.com> Mime-Version: 1.0 (Apple Message framework v924) Date: Mon, 30 Jun 2008 15:08:40 -0700 References: <374690192.455401214859639577.JavaMail.root@dkny.pando.com> X-Mailer: Apple Mail (2.924) Cc: p2pi@ietf.org Subject: Re: [p2pi] New version of the problem statement X-BeenThere: p2pi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: P2P Infrastructure Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: p2pi-bounces@ietf.org Errors-To: p2pi-bounces@ietf.org On Jun 30, 2008, at 2:00 PM, Laird Popkin wrote: > I think that it's important for ALTO to provide guidance before > starting transmissions. In fact, I'd suggest that once transmission > is started, the p2p networks won't benefit too much from ALTO, > because they will prefer to use the actual measured throughput to > optimize p2p transfers rather than guidance. Good point. -- Stanislav Shalunov http://shlang.com _______________________________________________ p2pi mailing list p2pi@ietf.org https://www.ietf.org/mailman/listinfo/p2pi From p2pi-bounces@ietf.org Mon Jun 30 15:20: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 C100F3A6B07; Mon, 30 Jun 2008 15:20: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 3DBDE3A6A4D for ; Mon, 30 Jun 2008 15:20:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.693 X-Spam-Level: X-Spam-Status: No, score=-1.693 tagged_above=-999 required=5 tests=[AWL=-0.906, BAYES_00=-2.599, SARE_SPEC_REPLICA_OBFU=1.812] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kBhIdPR+PYGH for ; Mon, 30 Jun 2008 15:20:06 -0700 (PDT) Received: from py-out-1112.google.com (py-out-1112.google.com [64.233.166.181]) by core3.amsl.com (Postfix) with ESMTP id 6A1033A6951 for ; Mon, 30 Jun 2008 15:20:06 -0700 (PDT) Received: by py-out-1112.google.com with SMTP id x19so413822pyg.24 for ; Mon, 30 Jun 2008 15:20:15 -0700 (PDT) Received: by 10.142.180.11 with SMTP id c11mr2124796wff.159.1214864415244; Mon, 30 Jun 2008 15:20:15 -0700 (PDT) Received: from ?192.168.1.103? ( [67.188.243.194]) by mx.google.com with ESMTPS id 30sm13131625wff.18.2008.06.30.15.20.13 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 30 Jun 2008 15:20:14 -0700 (PDT) Message-Id: <1535E107-012B-4D81-A8B6-0A673015D33F@shlang.com> From: Stanislav Shalunov To: Vijay K. Gurbani In-Reply-To: <48694614.7080703@alcatel-lucent.com> Mime-Version: 1.0 (Apple Message framework v924) Date: Mon, 30 Jun 2008 15:20:12 -0700 References: <48690985.4000906@telecomitalia.it> <54883F9F-8548-48A3-AC44-1FD3E261FEFB@bittorrent.com> <48692045.7060807@telecomitalia.it> <48694614.7080703@alcatel-lucent.com> X-Mailer: Apple Mail (2.924) Cc: "p2pi@ietf.org" Subject: Re: [p2pi] New version of the problem statement X-BeenThere: p2pi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: P2P Infrastructure Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: p2pi-bounces@ietf.org Errors-To: p2pi-bounces@ietf.org On Jun 30, 2008, at 1:46 PM, Vijay K. Gurbani wrote: > One model is espoused by Ono, from Northwestern University. Ono, as > I am sure you may be aware of, is an Azureus plug-in that uses > Akamai's CDN to derive hints on how clients are redirected to > replica servers and thus bias a peer selection algorithm (their > paper is in Sigcomm 2008 conference and can be accessed from > http://www.aqualab.cs.northwestern.edu/publications/DChoffnes08Sigcomm.pdf) > . > > We posit that a neutral third party may be someone that uses > techniques like this that are not ISP-dependent. Yeah, makes sense. Also Laird's RIR example, and perhaps roting registries. I was thinking about it as primarily an ISP-provided service to reduce costs, but indeed this could be used more broadly and should be designed to accommodate such uses. Then the ISP's instance of the ALTO information service could be found using the same technique as the ISP's instance of the ALTO cache. -- Stanislav Shalunov http://shlang.com _______________________________________________ p2pi mailing list p2pi@ietf.org https://www.ietf.org/mailman/listinfo/p2pi From p2pi-bounces@ietf.org Mon Jun 30 15:33: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 2F7873A6B16; Mon, 30 Jun 2008 15:33: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 68F863A6AC3 for ; Mon, 30 Jun 2008 15:33:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.372 X-Spam-Level: X-Spam-Status: No, score=-2.372 tagged_above=-999 required=5 tests=[AWL=0.227, 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 G0CuIR3NJwbS for ; Mon, 30 Jun 2008 15:33:07 -0700 (PDT) Received: from qb-out-0506.google.com (qb-out-0506.google.com [72.14.204.239]) by core3.amsl.com (Postfix) with ESMTP id 94FCA3A69A5 for ; Mon, 30 Jun 2008 15:33:07 -0700 (PDT) Received: by qb-out-0506.google.com with SMTP id c7so5432291qbc.9 for ; Mon, 30 Jun 2008 15:33:19 -0700 (PDT) Received: by 10.142.139.19 with SMTP id m19mr2142186wfd.25.1214865198644; Mon, 30 Jun 2008 15:33:18 -0700 (PDT) Received: from ?192.168.1.103? ( [67.188.243.194]) by mx.google.com with ESMTPS id 29sm12414252wfg.0.2008.06.30.15.33.17 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 30 Jun 2008 15:33:18 -0700 (PDT) Message-Id: <160799CD-046A-45FF-BAC7-C8349FBCB14B@shlang.com> From: Stanislav Shalunov To: Reinaldo Penno In-Reply-To: Mime-Version: 1.0 (Apple Message framework v924) Date: Mon, 30 Jun 2008 15:33:15 -0700 References: X-Mailer: Apple Mail (2.924) Cc: p2pi@ietf.org Subject: Re: [p2pi] New version of the problem statement X-BeenThere: p2pi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: P2P Infrastructure Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: p2pi-bounces@ietf.org Errors-To: p2pi-bounces@ietf.org On Jun 30, 2008, at 2:16 PM, Reinaldo Penno wrote: > * There are ISPs that want traffic within its AS because of cross-ISP > transit costs. Here traffic locality and caching would be good > solutions. > > * There are ISPs where transit cost is not the major problem. The most > pressing problem is upload/download between subscribers within its > AS. Peer > locality might not to help much here (actually could be make the > problem > worse). Caching or downloading from peers outside your own AS might > be a > better fit. > > * Then there are ISPs that actually want peers outside its AS to > download > from them. This allows them to argue for settlement free peering > since now > then send as much traffic as they receive from their upstream > provider. Agreed on the diverse needs. And note how caching is an answer to the first two and can easily be an answer for the third with a very simple config switch. -- Stanislav Shalunov http://shlang.com _______________________________________________ p2pi mailing list p2pi@ietf.org https://www.ietf.org/mailman/listinfo/p2pi From p2pi-bounces@ietf.org Mon Jun 30 15:48:59 2008 Return-Path: X-Original-To: p2pi-archive@ietf.org Delivered-To: ietfarch-p2pi-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D5B2F3A6B43; Mon, 30 Jun 2008 15:48:59 -0700 (PDT) X-Original-To: p2pi@core3.amsl.com Delivered-To: p2pi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 222983A6B43 for ; Mon, 30 Jun 2008 15:48:58 -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 4IBWmqgcujUk for ; Mon, 30 Jun 2008 15:48:57 -0700 (PDT) Received: from mailm.telecomitalia.it (mailm.telecomitalia.it [217.169.121.53]) by core3.amsl.com (Postfix) with ESMTP id B863B3A6B42 for ; Mon, 30 Jun 2008 15:48:56 -0700 (PDT) Received: from ptpxch007rm001.idc.cww.telecomitalia.it ([156.54.205.169]) by mailm.telecomitalia.it with Microsoft SMTPSVC(6.0.3790.1830); Tue, 1 Jul 2008 00:49:07 +0200 Received: from grfhub701rm001.griffon.local ([10.19.3.8]) by ptpxch007rm001.idc.cww.telecomitalia.it with Microsoft SMTPSVC(6.0.3790.1830); Tue, 1 Jul 2008 00:49:06 +0200 Received: from [172.16.82.18] (163.162.180.246) by smtp.telecomitalia.it (10.19.3.40) with Microsoft SMTP Server (TLS) id 8.1.278.0; Tue, 1 Jul 2008 00:49:06 +0200 Message-ID: <486962EA.1060906@telecomitalia.it> Date: Tue, 1 Jul 2008 00:49:14 +0200 From: Enrico Marocco User-Agent: Mozilla-Thunderbird 2.0.0.14 (X11/20080509) MIME-Version: 1.0 To: Stanislav Shalunov References: <48690985.4000906@telecomitalia.it> <54883F9F-8548-48A3-AC44-1FD3E261FEFB@bittorrent.com> <48692045.7060807@telecomitalia.it> In-Reply-To: X-OriginalArrivalTime: 30 Jun 2008 22:49:06.0845 (UTC) FILETIME=[80914CD0:01C8DB03] Cc: "p2pi@ietf.org" Subject: Re: [p2pi] New version of the problem statement X-BeenThere: p2pi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: P2P Infrastructure Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0127010115==" Sender: p2pi-bounces@ietf.org Errors-To: p2pi-bounces@ietf.org --===============0127010115== Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms050609060202030105060600" --------------ms050609060202030105060600 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Stanislav Shalunov wrote: > It's good if it can be made deployable by entities other than ISPs. > Who might be such third parties? I'd say communities in general. Nodes running distributed algorithms like Vivaldi or Meridian may easily implement the interface defined in ALTO, and such nodes are likely to be run on a volunteer basis just as mirrors for open-source software distributions (or eDonkey or Jabber servers) today are. Having third-parties in the game from the beginning would basically avoid ALTO to suffer from the same diffidence P2P users have in regard to ISPs. Then, at the end of the day, if the service provided by ISPs will result better than the others, I see no problem in it being adopted. -- Ciao, Enrico --------------ms050609060202030105060600 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 hkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wODA2MzAyMjQ5MTRaMCMG CSqGSIb3DQEJBDEWBBQFsrPJU7Mj99Iqa685snJKjvWfVzBfBgkqhkiG9w0BCQ8xUjBQMAsG CWCGSAFlAwQBAjAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAw BwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgYUGCSsGAQQBgjcQBDF4MHYwYjELMAkGA1UEBhMC WkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1Ro YXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAhAeTAANDUMJU97n0e1AWxu4MIGH BgsqhkiG9w0BCRACCzF4oHYwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25z dWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJ c3N1aW5nIENBAhAeTAANDUMJU97n0e1AWxu4MA0GCSqGSIb3DQEBAQUABIIBAG55E5P4HWBr 2j1py2D7viCBZd3+9aUcUnk2M3MyrKQzj03HKYuL/tA3vYj2NCVDkZpfyob1qTK7Cb2u6s9y yQlVUmOLcYllo3ndPgr4e3k0wGD7PSf2uXvw+6YXJDXq2joRabaxD6yxHtnXv6MA6YZhhnGR a3cCr1khysEEoWYCK/uC/o3c9Q8MLM+lBDQY0NU9H95cLKesSmzIM7nphKyPR60BSvKDa8BS gBTwcLZLPJVrYSLUU5F/5CM+dQTEvkC3/eLt0vfpVPsTijgcwRqa4EhLwXIMt3qtJTiatdkf IDIgtG6P4BTet1UzCcI2XOmJsOloe9YIA+c3V0wj4K8AAAAAAAA= --------------ms050609060202030105060600-- --===============0127010115== 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 --===============0127010115==-- From p2pi-bounces@ietf.org Mon Jun 30 16:35:05 2008 Return-Path: X-Original-To: p2pi-archive@ietf.org Delivered-To: ietfarch-p2pi-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2D1393A6918; Mon, 30 Jun 2008 16:35:05 -0700 (PDT) X-Original-To: p2pi@core3.amsl.com Delivered-To: p2pi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 53ACA3A695A for ; Mon, 30 Jun 2008 16:35:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.418 X-Spam-Level: X-Spam-Status: No, score=-2.418 tagged_above=-999 required=5 tests=[AWL=0.181, 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 J6cZS4n9mJt0 for ; Mon, 30 Jun 2008 16:35:03 -0700 (PDT) Received: from ag-out-0708.google.com (ag-out-0708.google.com [72.14.246.251]) by core3.amsl.com (Postfix) with ESMTP id 6ADB63A683A for ; Mon, 30 Jun 2008 16:35:03 -0700 (PDT) Received: by ag-out-0708.google.com with SMTP id 26so7802576agb.12 for ; Mon, 30 Jun 2008 16:35:12 -0700 (PDT) Received: by 10.142.51.4 with SMTP id y4mr2159531wfy.57.1214868911764; Mon, 30 Jun 2008 16:35:11 -0700 (PDT) Received: from ?192.168.1.103? ( [67.188.243.194]) by mx.google.com with ESMTPS id 24sm13258744wfc.3.2008.06.30.16.35.10 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 30 Jun 2008 16:35:11 -0700 (PDT) Message-Id: <9C750621-C46A-49A1-BE56-32D0168E4FAF@shlang.com> From: Stanislav Shalunov To: Enrico Marocco In-Reply-To: <486962EA.1060906@telecomitalia.it> Mime-Version: 1.0 (Apple Message framework v924) Date: Mon, 30 Jun 2008 16:35:08 -0700 References: <48690985.4000906@telecomitalia.it> <54883F9F-8548-48A3-AC44-1FD3E261FEFB@bittorrent.com> <48692045.7060807@telecomitalia.it> <486962EA.1060906@telecomitalia.it> X-Mailer: Apple Mail (2.924) Cc: "p2pi@ietf.org" Subject: Re: [p2pi] New version of the problem statement X-BeenThere: p2pi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: P2P Infrastructure Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: p2pi-bounces@ietf.org Errors-To: p2pi-bounces@ietf.org On Jun 30, 2008, at 3:49 PM, Enrico Marocco wrote: > Stanislav Shalunov wrote: >> It's good if it can be made deployable by entities other than ISPs. >> Who might be such third parties? > > I'd say communities in general. Nodes running distributed > algorithms like Vivaldi or Meridian may easily implement the > interface defined in ALTO, and such nodes are likely to be run on a > volunteer basis just as mirrors for open-source software > distributions (or eDonkey or Jabber servers) today are. > > Having third-parties in the game from the beginning would basically > avoid ALTO to suffer from the same diffidence P2P users have in > regard to ISPs. Then, at the end of the day, if the service > provided by ISPs will result better than the others, I see no > problem in it being adopted. Makes sense. -- Stanislav Shalunov http://shlang.com _______________________________________________ p2pi mailing list p2pi@ietf.org https://www.ietf.org/mailman/listinfo/p2pi From p2pi-bounces@ietf.org Mon Jun 30 16:49: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 D359A3A6A12; Mon, 30 Jun 2008 16:49: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 27F673A6A12 for ; Mon, 30 Jun 2008 16:49:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[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 BIX4N1jWKHsn for ; Mon, 30 Jun 2008 16:49:40 -0700 (PDT) Received: from barb.cs.washington.edu (barb.cs.washington.edu [128.208.2.42]) by core3.amsl.com (Postfix) with ESMTP id 899E73A67F2 for ; Mon, 30 Jun 2008 16:49:40 -0700 (PDT) X-Received: from dogmatix.dyn.cs.washington.edu (dogmatix.dyn.cs.washington.edu [128.208.7.170]) (authenticated bits=0) by barb.cs.washington.edu (8.14.1/8.14.1/1.10) with ESMTP id m5UNnKNi018410 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 30 Jun 2008 16:49:21 -0700 (envelope-from arvind@cs.washington.edu) Message-ID: <48697100.9000500@cs.washington.edu> Date: Mon, 30 Jun 2008 16:49:20 -0700 From: Arvind Krishnamurthy User-Agent: Thunderbird 2.0.0.14 (Macintosh/20080421) MIME-Version: 1.0 To: Enrico Marocco References: <48690985.4000906@telecomitalia.it> <54883F9F-8548-48A3-AC44-1FD3E261FEFB@bittorrent.com> <48692045.7060807@telecomitalia.it> <486962EA.1060906@telecomitalia.it> In-Reply-To: <486962EA.1060906@telecomitalia.it> Cc: "p2pi@ietf.org" , Stanislav Shalunov Subject: Re: [p2pi] New version of the problem statement X-BeenThere: p2pi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: P2P Infrastructure Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: p2pi-bounces@ietf.org Errors-To: p2pi-bounces@ietf.org Enrico Marocco wrote: > Stanislav Shalunov wrote: >> It's good if it can be made deployable by entities other than ISPs. >> Who might be such third parties? > > I'd say communities in general. Nodes running distributed algorithms > like Vivaldi or Meridian may easily implement the interface defined in > ALTO, and such nodes are likely to be run on a volunteer basis just as > mirrors for open-source software distributions (or eDonkey or Jabber > servers) today are. > > Having third-parties in the game from the beginning would basically > avoid ALTO to suffer from the same diffidence P2P users have in regard > to ISPs. Then, at the end of the day, if the service provided by ISPs > will result better than the others, I see no problem in it being adopted. > Hi Enrico, Just wanted to clarify as to whether the primary focus of ALTO is on improving application performance (as opposed to lowering ISP costs/loads)? Also wanted to point out that the different proposals floating around are trying to solve slightly different problems, and consequently provide different sets of incentives to the various parties involved (such as the iTracker/apptracker/clients). For instance, in p4p, the focus is more on alleviating the adversarial relationship between ISPs and P2P. The question then is: can P2P applications reduce ISP costs/loads *without* sacrificing on application-level performance - as opposed to proposals that are more focussed on just improving application-level performance *irrespective* of what happens to ISPs (and I would put network coordinates/Ono in that category). As an example, if applications establish peering connections based on just end-to-end latency considerations, the peerings might be sub-optimal from an ISP perspective, as latency and AS-path length are only weakly correlated (and we have a bunch of data to demonstrate that). Hence the question as to what is the primary objective, especially when the incentives are not perfectly aligned. Thanks, Arvind _______________________________________________ p2pi mailing list p2pi@ietf.org https://www.ietf.org/mailman/listinfo/p2pi From p2pi-bounces@ietf.org Mon Jun 30 20:02: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 BB5CB3A6782; Mon, 30 Jun 2008 20:02: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 5E04A3A6782 for ; Mon, 30 Jun 2008 20:02:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uD8mp0cNSeHd for ; Mon, 30 Jun 2008 20:02:22 -0700 (PDT) Received: from qb-out-0506.google.com (qb-out-0506.google.com [72.14.204.239]) by core3.amsl.com (Postfix) with ESMTP id 687CA3A63CB for ; Mon, 30 Jun 2008 20:02:21 -0700 (PDT) Received: by qb-out-0506.google.com with SMTP id c7so5663211qbc.9 for ; Mon, 30 Jun 2008 20:02:32 -0700 (PDT) Received: by 10.114.37.1 with SMTP id k1mr5076411wak.44.1214881352279; Mon, 30 Jun 2008 20:02:32 -0700 (PDT) Received: from ?192.168.1.103? ( [67.188.243.194]) by mx.google.com with ESMTPS id v35sm9247479wah.12.2008.06.30.20.02.27 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 30 Jun 2008 20:02:31 -0700 (PDT) Message-Id: <91AD05EE-11CB-46A6-B1F2-7E5F81AF37E2@bittorrent.com> From: Stanislav Shalunov To: p2pi@ietf.org In-Reply-To: Mime-Version: 1.0 (Apple Message framework v924) Date: Mon, 30 Jun 2008 20:00:52 -0700 References: <48690985.4000906@telecomitalia.it> <54883F9F-8548-48A3-AC44-1FD3E261FEFB@bittorrent.com> <48692045.7060807@telecomitalia.it> X-Mailer: Apple Mail (2.924) Subject: Re: [p2pi] New version of the problem statement X-BeenThere: p2pi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: P2P Infrastructure Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: p2pi-bounces@ietf.org Errors-To: p2pi-bounces@ietf.org On Jun 30, 2008, at 1:02 PM, Stanislav Shalunov wrote: > DSCP for discovery of local application-specific resources DHCP, of course. Drain bramage on my part. -- Stanislav Shalunov http://shlang.com _______________________________________________ p2pi mailing list p2pi@ietf.org https://www.ietf.org/mailman/listinfo/p2pi From p2pi-bounces@ietf.org Tue Jul 1 01:33: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 B626B3A6B3E; Tue, 1 Jul 2008 01:33: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 CD9B03A6B3E for ; Tue, 1 Jul 2008 01:33:27 -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 rckCQrfa4sql for ; Tue, 1 Jul 2008 01:33:27 -0700 (PDT) Received: from maile.telecomitalia.it (maile.telecomitalia.it [156.54.233.31]) by core3.amsl.com (Postfix) with ESMTP id 4C5BB3A6ADB for ; Tue, 1 Jul 2008 01:33:26 -0700 (PDT) Received: from ptpxch008ba020.idc.cww.telecomitalia.it ([156.54.240.51]) by maile.telecomitalia.it with Microsoft SMTPSVC(6.0.3790.1830); Tue, 1 Jul 2008 10:33:34 +0200 Received: from GRFHUB702BA020.griffon.local ([10.188.101.112]) by ptpxch008ba020.idc.cww.telecomitalia.it with Microsoft SMTPSVC(6.0.3790.1830); Tue, 1 Jul 2008 10:33:33 +0200 Received: from [10.229.8.44] (10.229.8.44) by smtp.telecomitalia.it (10.188.101.115) with Microsoft SMTP Server (TLS) id 8.1.278.0; Tue, 1 Jul 2008 10:33:33 +0200 Message-ID: <4869EBC6.4050503@telecomitalia.it> Date: Tue, 1 Jul 2008 10:33:10 +0200 From: Enrico Marocco User-Agent: Mozilla-Thunderbird 2.0.0.14 (X11/20080509) MIME-Version: 1.0 To: Arvind Krishnamurthy References: <48690985.4000906@telecomitalia.it> <54883F9F-8548-48A3-AC44-1FD3E261FEFB@bittorrent.com> <48692045.7060807@telecomitalia.it> <486962EA.1060906@telecomitalia.it> <48697100.9000500@cs.washington.edu> In-Reply-To: <48697100.9000500@cs.washington.edu> X-Enigmail-Version: 0.95.0 X-OriginalArrivalTime: 01 Jul 2008 08:33:33.0844 (UTC) FILETIME=[2620B540:01C8DB55] Cc: "p2pi@ietf.org" , Stanislav Shalunov Subject: Re: [p2pi] New version of the problem statement X-BeenThere: p2pi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: P2P Infrastructure Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1766814662==" Sender: p2pi-bounces@ietf.org Errors-To: p2pi-bounces@ietf.org --===============1766814662== Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms060301040406040302020101" --------------ms060301040406040302020101 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Arvind Krishnamurthy wrote: > Just wanted to clarify as to whether the primary focus > of ALTO is on improving application performance (as opposed > to lowering ISP costs/loads)? Both. For the most part of the industry (not all, of course), the primary focus is probably on lowering costs, but it seems quite straightforward that if a deployed solution is not beneficial to applications, it will just not get adopted. > Also wanted to point out that the different proposals > floating around are trying to solve slightly different > problems, and consequently provide different sets of > incentives to the various parties involved (such as > the iTracker/apptracker/clients). > > For instance, in p4p, the focus is more on alleviating > the adversarial relationship between ISPs and P2P. The > question then is: can P2P applications reduce ISP costs/loads > *without* sacrificing on application-level performance - as > opposed to proposals that are more focussed on just improving > application-level performance *irrespective* of what happens > to ISPs (and I would put network coordinates/Ono in that > category). As an example, if applications establish peering > connections based on just end-to-end latency considerations, > the peerings might be sub-optimal from an ISP perspective, as > latency and AS-path length are only weakly correlated (and we > have a bunch of data to demonstrate that). The goal is to design an interface which could be exposed by both types of systems. Some proposals seem to already have such a propriety (e.g. the "sorting oracle"), others will probably need some tweaking. I believe that, since it is unlikely that the use of ALTO services may be imposed, eventually competition will depend on the benefit they bring to applications. However, I am quite optimistic about ISP based solutions, as they show impressive improvements in applications performance: for example, the SIGCOMM P4P paper (you are a co-author of, btw) reports a 23% improvement in download completion time, which seems a very important achievement, especially if the main goal of the work was just to lower ISP costs. -- Ciao, Enrico --------------ms060301040406040302020101 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 hkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wODA3MDEwODMzMTBaMCMG CSqGSIb3DQEJBDEWBBRQOppXhk08SjW04GrHiQTHRWlUbTBfBgkqhkiG9w0BCQ8xUjBQMAsG CWCGSAFlAwQBAjAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAw BwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgYUGCSsGAQQBgjcQBDF4MHYwYjELMAkGA1UEBhMC WkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1Ro YXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAhAeTAANDUMJU97n0e1AWxu4MIGH BgsqhkiG9w0BCRACCzF4oHYwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25z dWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJ c3N1aW5nIENBAhAeTAANDUMJU97n0e1AWxu4MA0GCSqGSIb3DQEBAQUABIIBAHjZyNK2j9sS FbYQWbIfKZ8nWszXWq4gF9p4uZ5KM/TC9YhPtk3ZI8YcaUcshW29916HwP6PtBAzx9qv4M0V R03k0d6/oHS1PAip7yziH6vWXS4Z9ijsIA5kkM1eTrTMxam7ejjwnGH2RSCCiBkkaF2Ksxcc QNDsWeS/Y6hyx4CytZJ7Ph0Sd4eD41ZnWNb4br+QHGRfLrGRXhWLsW7LHg80y/W+VZ2ZTZMZ mmFfbBuoij+5dXlwy2w9wj5Dt7nYCAGu4HxAl9nfXKl5sQUNnQ9C3Hv9OCQ+tatDJPuHiSxV yPJCtq/C+zHq2k6b0DtXXeDimDA46JsKB1JyzL0+P4wAAAAAAAA= --------------ms060301040406040302020101-- --===============1766814662== 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 --===============1766814662==--