From p2pi-bounces@ietf.org Fri Aug 1 03:56: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 C8AF328C31A; Fri, 1 Aug 2008 03:56: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 A92BD28C31C for ; Fri, 1 Aug 2008 03:56:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.858 X-Spam-Level: X-Spam-Status: No, score=-5.858 tagged_above=-999 required=5 tests=[AWL=0.141, BAYES_00=-2.599, J_CHICKENPOX_57=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F3HlMVcWBJx8 for ; Fri, 1 Aug 2008 03:56:25 -0700 (PDT) Received: from exprod7og110.obsmtp.com (exprod7og110.obsmtp.com [64.18.2.173]) by core3.amsl.com (Postfix) with ESMTP id B281D28C292 for ; Fri, 1 Aug 2008 03:56:22 -0700 (PDT) Received: from source ([66.129.228.6]) by exprod7ob110.postini.com ([64.18.6.12]) with SMTP; Fri, 01 Aug 2008 03:56:12 PDT Received: from p-emlb02-sac.jnpr.net ([66.129.254.47]) by p-emsmtp03.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Fri, 1 Aug 2008 03:53:56 -0700 Received: from emailwf1.jnpr.net ([10.10.2.33]) by p-emlb02-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Fri, 1 Aug 2008 03:53:56 -0700 Received: from proton.jnpr.net ([10.10.2.37]) by emailwf1.jnpr.net with Microsoft SMTPSVC(6.0.3790.1830); Fri, 1 Aug 2008 06:53:54 -0400 Received: from 172.23.1.57 ([172.23.1.57]) by proton.jnpr.net ([10.10.2.37]) with Microsoft Exchange Server HTTP-DAV ; Fri, 1 Aug 2008 10:53:54 +0000 User-Agent: Microsoft-Entourage/12.11.0.080522 Date: Fri, 01 Aug 2008 03:53:49 -0700 From: Reinaldo Penno To: Laird Popkin , Bob Briscoe Message-ID: Thread-Topic: [p2pi] p2p localization and transit vs. local traffic Thread-Index: AcjzxODBr/CFLfN79UyBZoBs2DS5Ug== In-Reply-To: <574573834.93971217580154524.JavaMail.root@dkny.pando.com> Mime-version: 1.0 X-OriginalArrivalTime: 01 Aug 2008 10:53:54.0776 (UTC) FILETIME=[E4333580:01C8F3C4] Cc: Ivica Rimac , p2pi@ietf.org Subject: Re: [p2pi] p2p localization and transit vs. local traffic X-BeenThere: p2pi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: P2P Infrastructure Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: p2pi-bounces@ietf.org Errors-To: p2pi-bounces@ietf.org Hello Laird, Regarding your first point. If you have users 1..N downloading from the Internet which increases inter-domain and downstream links, if they start downloading from their neighbors that by definition increases uplink congestion doesn't it? The above is not true unless you assume that P2P users upload a certain amount of bandwidth irrespective of the peer. But (and you probably have more data on this) although you might localize downstream, and if upstream is not localized (or on the other hand allows for more bandwidth), you definitely get more upstream, right? The premise is that you are telling peer A or others peers in its local network that peer A would not have chosen otherwise. Finally, I would like to understand if any of the P4P tests have been down with PEX and DHT fully enabled? I would like if possible to understand the dynamics of ALTO suggesting a few peers whereas a peer learn 3000 other peers through other means you cannot control. Some data I've seen shows a peer can easily learn all peers in a huge swarm much faster than we could influence its behavior. Anyway, although ALTO can produce a protocol the dynamics of such system should be captured. Thanks, Reinaldo On 8/1/08 1:42 AM, "Laird Popkin" wrote: > Field test data does not support the assertion that "If a sink moves its > traffic source from a remote peer to a local one, that's more traffic on the > local upstream and less on the remote > upstream and less on the interconnect." I think that you're thinking only > about internal data transfer, and forgetting that the users are currently > uploading not only to other customers of the same ISP (2% of the time, on > average), but also (98% of the time, on average) to users on the rest of the > internet. While there's a alrge increase in local upstream uploading to other > customers of the same ISP, there's a cooresponding drop in local upstream > uploading to the general internet. So far in field testing the two effects > balance each other out, so total uplink consumption doesn't change much. > > Regarding "This also says the P2P network has the best info to help the > oracle, > not the individual ISPs which only have topology info and partial > congestion info." I would modify this to say that neither the p2p network nor > the ISP have sufficient information in isolation to make the best peer > assignment selections. So (IMO, of course) the ISP should provide information > to the p2p network that, in combination with what the p2p network knows, > allows it to make better peer assignment selections. Specifically, the p2p > network knows a lot about peer network profile (e.g. firewalled, current > utilization) and the ISP knows about network topology, and by working together > the two can make much better choices than either by themselves. > > - Laird Popkin, CTO, Pando Networks > mobile: 646/465-0570 > > ----- Original Message ----- > From: "Bob Briscoe" > To: "Ivica Rimac" > Cc: p2pi@ietf.org > Sent: 01 August 2008 01:31:59 o'clock (GMT) Europe/London > Subject: Re: [p2pi] p2p localization and transit vs. local traffic > > Ivica, > > At 23:08 31/07/2008, Ivica Rimac wrote: >> Bob, >> >> but isn't a P2P content network's self-scaling property based on the >> assumption that each peer sources as much data as it consumes (at >> least in average)? I.e., the total amount of data sourced from peers >> sholdn't change > > Agreed, but... > >> and even with a pure random peer selection approach (a la BT) peers >> have a chance of being selected by other (local or remote) peers as sources. > > I'm not saying random is good. I'm saying localisation is not good. > And there's a better way... > >> I do not see transit reduction generally implying an increase in >> local network traffic other then when the P2P network is running in >> surplus mode. > > Eh? If a sink moves its traffic source from a remote peer to a local > one, that's more traffic on the local upstream and less on the remote > upstream and less on the interconnect. > > I'm saying the best allocation is congestion minimisation. Which is > significantly different from topological localisation. > > Some networks have less upstream congestion than others as a result > of their design constraints (e.g. DSL vs cable). So using a certain > amount of interconnect between the two types is more optimal than > localising within one type. But /only/ until congestion 'balances > out' to minimum everywhere. > > A good modern congestion control is good at congestion minimisation > (but note that TCP has the 1/RTT artefact that skews matters unlike > more modern controls - see my slides). > > So if you want to judge whether an oracle is performing well, > - don't judge how well it localises > - judge whether it bootstraps connections in the same pattern that > BitTorrent DNA would evolve to - given enough time. > > This also says the P2P network has the best info to help the oracle, > not the individual ISPs which only have topology info and partial > congestion info. > > > Bob > > >> -ivica >> >> >>>>> Addressing remark 1: localizing network traffic (based on the >>>> p4p >field tests, which used ISP network maps and an "oracle") >>>> shows a >strong benefit in transit reduction and in performance >>>> improvement, >for networks that are DSL, Cable or FTTH. >>> I think my rather important previous point got missed (sorry my >>> mail had a lot of points)... >>> Neither of these metrics for 'better' impresses me much at all. >>> * If performance of p2p is better, and if there is shared >>> congestion with other non-p2p users on the same local network, this >>> means the performance of others will most likely be worse. Overall, >>> is this better or worse? >>> * If there's transit reduction, equivalent traffic will instead be >>> being uploaded from the local network. Again, if the local network >>> already has shared congestion upstream (a cable network does), >>> that's making it _worse_ both for local p2p & non-p2p users. >>> >>> It costs more (bit for bit) to upgrade access and backhaul than it >>> does to upgrade interconnect (there's a considerable economy of >>> scale). If someone from a cablecco has told you it's most important >>> to reduce transit costs, you'll find they did NOT mean "and at the >>> same time please introduce higher backhaul and access costs instead". >> >> -- >> Ivica Rimac Bell Labs / Alcatel-Lucent >> Email: rimac@bell-labs.com 791 Holmdel-Keyport Road >> Phone: +1-732-888-7205 Holmdel, NJ 07733, USA >> >> > > ____________________________________________________________________________ > Bob Briscoe, Networks Research Centre, BT Research > B54/77 Adastral Park,Martlesham Heath,Ipswich,IP5 3RE,UK. +44 1473 645196 > > > _______________________________________________ > p2pi mailing list > p2pi@ietf.org > https://www.ietf.org/mailman/listinfo/p2pi > _______________________________________________ > p2pi mailing list > p2pi@ietf.org > https://www.ietf.org/mailman/listinfo/p2pi _______________________________________________ p2pi mailing list p2pi@ietf.org https://www.ietf.org/mailman/listinfo/p2pi From p2pi-bounces@ietf.org Fri Aug 1 05:45: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 F000228C4DD; Fri, 1 Aug 2008 05:45: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 726B628C4CD for ; Fri, 1 Aug 2008 05:45:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.665 X-Spam-Level: X-Spam-Status: No, score=-9.665 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HABEAS_ACCREDITED_COI=-8, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_57=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nOGi0LIVsW+L for ; Fri, 1 Aug 2008 05:45:52 -0700 (PDT) Received: from dkny.pando.com (dkny.pando.com [67.99.55.163]) by core3.amsl.com (Postfix) with ESMTP id 3C53228C6B0 for ; Fri, 1 Aug 2008 05:23:19 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by dkny.pando.com (Postfix) with ESMTP id C747AE10A96; Fri, 1 Aug 2008 08:23:25 -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 ugzHhZ-Kty0A; Fri, 1 Aug 2008 08:23:16 -0400 (EDT) Received: from [192.168.1.9] (unknown [83.71.255.41]) by dkny.pando.com (Postfix) with ESMTP id A04FCE10AF8; Fri, 1 Aug 2008 08:23:15 -0400 (EDT) Message-Id: From: Laird Popkin To: Reinaldo Penno In-Reply-To: Mime-Version: 1.0 (Apple Message framework v928.1) Date: Fri, 1 Aug 2008 08:22:44 -0400 References: X-Mailer: Apple Mail (2.928.1) Cc: p2pi@ietf.org, Ivica Rimac Subject: Re: [p2pi] p2p localization and transit vs. local traffic X-BeenThere: p2pi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: P2P Infrastructure Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: p2pi-bounces@ietf.org Errors-To: p2pi-bounces@ietf.org On Aug 1, 2008, at 6:53 AM, Reinaldo Penno wrote: > Hello Laird, > > Regarding your first point. If you have users 1..N downloading from > the > Internet which increases inter-domain and downstream links, if they > start > downloading from their neighbors that by definition increases uplink > congestion doesn't it? > > The above is not true unless you assume that P2P users upload a > certain > amount of bandwidth irrespective of the peer. But (and you probably > have > more data on this) although you might localize downstream, and if > upstream > is not localized (or on the other hand allows for more bandwidth), you > definitely get more upstream, right? The premise is that you are > telling > peer A or others peers in its local network that peer A would not have > chosen otherwise. In the most recent P4P test we preferentially connected peers within the same ISP, with the result that while there was increased demand for uplink to send data to same-ISP peers, there was decreased demand for uplink to send data to other-ISP peers. Note that localizing p2p peer connections localizes both uplink and downlink transit, since p2p connections are bi-directional. For example, peers connect out to other peers in order to send them data, not just to receive data from them. > Finally, I would like to understand if any of the P4P tests have > been down > with PEX and DHT fully enabled? I would like if possible to > understand the > dynamics of ALTO suggesting a few peers whereas a peer learn 3000 > other > peers through other means you cannot control. This is a very good question; in the tests we used P4P guidance in combination with 'random' peers. Specifically, in the tests we used P4P iTracker (AKA ALTO server) guidance to give peers 80% of their peer assignments, and gave 20% random peers so that the swarm wasn't completely segmented. In addition, we perform peer exchange, so over time peers learn about the entire swarm. This did not appear to reduce the benefit of traffic localization, because our software (like many others) optimizes to use the fastest data sources, so if the local data sources are fastest, they continue to be used, and remote data sources are relatively unused. And if the remote data sources are faster than the local ones, we _want_ to use them, for improved performance, even at the cost of some increased transit use. > Some data I've seen shows a peer can easily learn all peers in a > huge swarm > much faster than we could influence its behavior. Yes, peers can learn the addresses of the other peers fairly quickly. The part that takes time is in exchanging data with each peer and measuring the throughput in order to determine which peers are fastest. It takes about 2 second per peer to do a quick data exchange to measure throughput, so a swarm of 1,000 peers would take perhaps 2,000 seconds to profile all peers in the swarm. Of course, this is an incremental process, so in 1,000 seconds half of the swarm would have been profiled, etc. > Anyway, although ALTO can produce a protocol the dynamics of such > system > should be captured. > > Thanks, > > Reinaldo > > > On 8/1/08 1:42 AM, "Laird Popkin" wrote: > >> Field test data does not support the assertion that "If a sink >> moves its >> traffic source from a remote peer to a local one, that's more >> traffic on the >> local upstream and less on the remote >> upstream and less on the interconnect." I think that you're >> thinking only >> about internal data transfer, and forgetting that the users are >> currently >> uploading not only to other customers of the same ISP (2% of the >> time, on >> average), but also (98% of the time, on average) to users on the >> rest of the >> internet. While there's a alrge increase in local upstream >> uploading to other >> customers of the same ISP, there's a cooresponding drop in local >> upstream >> uploading to the general internet. So far in field testing the two >> effects >> balance each other out, so total uplink consumption doesn't change >> much. >> >> Regarding "This also says the P2P network has the best info to help >> the >> oracle, >> not the individual ISPs which only have topology info and partial >> congestion info." I would modify this to say that neither the p2p >> network nor >> the ISP have sufficient information in isolation to make the best >> peer >> assignment selections. So (IMO, of course) the ISP should provide >> information >> to the p2p network that, in combination with what the p2p network >> knows, >> allows it to make better peer assignment selections. Specifically, >> the p2p >> network knows a lot about peer network profile (e.g. firewalled, >> current >> utilization) and the ISP knows about network topology, and by >> working together >> the two can make much better choices than either by themselves. >> >> - Laird Popkin, CTO, Pando Networks >> mobile: 646/465-0570 >> >> ----- Original Message ----- >> From: "Bob Briscoe" >> To: "Ivica Rimac" >> Cc: p2pi@ietf.org >> Sent: 01 August 2008 01:31:59 o'clock (GMT) Europe/London >> Subject: Re: [p2pi] p2p localization and transit vs. local traffic >> >> Ivica, >> >> At 23:08 31/07/2008, Ivica Rimac wrote: >>> Bob, >>> >>> but isn't a P2P content network's self-scaling property based on the >>> assumption that each peer sources as much data as it consumes (at >>> least in average)? I.e., the total amount of data sourced from peers >>> sholdn't change >> >> Agreed, but... >> >>> and even with a pure random peer selection approach (a la BT) peers >>> have a chance of being selected by other (local or remote) peers >>> as sources. >> >> I'm not saying random is good. I'm saying localisation is not good. >> And there's a better way... >> >>> I do not see transit reduction generally implying an increase in >>> local network traffic other then when the P2P network is running in >>> surplus mode. >> >> Eh? If a sink moves its traffic source from a remote peer to a local >> one, that's more traffic on the local upstream and less on the remote >> upstream and less on the interconnect. >> >> I'm saying the best allocation is congestion minimisation. Which is >> significantly different from topological localisation. >> >> Some networks have less upstream congestion than others as a result >> of their design constraints (e.g. DSL vs cable). So using a certain >> amount of interconnect between the two types is more optimal than >> localising within one type. But /only/ until congestion 'balances >> out' to minimum everywhere. >> >> A good modern congestion control is good at congestion minimisation >> (but note that TCP has the 1/RTT artefact that skews matters unlike >> more modern controls - see my slides). >> >> So if you want to judge whether an oracle is performing well, >> - don't judge how well it localises >> - judge whether it bootstraps connections in the same pattern that >> BitTorrent DNA would evolve to - given enough time. >> >> This also says the P2P network has the best info to help the oracle, >> not the individual ISPs which only have topology info and partial >> congestion info. >> >> >> Bob >> >> >>> -ivica >>> >>> >>>>>> Addressing remark 1: localizing network traffic (based on the >>>>> p4p >field tests, which used ISP network maps and an "oracle") >>>>> shows a >strong benefit in transit reduction and in performance >>>>> improvement, >for networks that are DSL, Cable or FTTH. >>>> I think my rather important previous point got missed (sorry my >>>> mail had a lot of points)... >>>> Neither of these metrics for 'better' impresses me much at all. >>>> * If performance of p2p is better, and if there is shared >>>> congestion with other non-p2p users on the same local network, this >>>> means the performance of others will most likely be worse. Overall, >>>> is this better or worse? >>>> * If there's transit reduction, equivalent traffic will instead be >>>> being uploaded from the local network. Again, if the local network >>>> already has shared congestion upstream (a cable network does), >>>> that's making it _worse_ both for local p2p & non-p2p users. >>>> >>>> It costs more (bit for bit) to upgrade access and backhaul than it >>>> does to upgrade interconnect (there's a considerable economy of >>>> scale). If someone from a cablecco has told you it's most important >>>> to reduce transit costs, you'll find they did NOT mean "and at the >>>> same time please introduce higher backhaul and access costs >>>> instead". >>> >>> -- >>> Ivica Rimac Bell Labs / Alcatel-Lucent >>> Email: rimac@bell-labs.com 791 Holmdel-Keyport Road >>> Phone: +1-732-888-7205 Holmdel, NJ 07733, USA >>> >>> >> >> ____________________________________________________________________________ >> Bob Briscoe, Networks Research Centre, BT >> Research >> B54/77 Adastral Park,Martlesham Heath,Ipswich,IP5 3RE,UK. +44 >> 1473 645196 >> >> >> _______________________________________________ >> p2pi mailing list >> p2pi@ietf.org >> https://www.ietf.org/mailman/listinfo/p2pi >> _______________________________________________ >> p2pi mailing list >> p2pi@ietf.org >> https://www.ietf.org/mailman/listinfo/p2pi > _______________________________________________ p2pi mailing list p2pi@ietf.org https://www.ietf.org/mailman/listinfo/p2pi From p2pi-bounces@ietf.org Sat Aug 2 08:44: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 812AD3A6938; Sat, 2 Aug 2008 08:44: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 D0C303A68C6 for ; Sat, 2 Aug 2008 08:44:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.785 X-Spam-Level: X-Spam-Status: No, score=-0.785 tagged_above=-999 required=5 tests=[AWL=0.732, BAYES_00=-2.599, DNS_FROM_RFC_BOGUSMX=1.482, J_CHICKENPOX_57=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mQvFIcRs2QDo for ; Sat, 2 Aug 2008 08:44:02 -0700 (PDT) Received: from smtp4.smtp.bt.com (smtp4.smtp.bt.com [217.32.164.151]) by core3.amsl.com (Postfix) with ESMTP id 4B6343A68CD for ; Sat, 2 Aug 2008 08:44:01 -0700 (PDT) Received: from i2kc08-ukbr.domain1.systemhost.net ([193.113.197.71]) by smtp4.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 2 Aug 2008 16:44:24 +0100 Received: from cbibipnt08.iuser.iroot.adidom.com ([147.149.100.81]) by i2kc08-ukbr.domain1.systemhost.net with Microsoft SMTPSVC(6.0.3790.1830); Sat, 2 Aug 2008 16:44:23 +0100 Received: From bagheera.jungle.bt.co.uk ([132.146.168.158]) by cbibipnt08.iuser.iroot.adidom.com (WebShield SMTP v4.5 MR1a P0803.399); id 1217691865517; Sat, 2 Aug 2008 16:44:25 +0100 Received: from mut.jungle.bt.co.uk ([10.73.65.33]) by bagheera.jungle.bt.co.uk (8.13.5/8.12.8) with ESMTP id m72FiHUC003709; Sat, 2 Aug 2008 16:44:19 +0100 Message-Id: <200808021544.m72FiHUC003709@bagheera.jungle.bt.co.uk> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Sat, 02 Aug 2008 16:50:00 +0100 To: "PAPADIMITRIOU Dimitri" From: Bob Briscoe In-Reply-To: <00275A5B436CA441900CB10936742A38DFAD26@FRVELSMBS22.ad2.ad. alcatel.com> References: <20080731143742.GM10916@cisco.com> <9D30D134-8BDA-4305-AD97-033B3538342C@cisco.com> <200807312346.m6VNk432028583@bagheera.jungle.bt.co.uk> <00275A5B436CA441900CB10936742A38DFAD26@FRVELSMBS22.ad2.ad.alcatel.com> Mime-Version: 1.0 X-Scanned-By: MIMEDefang 2.56 on 132.146.168.158 X-OriginalArrivalTime: 02 Aug 2008 15:44:23.0819 (UTC) FILETIME=[A321DDB0:01C8F4B6] Cc: Toerless Eckert , p2pi@ietf.org Subject: Re: [p2pi] DSCP or not X-BeenThere: p2pi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: P2P Infrastructure Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: p2pi-bounces@ietf.org Errors-To: p2pi-bounces@ietf.org Dimitri, At 08:53 01/08/2008, PAPADIMITRIOU Dimitri wrote: > > -----Original Message----- > > From: p2pi-bounces@ietf.org [mailto:p2pi-bounces@ietf.org] On > > Behalf Of Bob Briscoe > > Sent: Friday, August 01, 2008 1:46 AM > > To: Henning Schulzrinne > > Cc: p2pi@ietf.org; Toerless Eckert > > Subject: Re: [p2pi] DSCP or not > > > > Henning, etc > > > > Yes, access is the pinch point (and interconnect). > > > > But your facts aren't quite right on DSL... > > The user's own DSL upstream access is certainly a bottleneck (so > > you'd just have to buy a home hub that does Diffserv). But there's > > absolutely never any congestion on the shared upstream backhaul > > (because it's symmetric but fed by the asymmetric access). > >previous post correctly point that in the upstream direction the >bottleneck is on the first mile access link. [BB] You & I are agreeing, but... The sentence of Henning's I was correcting was "...the important link limit in both cable and DSL is the uplink". I was pointing out (as you agree below) that downstream DSL backhaul is often congested too, and the upstream DSL backhaul is not congested at all. >in the downstream direction >and considering a pure distribution tree the (main) bottleneck is on the >link toward the aggr. network of the edge router playing the role of NAS >(see > >for inst.) since distribution of traffic can only have a lower >granularity down the tree. > >note: access contains the first mile and the metro-access for aggr. if >you consider the figure you made use in your previous pointer you have >simplified that aggr. network to a backhaul link. while multiple aggr. >nodes may be comprised. [BB] Most certainly. I said I had only shown how the network looks to IP (logical not physical topology). [BB] One big simplifaction I made was to show all the backhaul links to the BRAS as if they don't cross the core, whereas there's often point-point (L2 over L3) pseudowires from each DSLAM across the core to each particular ISP's own BRAS(s). But as the core segments of these links are rarely if ever congested, I simplified them out of the picture. >note also that these network are progressively >becoming more meshy. [BB] Indeed. And the multiplexing helps reduce costs and therefore makes it cheaper to upgrade out of congestion ('resource pooling' if you saw Mark Handley's talk). [BB] But wholesale business models still don't know how to sell capacity across a mesh without turning it into a load of nailed up pipes and losing the resource pooling gain. We have been sponsoring research on this, to extend the promising contract and balancing approach [Anderson06] from just shared links to a shared mesh. > > [snip] > > Regarding vendor support for Diffserv on BRASs, many support it, but > > most vendors offer fairly limited numbers of queues and you may find > > all the queues are already used for other scheduling stuff the > > provider has already put in (weighted fair queueing between ISPs > > sharing the BRAS, video services, VoIP etc). > > >what do you call a "fairly limited" number of queues ? per subscriber >and per traffic class queuing are available on such devices. access >nodes can also provide for the same capability (using e.g. VLAN per >subscriber). the main point will be to consider a representative >baseline scenario for this type of exercise. [BB] There's a wide range out there depending on which vendor and model the ISP or operator bought. Some only have enough queues to do per-ISP or per-service scheduling, while others have enough for 3 or 4 per user. I really don't know all the details across the range, and I'd rather not start giving selective brochure stats on the models I know about, as the thread will just become a vendor beauty contest. [BB] But if someone could give a wider range of product info than I know, that would be worth hearing - to get a better feel for what most ISPs would be able to do with their current equipment. > > IOW, there's already a > > lot of scheduling stuff done in access networks - much of it is > > Diffserv-based - ie driven by internally generated DSCPs - but much > > is just nailed up by the provider config locally on the link > > in question. > > >The key question is what will be the boundary of the DS domain and >whether we will see or not (re-)classification and re-marking at the AN >even when the CPE is performing the job. if this is the case then which >MF classification should be used. [BB] Yes. And whether DS markings will be copied down to the encapsulating lower layer for the large majority of current access equipment that isn't IP-aware, but could do scheduling (e.g. 802.1p). > > [snip] > > The main issue for DS is of course the interface with hosts. But also > > that networks have to add policing to BE once BE is better than > > something else. But everyone's guessing when they work out how to do > > this, because they can't use traditional Diffserv token bucket > > policing for residential customers - the traffic isn't aggregated > > enough. So it's all volume limits and arbitrary stuff being > > bandied about. > > >the exact reason why you have an aggregation network in between. now >this does not prevent the use of DS at these boundaries. [BB] I'm sure it doesn't prevent using DS, but it does prevent re-using all the theory on which DS policing was built. The existence of an aggregation network doesn't solve the fact that /each customer's/ traffic isn't sufficiently aggregated to police separately as in all the theory built up for traditional DS policing where each single (enterprise) customers' traffic is sufficiently aggregated already. > > However, I've also tried to show that it's not all downhill for > > host-based scavenger either, tho I think it has more chance of > > getting there first (in a sense it already has with DNA) but I > > predict issues we haven't seen yet, which is why TANA is right to at > > least aim to document the issue as a whole. > > >i agree but the assumption made when documenting these issues shall be >representative - caricaturing and limiting capabilities of access >networks as they used to be, would not be of any help. [BB] Like you, I prefer to think about the future. But TANA seems very focused on only a few months away. In that case, there's a huge amount of access equipment that isn't going to be obsoleted any time soon - this stuff represents the largest part of a residential operator's sunk investment. [BB] Reference: [Anderson06] Edward Anderson, Frank Kelly and Richard Steinberg, "A Contract and Balancing Mechanism for Sharing Capacity in a Communication Network," In: Management Science 52 pp. 39--53 (2006). Bob >-d. > > ____________________________________________________________________________ Bob Briscoe, Networks Research Centre, BT Research B54/77 Adastral Park,Martlesham Heath,Ipswich,IP5 3RE,UK. +44 1473 645196 _______________________________________________ p2pi mailing list p2pi@ietf.org https://www.ietf.org/mailman/listinfo/p2pi From p2pi-bounces@ietf.org Sat Aug 2 08:48: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 CB3703A695E; Sat, 2 Aug 2008 08:48: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 C1B8B3A68C6 for ; Sat, 2 Aug 2008 08:48:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.82 X-Spam-Level: X-Spam-Status: No, score=-0.82 tagged_above=-999 required=5 tests=[AWL=0.697, BAYES_00=-2.599, DNS_FROM_RFC_BOGUSMX=1.482, J_CHICKENPOX_57=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E2BVxyukfF9t for ; Sat, 2 Aug 2008 08:47:54 -0700 (PDT) Received: from smtp2.smtp.bt.com (smtp2.smtp.bt.com [217.32.164.150]) by core3.amsl.com (Postfix) with ESMTP id 4BE963A6830 for ; Sat, 2 Aug 2008 08:47:54 -0700 (PDT) Received: from i2kc08-ukbr.domain1.systemhost.net ([193.113.197.71]) by smtp2.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 2 Aug 2008 16:48:14 +0100 Received: from cbibipnt08.iuser.iroot.adidom.com ([147.149.100.81]) by i2kc08-ukbr.domain1.systemhost.net with Microsoft SMTPSVC(6.0.3790.1830); Sat, 2 Aug 2008 16:48:14 +0100 Received: From bagheera.jungle.bt.co.uk ([132.146.168.158]) by cbibipnt08.iuser.iroot.adidom.com (WebShield SMTP v4.5 MR1a P0803.399); id 1217692095955; Sat, 2 Aug 2008 16:48:15 +0100 Received: from mut.jungle.bt.co.uk ([10.73.65.33]) by bagheera.jungle.bt.co.uk (8.13.5/8.12.8) with ESMTP id m72Fm94L003784; Sat, 2 Aug 2008 16:48:11 +0100 Message-Id: <200808021548.m72Fm94L003784@bagheera.jungle.bt.co.uk> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Sat, 02 Aug 2008 17:18:00 +0100 To: Philip Levis From: Bob Briscoe In-Reply-To: References: <1232737442.90411217507981759.JavaMail.root@dkny.pando.com> <1959788251.90461217508317275.JavaMail.root@dkny.pando.com> <200807311754.m6VHsBVg000355@bagheera.jungle.bt.co.uk> Mime-Version: 1.0 X-Scanned-By: MIMEDefang 2.56 on 132.146.168.158 X-OriginalArrivalTime: 02 Aug 2008 15:48:14.0337 (UTC) FILETIME=[2C881F10:01C8F4B7] Cc: p2pi@ietf.org Subject: Re: [p2pi] why I didn't hum yes (yet) X-BeenThere: p2pi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: P2P Infrastructure Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: p2pi-bounces@ietf.org Errors-To: p2pi-bounces@ietf.org Phil, See end... At 02:14 01/08/2008, Philip Levis wrote: >On Jul 31, 2008, at 6:54 PM, Bob Briscoe wrote: > >>Laird, >> >>At 13:45 31/07/2008, Laird Popkin wrote: >>>Addressing remark 1: localizing network traffic (based on the p4p >>>field tests, which used ISP network maps and an "oracle") shows a >>>strong benefit in transit reduction and in performance improvement, >>>for networks that are DSL, Cable or FTTH. >> >>I think my rather important previous point got missed (sorry my mail >>had a lot of points)... >> >>Neither of these metrics for 'better' impresses me much at all. >> >>* If performance of p2p is better, and if there is shared congestion >>with other non-p2p users on the same local network, this means the >>performance of others will most likely be worse. Overall, is this >>better or worse? >> >>* If there's transit reduction, equivalent traffic will instead be >>being uploaded from the local network. Again, if the local network >>already has shared congestion upstream (a cable network does), >>that's making it _worse_ both for local p2p & non-p2p users. >> >> >>It costs more (bit for bit) to upgrade access and backhaul than it >>does to upgrade interconnect (there's a considerable economy of >>scale). If someone from a cablecco has told you it's most important >>to reduce transit costs, you'll find they did NOT mean "and at the >>same time please introduce higher backhaul and access costs instead". >> >>See the picture I posted yesterday to this list: >>> > >> >>The Internetwork is provided to be used. Let's not assume a >>DISINTERNET is 'better' without being clear what 'better' means. >> >>I've seen no research that uses a full cost-benefit analysis. That's >>hard (e.g. what's the relative value of p2p bits versus non-p2p >>bits). But without such a study, unfortunately, what everyone is >>calling 'better' looks like 'worse' to me on second looks - at least >>for networks with a congested upstream. >> >>On third looks (ie a full study) it might not be worse. But can >>people please enter this debate on the assumption that network >>economics is dangerous in the hands of amateurs (which includes the >>large majority of folks even in telcos/cablecos). > > >Bob, I think you're getting lost in the weeds here. > >The goal is to define a mechanism by which entities with a greater >knowledge of the network can provide guidance to clients on whom those >clients might want to communicate with. I'm well aware of this and not getting lost in the weeds. I'm trying to me very clear: I'm saying: If it were just a localisation problem it would be easy to standardise. As it's not proven that it's a simple localisation problem, this is probably still research. >This guidance could be based on localization, or it could be based on >other properties which turn out to be better but we have not >discovered yet. The interface proposed, (X,Y,Z) -> (Z), does not >assume localization. Doing so would be folly, as it would preclude >using the mechanism for applications which are better served by other >selection policies. As I said in my mail, many P4P folks know there's more to it than localisation and I was happy they emphasised this at the p2pi workshop. But in ALTO, a different bunch of people seemed to have taken over the asylum, all of whom said "localisation is the goal". To the uninitiated, this makes it look like it's a simple task, and ready for standardisation. So far, most experimentation with oracles has made localisation the goal then proved (unsurprisingly) they've achieved more localisation. They often say that in practice policies and congestion might need to be taken into account, and that their framework allows for these extensions. But unsurprisingly no-one's fully taken that step. Because that's the really hard bit - particularly congestion, because the endpoints know more than the network. To be clear, I'm not saying do nothing until it's perfect. I'm saying we can't judge whether it's even 'better' while the research makes claims of 'better' against the wrong metric. >That being said, the points in your slides are interesting. Do you >have any real and repeatable experimental evidence that it's "worse?" No; I'm not doing research on oracles. I was just acting as a critical research reviewer. The experimental evidence being quoted from trials and simulations seemed to be using bogus metrics for claims of 'better'. less transit != better (not unconditionally) better p2p performance != better (not necessarily) >I'll admit that none of the experimental studies cover every single >edge case -- they would then be so voluminous as to be unreadable -- >but I'm tempted to trust experimental data collected from real >networks over back-of-the-envelope calculations. Just because I gave a very common scenario where localisation is unlikely to work, doesn't mean I'm asking researchers to exhaustively cover all scenarios. I'm asking them to use the right metric for 'better', whatever representative scenarios they choose. Bob ____________________________________________________________________________ Bob Briscoe, Networks Research Centre, BT Research B54/77 Adastral Park,Martlesham Heath,Ipswich,IP5 3RE,UK. +44 1473 645196 _______________________________________________ p2pi mailing list p2pi@ietf.org https://www.ietf.org/mailman/listinfo/p2pi From p2pi-bounces@ietf.org Sat Aug 2 08:51: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 AA2E53A6846; Sat, 2 Aug 2008 08:51: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 6CD193A68C6 for ; Sat, 2 Aug 2008 08:51:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.851 X-Spam-Level: X-Spam-Status: No, score=-0.851 tagged_above=-999 required=5 tests=[AWL=0.666, BAYES_00=-2.599, DNS_FROM_RFC_BOGUSMX=1.482, J_CHICKENPOX_57=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 25TuIXRC7AFU for ; Sat, 2 Aug 2008 08:51:09 -0700 (PDT) Received: from smtp3.smtp.bt.com (smtp3.smtp.bt.com [217.32.164.138]) by core3.amsl.com (Postfix) with ESMTP id 96E423A6830 for ; Sat, 2 Aug 2008 08:51:08 -0700 (PDT) Received: from i2kc06-ukbr.domain1.systemhost.net ([193.113.197.70]) by smtp3.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 2 Aug 2008 16:51:30 +0100 Received: from cbibipnt05.iuser.iroot.adidom.com ([147.149.196.177]) by i2kc06-ukbr.domain1.systemhost.net with Microsoft SMTPSVC(6.0.3790.1830); Sat, 2 Aug 2008 16:51:30 +0100 Received: From bagheera.jungle.bt.co.uk ([132.146.168.158]) by cbibipnt05.iuser.iroot.adidom.com (WebShield SMTP v4.5 MR1a P0803.399); id 1217692289913; Sat, 2 Aug 2008 16:51:29 +0100 Received: from mut.jungle.bt.co.uk ([10.73.65.33]) by bagheera.jungle.bt.co.uk (8.13.5/8.12.8) with ESMTP id m72FpOAN003831; Sat, 2 Aug 2008 16:51:27 +0100 Message-Id: <200808021551.m72FpOAN003831@bagheera.jungle.bt.co.uk> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Sat, 02 Aug 2008 16:51:25 +0100 To: "Woundy, Richard" From: Bob Briscoe In-Reply-To: <74CCBBDF76102846AFA7B29F3A98D3F601940660@PACDCEXCMB06.cabl e.comcast.com> References: <1232737442.90411217507981759.JavaMail.root@dkny.pando.com> <1959788251.90461217508317275.JavaMail.root@dkny.pando.com> <200807311754.m6VHsBVg000355@bagheera.jungle.bt.co.uk> <74CCBBDF76102846AFA7B29F3A98D3F601940660@PACDCEXCMB06.cable.comcast.com> Mime-Version: 1.0 X-Scanned-By: MIMEDefang 2.56 on 132.146.168.158 X-OriginalArrivalTime: 02 Aug 2008 15:51:30.0143 (UTC) FILETIME=[A13DBEF0:01C8F4B7] Cc: p2pi@ietf.org Subject: Re: [p2pi] why I didn't hum yes (yet) X-BeenThere: p2pi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: P2P Infrastructure Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: p2pi-bounces@ietf.org Errors-To: p2pi-bounces@ietf.org Rich, Thanks - this data is getting more useful. More inline... At 09:25 01/08/2008, Woundy, Richard wrote: >Bob, > >I feel compelled to respond to some of your points. > >At Comcast, we studied the P4P results from Verizon earlier this >year, before we committed to a trial this summer. There were three >items of interest from those results: > >1. > Faster downloads for P2P users >2. > Reduced backbone transit traffic for the ISP >3. > * The same aggregate amount of uploading by ISP customers Do you mean uploading by p2p apps that P4P has helped shift, or uploading by all apps including other p2p systems? If you mean not just P4P apps but all apps, getting no increase in uploading could be an effect of the performance probing of non-P4P apps finding that Comcast's upstream is getting congested so they naturally choose peers in other networks to download from instead of yours (as you say below). In that case, P4P can indeed be judged as 'better'. Essentially it would be initiating a shuffle around of /all/ the transit flows so more were local, not just it's own. I hope I've made clear I'm not saying I believe P4P is wrong, I'm just asking for rigor in the claims of 'better'. >We're not ready to reveal the results of our own recently-concluded >P4P trial, but suffice it to say that we are seeing similar results. >I suspect the reason behind point #3 is that P2P uploads within the >ISP displace the P2P uploads outside the ISP. And the reason behind >point #2 may be that there are fewer outside factors (e.g. multiple >transit backbones) that could cause congestion. > >We need to perform more analysis before we can conclude that ISP >localization doesn't increase upstream traffic, but at least on >average it does not increase upstream traffic. If it turns out that >P4P localization is cost-neutral on an access basis, then that would >be a critical item to retain for ALTO. Certainly. And I'm glad you're not jumping to conclusions. >BTW, I agree with many of your other comments. For example, I agree >that minimizing RTT for P2P connections isn't all that critical. For >example, I've heard that clever P2P users are often motivated (where >possible) to select peers in Japan and Korea, because higher upload >throughput trumps RTT every time. Just to be clear, I was saying RTT /will/ become much less critical over the next year or so as these new congestion controls become widespread. That drastically cuts the incentive for p2p users to voluntarily ask an oracle (losing your point 1: 'faster downloads for p2p users'). > >It costs more (bit for bit) to upgrade access and backhaul than it > does to upgrade interconnect (there's a considerable economy of > scale). If someone from a cablecco has told you it's most important > to reduce transit costs, you'll find they did NOT mean "and at the > same time please introduce higher backhaul and access costs instead". > >I've been talking to Laird, and I seem to be from a 'cableco', so >maybe you're referring to me. (And maybe I'm one of the amateurs as well.) :^/ :) > >But I am pretty sure I have been consistent on this point, from the >P2PI Workshop to the ALTO BOF to other private conversations -- our >broadband access costs are much higher than our backbone / transit >costs. As my boss would say, "backhoe costs don't follow Moore's >Law". For Comcast, minimizing transit costs is nice but not the >fundamental concern. Everyone on the list, please take this to heart. > >BTW, I have heard that for other ISPs, transit costs *are* a >fundamental issue. And not just in the so-called "third world". Certainly, Telecom New Zealand say this and our friends in Oz. Bob > >-- Rich > > >Laird, > >At 13:45 31/07/2008, Laird Popkin wrote: > >Addressing remark 1: localizing network traffic (based on the p4p > >field tests, which used ISP network maps and an "oracle") shows a > >strong benefit in transit reduction and in performance improvement, > >for networks that are DSL, Cable or FTTH. > >I think my rather important previous point got missed (sorry my mail >had a lot of points)... > >Neither of these metrics for 'better' impresses me much at all. > >* If performance of p2p is better, and if there is shared congestion >with other non-p2p users on the same local network, this means the >performance of others will most likely be worse. Overall, is this >better or worse? > >* If there's transit reduction, equivalent traffic will instead be >being uploaded from the local network. Again, if the local network >already has shared congestion upstream (a cable network does), that's >making it _worse_ both for local p2p & non-p2p users. > > >It costs more (bit for bit) to upgrade access and backhaul than it >does to upgrade interconnect (there's a considerable economy of >scale). If someone from a cablecco has told you it's most important >to reduce transit costs, you'll find they did NOT mean "and at the >same time please introduce higher backhaul and access costs instead". > >See the picture I posted yesterday to this list: > > >The Internetwork is provided to be used. Let's not assume a >DISINTERNET is 'better' without being clear what 'better' means. > >I've seen no research that uses a full cost-benefit analysis. That's >hard (e.g. what's the relative value of p2p bits versus non-p2p >bits). But without such a study, unfortunately, what everyone is >calling 'better' looks like 'worse' to me on second looks - at least >for networks with a congested upstream. > >On third looks (ie a full study) it might not be worse. But can >people please enter this debate on the assumption that network >economics is dangerous in the hands of amateurs (which includes the >large majority of folks even in telcos/cablecos). > > >Bob > > > >____________________________________________________________________________ >Bob Briscoe, Networks Research Centre, BT Research >B54/77 Adastral Park,Martlesham Heath,Ipswich,IP5 3RE,UK. +44 1473 645196 > > >_______________________________________________ >p2pi mailing list >p2pi@ietf.org >https://www.ietf.org/mailman/listinfo/p2pi ____________________________________________________________________________ Bob Briscoe, Networks Research Centre, BT Research B54/77 Adastral Park,Martlesham Heath,Ipswich,IP5 3RE,UK. +44 1473 645196 _______________________________________________ p2pi mailing list p2pi@ietf.org https://www.ietf.org/mailman/listinfo/p2pi From p2pi-bounces@ietf.org Sat Aug 2 09:05: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 3DB7A3A6907; Sat, 2 Aug 2008 09:05: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 422CD3A68C9 for ; Sat, 2 Aug 2008 09:05:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.88 X-Spam-Level: X-Spam-Status: No, score=-0.88 tagged_above=-999 required=5 tests=[AWL=0.637, BAYES_00=-2.599, DNS_FROM_RFC_BOGUSMX=1.482, J_CHICKENPOX_57=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 91vc5ktvgjmK for ; Sat, 2 Aug 2008 09:05:46 -0700 (PDT) Received: from smtp3.smtp.bt.com (smtp3.smtp.bt.com [217.32.164.138]) by core3.amsl.com (Postfix) with ESMTP id 5AFF43A6765 for ; Sat, 2 Aug 2008 09:05:45 -0700 (PDT) Received: from i2kc06-ukbr.domain1.systemhost.net ([193.113.197.70]) by smtp3.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 2 Aug 2008 17:05:14 +0100 Received: from cbibipnt05.iuser.iroot.adidom.com ([147.149.196.177]) by i2kc06-ukbr.domain1.systemhost.net with Microsoft SMTPSVC(6.0.3790.1830); Sat, 2 Aug 2008 17:05:14 +0100 Received: From bagheera.jungle.bt.co.uk ([132.146.168.158]) by cbibipnt05.iuser.iroot.adidom.com (WebShield SMTP v4.5 MR1a P0803.399); id 1217693114448; Sat, 2 Aug 2008 17:05:14 +0100 Received: from mut.jungle.bt.co.uk ([10.73.65.33]) by bagheera.jungle.bt.co.uk (8.13.5/8.12.8) with ESMTP id m72G5A7p003948; Sat, 2 Aug 2008 17:05:12 +0100 Message-Id: <200808021605.m72G5A7p003948@bagheera.jungle.bt.co.uk> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Sat, 02 Aug 2008 17:05:10 +0100 To: Laird Popkin From: Bob Briscoe In-Reply-To: <826442146.93941217579515505.JavaMail.root@dkny.pando.com> References: <826442146.93941217579515505.JavaMail.root@dkny.pando.com> Mime-Version: 1.0 X-Scanned-By: MIMEDefang 2.56 on 132.146.168.158 X-OriginalArrivalTime: 02 Aug 2008 16:05:14.0638 (UTC) FILETIME=[8CADB2E0:01C8F4B9] Cc: p2pi@ietf.org Subject: Re: [p2pi] why I didn't hum yes (yet) X-BeenThere: p2pi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: P2P Infrastructure Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: p2pi-bounces@ietf.org Errors-To: p2pi-bounces@ietf.org Laird, This sounds good. Bob At 09:31 01/08/2008, Laird Popkin wrote: >To add a little field test data, so far we've not seen any cases >where traffic localization increased "last mile" uplink consumption. >When traffic isn't localized, an ISP's customers are uploading to >the general internet. When traffic is localized, an ISP's customers >upload about the same volume, but the destination of the upload >shifts from external to internal destinations. This happens in part >because the ISP's customers connect to each other, and in part >because the external users connect to each other instead of >connecting into the ISP. The result is that the consumption of the >"last mile" doesn't change, but the consumption of internal and >external links drops. > >You're right that a cost analysis is complex, since it varies >dramatically between ISPs (and is subject to debate within ISPs). >That's why I'd rather talk about resource consumption (e.g. data >volumes, link utilization). > >- Laird Popkin, CTO, Pando Networks > mobile: 646/465-0570 > >----- Original Message ----- >From: "Philip Levis" >To: "Bob Briscoe" >Cc: "Laird Popkin" , p2pi@ietf.org >Sent: 01 August 2008 02:14:25 o'clock (GMT) Europe/London >Subject: Re: [p2pi] why I didn't hum yes (yet) > > >On Jul 31, 2008, at 6:54 PM, Bob Briscoe wrote: > > > Laird, > > > > At 13:45 31/07/2008, Laird Popkin wrote: > >> Addressing remark 1: localizing network traffic (based on the p4p > >> field tests, which used ISP network maps and an "oracle") shows a > >> strong benefit in transit reduction and in performance improvement, > >> for networks that are DSL, Cable or FTTH. > > > > I think my rather important previous point got missed (sorry my mail > > had a lot of points)... > > > > Neither of these metrics for 'better' impresses me much at all. > > > > * If performance of p2p is better, and if there is shared congestion > > with other non-p2p users on the same local network, this means the > > performance of others will most likely be worse. Overall, is this > > better or worse? > > > > * If there's transit reduction, equivalent traffic will instead be > > being uploaded from the local network. Again, if the local network > > already has shared congestion upstream (a cable network does), > > that's making it _worse_ both for local p2p & non-p2p users. > > > > > > It costs more (bit for bit) to upgrade access and backhaul than it > > does to upgrade interconnect (there's a considerable economy of > > scale). If someone from a cablecco has told you it's most important > > to reduce transit costs, you'll find they did NOT mean "and at the > > same time please introduce higher backhaul and access costs instead". > > > > See the picture I posted yesterday to this list: > > > > > > > The Internetwork is provided to be used. Let's not assume a > > DISINTERNET is 'better' without being clear what 'better' means. > > > > I've seen no research that uses a full cost-benefit analysis. That's > > hard (e.g. what's the relative value of p2p bits versus non-p2p > > bits). But without such a study, unfortunately, what everyone is > > calling 'better' looks like 'worse' to me on second looks - at least > > for networks with a congested upstream. > > > > On third looks (ie a full study) it might not be worse. But can > > people please enter this debate on the assumption that network > > economics is dangerous in the hands of amateurs (which includes the > > large majority of folks even in telcos/cablecos). > > >Bob, I think you're getting lost in the weeds here. > >The goal is to define a mechanism by which entities with a greater >knowledge of the network can provide guidance to clients on whom those >clients might want to communicate with. > >This guidance could be based on localization, or it could be based on >other properties which turn out to be better but we have not >discovered yet. The interface proposed, (X,Y,Z) -> (Z), does not >assume localization. Doing so would be folly, as it would preclude >using the mechanism for applications which are better served by other >selection policies. > >That being said, the points in your slides are interesting. Do you >have any real and repeatable experimental evidence that it's "worse?" >I'll admit that none of the experimental studies cover every single >edge case -- they would then be so voluminous as to be unreadable -- >but I'm tempted to trust experimental data collected from real >networks over back-of-the-envelope calculations. > >Phil ____________________________________________________________________________ Bob Briscoe, Networks Research Centre, BT Research B54/77 Adastral Park,Martlesham Heath,Ipswich,IP5 3RE,UK. +44 1473 645196 _______________________________________________ p2pi mailing list p2pi@ietf.org https://www.ietf.org/mailman/listinfo/p2pi From p2pi-bounces@ietf.org Sat Aug 2 11:11: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 AC9C53A6A2D; Sat, 2 Aug 2008 11:11: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 C900E3A69FA for ; Sat, 2 Aug 2008 11:11:34 -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 nOBagSLT2zYy for ; Sat, 2 Aug 2008 11:11:34 -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 F2A543A6A0F for ; Sat, 2 Aug 2008 11:11:33 -0700 (PDT) Received: by wf-out-1314.google.com with SMTP id 27so1403627wfd.31 for ; Sat, 02 Aug 2008 11:11:57 -0700 (PDT) Received: by 10.143.28.7 with SMTP id f7mr4263894wfj.40.1217700717305; Sat, 02 Aug 2008 11:11:57 -0700 (PDT) Received: from ?192.168.1.103? ( [67.188.243.194]) by mx.google.com with ESMTPS id 29sm1299564wfg.0.2008.08.02.11.11.56 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sat, 02 Aug 2008 11:11:56 -0700 (PDT) Message-Id: From: Stanislav Shalunov To: Toerless Eckert In-Reply-To: <20080731143742.GM10916@cisco.com> Mime-Version: 1.0 (Apple Message framework v926) Date: Sat, 2 Aug 2008 11:11:55 -0700 References: <20080731143742.GM10916@cisco.com> X-Mailer: Apple Mail (2.926) Cc: tsv-area@ietf.org, p2pi@ietf.org Subject: Re: [p2pi] DSCP or not X-BeenThere: p2pi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: P2P Infrastructure Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: p2pi-bounces@ietf.org Errors-To: p2pi-bounces@ietf.org This is a TANA discussion and should for now be on tsv-area. The real challenge in deploying scavenger is not even the core, which is infrequently congested, but the very edge, which gets congested on every upload. Many more devices (cable and DSL modems), most of them hard to manage en masse. A practical solution, therefore, must be end-to-end. Whether to add a DSCP marking to the traffic is an orthogonal question, and the answer is likely positive, if we can find a suitable codepoint. I expect we can, with 001000 being the most obvious candidate. This will be particularly useful if networks would exclude scavenger- marked traffic from quotas, etc. Since we can't rely on a network that does not support scavenger to do anything with scavenger traffic (including resetting the DSCP), having a negotiation that switches between algorithms is challenging. Consider that most head ends of congested bottlenecks are not even IP devices. -- Stas On Jul 31, 2008, at 7:37 AM, Toerless Eckert wrote: > > Seems to me as if the best long term solution would be to utilize a > scavenger > DSCP class in the network. For such a class i think the existing > flow control mechanisms as eg: in TCP may not be suited best to > exhaust > the available bandwidth - as it likely fluctuates more frequently and > short term than in best effort. SSo some form of agressive > transmission with > effecient retransmission (and maybe FEC) is probably best when using > such a scavenger clas. > > Practically speaking, it will be a long time for most core networks > to support such a clss, specifically because of the limited number of > exp bits in MPLS, inertia, technical problems, and so on. So now > we need the algorithm to handle scavenger traffic in the best effort > class, > that very carefully tries not to cause any congestion and in face of > congestion throttles itself back to zero or close to it. > > If we could bring together those two algorithms together, and the > algorithm for a connection would be selected based on whether or not > the ntework > resets the scavenger DSCP class to best effort (because there is no > scavenger class > configured) ... then i think this would be a good short and long > term solution. > > Cheers > Toerless > _______________________________________________ > p2pi mailing list > p2pi@ietf.org > https://www.ietf.org/mailman/listinfo/p2pi -- Stanislav Shalunov _______________________________________________ p2pi mailing list p2pi@ietf.org https://www.ietf.org/mailman/listinfo/p2pi From p2pi-bounces@ietf.org Sat Aug 2 13:31:54 2008 Return-Path: X-Original-To: p2pi-archive@ietf.org Delivered-To: ietfarch-p2pi-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4E2BE3A695B; Sat, 2 Aug 2008 13:31:54 -0700 (PDT) X-Original-To: p2pi@core3.amsl.com Delivered-To: p2pi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 89F653A6924 for ; Sat, 2 Aug 2008 13:31:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.133 X-Spam-Level: X-Spam-Status: No, score=-2.133 tagged_above=-999 required=5 tests=[AWL=0.465, 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 0vkXOWDg2ti9 for ; Sat, 2 Aug 2008 13:31:51 -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 454293A68B7 for ; Sat, 2 Aug 2008 13:31:50 -0700 (PDT) Received: by wf-out-1314.google.com with SMTP id 27so1432314wfd.31 for ; Sat, 02 Aug 2008 13:32:14 -0700 (PDT) Received: by 10.142.177.7 with SMTP id z7mr4300587wfe.15.1217709133151; Sat, 02 Aug 2008 13:32:13 -0700 (PDT) Received: from ?192.168.1.103? ( [67.188.243.194]) by mx.google.com with ESMTPS id 24sm3424889wfc.6.2008.08.02.13.32.12 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sat, 02 Aug 2008 13:32:12 -0700 (PDT) Message-Id: <2BC23947-E7E7-4E59-98B2-05E79AE8BA78@shlang.com> From: Stanislav Shalunov To: p2pi@ietf.org Mime-Version: 1.0 (Apple Message framework v926) Date: Sat, 2 Aug 2008 13:32:11 -0700 X-Mailer: Apple Mail (2.926) Subject: [p2pi] ALTO service privacy, performance, and architecture X-BeenThere: p2pi@ietf.org X-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="===============2084259677==" Sender: p2pi-bounces@ietf.org Errors-To: p2pi-bounces@ietf.org --===============2084259677== Content-Type: multipart/alternative; boundary=Apple-Mail-37-1031246308 --Apple-Mail-37-1031246308 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Much time has been spent discussing the operation of a sorting oracle or oracles answering questions like "What is the load on this link?", "Where did I put my glasses?", "How can I make $100M dollars this year?", "What is the link capacity between 1.2.3.4 and 1.2.3.5?", "If I were to send a packet to 1.2.3.4 after my next scheduling slice in the OS ends and I start to feel pretty, what would be the delay?". A sorting oracle is a useful concept to consider when thinking about the system as a whole. The oracle that answers questions it can't possibly answer is not a useful concept. A literal sorting oracle operated by the ISP will, however, *not* be queried by P2P apps and is, therefore, not relevant. Passing just a few IP numbers to such an oracle is not enough because it won't solve the localization problem: chances are none of the few are nearby. Passing the entire swarm or nearly the entire swarm to the oracle is not something that we would do in BitTorrent. I expect other P2P apps with users will also not consider this privacy horror seriously. The sorting needs to happen inside the client. P2P apps already can easily have a lot of information about the network topology. For example, it is entirely practical to download the entire Internet routing table to every client and keep it current. The routing table, is of course, publicly available at a looking glass near you. What P2P apps don't know about the topology is what the ISP would actually prefer. The sort of things that it would be useful to know are: * Does the ISP prefer local traffic? * Which IP ranges are local? * Are there any IP ranges best avoided? (Mobile or DSL when fiber is available, for example.) Here is an example of a solution that would answer this sort of questions. 1. The client discovers an URL using a mechanism similar to BEP 22. Say the URL is http://nms.example.net/ip-routing-policy 2. The client checks how long ago it has downloaded this URL. If more than a month ago, downloads again. The URL is a file containing things like: IP4:1.2.3/24 prefer IP4:1.2.4/24 avoid ASN:16 prefer ASN:18 prefer Such a solution would be very useful for P2P apps. ISPs will be able to decide how much information they want to reveal about their own network topology and business arrangements. The amount of information revealed is the same as through a literal sorting oracle if I'm allowed to ask an unlimited number of sorting questions. Every concerned party will thus have an incentive to use this solution. Solution is also easy to deploy: for discovery, the ISP will need to add one line to a forward DNS zone file; for the actual service, it'll need to use a simple script in daily cron to post-process "show ip bgp" output or equivalent. The discovery mechanism would be easy to generalize and use for other kinds of discovery. The ALTO information service would be useful for anything that can choose traffic sources/destinations: P2P, CDN, mirror selection, etc. -- Stanislav Shalunov --Apple-Mail-37-1031246308 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: quoted-printable
Much time has been spent = discussing the operation of a sorting oracle or oracles answering = questions like "What is the load on this link?", "Where did I put my = glasses?", "How can I make $100M dollars this year?", "What is the link = capacity between 1.2.3.4 and 1.2.3.5?", "If I were to send a packet to = 1.2.3.4 after my next scheduling slice in the OS ends and I start to = feel pretty, what would be the delay?".  A sorting oracle is a = useful concept to consider when thinking about the system as a whole. =  The oracle that answers questions it can't possibly answer is not = a useful concept. 

A literal sorting = oracle operated by the ISP will, however, *not* be queried by P2P apps = and is, therefore, not relevant.

Passing just a = few IP numbers to such an oracle is not enough because it won't solve = the localization problem: chances are none of the few are = nearby.

Passing the entire swarm or nearly the = entire swarm to the oracle is not something that we would do in = BitTorrent.  I expect other P2P apps with users will also not = consider this privacy horror seriously.

The = sorting needs to happen inside the client.

P2P = apps already can easily have a lot of information about the network = topology.  For example, it is entirely practical to download the = entire Internet routing table to every client and keep it current. =  The routing table, is of course, publicly available at a looking = glass near you.  What P2P apps don't know about the topology is = what the ISP would actually prefer.

The sort of = things that it would be useful to know are:

* = Does the ISP prefer local traffic?

* Which IP = ranges are local?

* Are there any IP ranges = best avoided?  (Mobile or DSL when fiber is available, for = example.)

Here is an example of a solution that = would answer this sort of questions.

1. The = client discovers an URL using a mechanism similar to BEP 22.  Say = the URL is http://nms.example.net/i= p-routing-policy

2. The client checks how = long ago it has downloaded this URL.  If more than a month ago, = downloads again.  The URL is a file containing things = like:

IP4:1.2.3/24 = prefer
IP4:1.2.4/24 avoid
ASN:16 = prefer
ASN:18 prefer

Such a solution = would be very useful for P2P apps.  ISPs will be able to decide how = much information they want to reveal about their own network topology = and business arrangements.  The amount of information revealed is = the same as through a literal sorting oracle if I'm allowed to ask an = unlimited number of sorting questions.  Every concerned party will = thus have an incentive to use this solution.  Solution is also easy = to deploy: for discovery, the ISP will need to add one line to a forward = DNS zone file; for the actual service, it'll need to use a simple script = in daily cron to post-process "show ip bgp" output or = equivalent.

The discovery mechanism would be = easy to generalize and use for other kinds of = discovery.

The ALTO information service would = be useful for anything that can choose traffic sources/destinations: = P2P, CDN, mirror selection, etc.


= --Apple-Mail-37-1031246308-- --===============2084259677== 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 --===============2084259677==-- From p2pi-bounces@ietf.org Sat Aug 2 13:56: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 2E2333A6957; Sat, 2 Aug 2008 13:56: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 7CBBA3A67EB for ; Sat, 2 Aug 2008 13:56:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.174 X-Spam-Level: X-Spam-Status: No, score=-10.174 tagged_above=-999 required=5 tests=[AWL=0.090, 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 SVyYnifa+j+v for ; Sat, 2 Aug 2008 13:56:51 -0700 (PDT) Received: from dkny.pando.com (dkny.pando.com [67.99.55.163]) by core3.amsl.com (Postfix) with ESMTP id B16ED3A6965 for ; Sat, 2 Aug 2008 13:56:50 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by dkny.pando.com (Postfix) with ESMTP id 21E13E10B6C; Sat, 2 Aug 2008 16:57:14 -0400 (EDT) X-Virus-Scanned: amavisd-new at Received: from dkny.pando.com ([127.0.0.1]) by localhost (dkny.pando.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g6cZttoP7yVi; Sat, 2 Aug 2008 16:57:00 -0400 (EDT) Received: from dkny.pando.com (dkny.pando.com [10.10.60.11]) by dkny.pando.com (Postfix) with ESMTP id C12C0E10B1E; Sat, 2 Aug 2008 16:57:00 -0400 (EDT) Date: Sat, 2 Aug 2008 16:57:00 -0400 (EDT) From: Laird Popkin To: Stanislav Shalunov Message-ID: <1035869004.97841217710620745.JavaMail.root@dkny.pando.com> In-Reply-To: <1109433876.97821217710490451.JavaMail.root@dkny.pando.com> MIME-Version: 1.0 X-Originating-IP: [71.187.207.81] Cc: p2pi@ietf.org Subject: Re: [p2pi] ALTO service privacy, performance, and architecture X-BeenThere: p2pi@ietf.org X-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="===============0738254833==" Sender: p2pi-bounces@ietf.org Errors-To: p2pi-bounces@ietf.org --===============0738254833== Content-Type: multipart/alternative; boundary="----=_Part_4410_1940680520.1217710620744" ------=_Part_4410_1940680520.1217710620744 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Ignoring the sarcasm, I agree with much of what you've written, with the ca= veat that the answers that the oracle provides need to be relative to some = point. For example, the answer to the question "which IP ranges are local" = is by definition different for each locality that the ISP cares about. Also= , for many p2p architectures this service needs to be accessible by a third= party (e.g. a Tracker) asking on behalf of a client, and should be applica= ble to any p2p network (or other application) so the mechanism described wo= uld need to be generalized somewhat.=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: "Stanislav Shalunov" =20 To: p2pi@ietf.org=20 Sent: Saturday, August 2, 2008 4:32:11 PM (GMT-0500) America/New_York=20 Subject: [p2pi] ALTO service privacy, performance, and architecture=20 Much time has been spent discussing the operation of a sorting oracle or or= acles answering questions like "What is the load on this link?", "Where did= I put my glasses?", "How can I make $100M dollars this year?", "What is th= e link capacity between 1.2.3.4 and 1.2.3.5?", "If I were to send a packet = to 1.2.3.4 after my next scheduling slice in the OS ends and I start to fee= l pretty, what would be the delay?". =C2=A0A=C2=A0sorting oracle is a usefu= l concept to consider when thinking about the system as a whole. =C2=A0The = oracle that answers questions it can't possibly answer is not a useful conc= ept.=C2=A0=20 A literal sorting oracle operated by the ISP will, however, *not* be querie= d by P2P apps and is, therefore, not relevant.=20 Passing just a few IP numbers to such an oracle is not enough because it wo= n't solve the localization problem: chances are none of the few are nearby.= =20 Passing the entire swarm or nearly the entire swarm to the oracle is not so= mething that we would do in BitTorrent. =C2=A0I expect other P2P apps with = users will also not consider this privacy horror seriously.=20 The sorting needs to happen inside the client.=20 P2P apps already can easily have a lot of information about the network top= ology. =C2=A0For example, it is entirely practical to download the entire I= nternet routing table to every client and keep it current. =C2=A0The routin= g table, is of course, publicly available at a looking glass near you. =C2= =A0What P2P apps don't know about the topology is what the ISP would actual= ly prefer.=20 The sort of things that it would be useful to know are:=20 * Does the ISP prefer local traffic?=20 * Which IP ranges are local?=20 * Are there any IP ranges best avoided? =C2=A0(Mobile or DSL when fiber is = available, for example.)=20 Here is an example of a solution that would answer this sort of questions.= =20 1. The client discovers an URL using a mechanism similar to BEP 22. =C2=A0S= ay the URL is http://nms.example.net/ip-routing-policy=20 2. The client checks how long ago it has downloaded this URL. =C2=A0If more= than a month ago, downloads again. =C2=A0The URL is a file containing thin= gs like:=20 IP4:1.2.3/24 prefer=20 IP4:1.2.4/24 avoid=20 ASN:16 prefer=20 ASN:18 prefer=20 Such a solution would be very useful for P2P apps. =C2=A0ISPs will be able = to decide how much information they want to reveal about their own network = topology and business arrangements. =C2=A0The amount of information reveale= d is the same as through a literal sorting oracle if I'm allowed to ask an = unlimited number of sorting questions. =C2=A0Every concerned party will thu= s have an incentive to use this solution. =C2=A0Solution is also easy to de= ploy: for discovery, the ISP will need to add one line to a forward DNS zon= e file; for the actual service, it'll need to use a simple script in daily = cron to post-process "show ip bgp" output or equivalent.=20 The discovery mechanism would be easy to generalize and use for other kinds= of discovery.=20 The ALTO information service would be useful for anything that can choose t= raffic sources/destinations: P2P, CDN, mirror selection, etc.=20 --=20 Stanislav Shalunov=20 Hacking Startups _______________________________________________ p2pi mailing list p2pi@ietf= .org https://www.ietf.org/mailman/listinfo/p2pi ------=_Part_4410_1940680520.1217710620744 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable Ignoring the sarcasm, I agree with much of what= you've written, with the caveat that the answers that the oracle provides = need to be relative to some point. For example, the answer to the question = "which IP ranges are local" is by definition different for each locality th= at the ISP cares about. Also, for many p2p architectures this service needs= to be accessible by a third party (e.g. a Tracker) asking on behalf of a c= lient, and should be applicable to any p2p network (or other application) s= o the mechanism described would need to be generalized somewhat.

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

----- Original Message -----
From: "Sta= nislav Shalunov" <shalunov@shlang.com>
To: p2pi@ietf.org
Sent: Sat= urday, August 2, 2008 4:32:11 PM (GMT-0500) America/New_York
Subject: [p= 2pi] ALTO service privacy, performance, and architecture

Much t= ime has been spent discussing the operation of a sorting oracle or oracles = answering questions like "What is the load on this link?", "Where did I put= my glasses?", "How can I make $100M dollars this year?", "What is the link= capacity between 1.2.3.4 and 1.2.3.5?", "If I were to send a packet to 1.2= .3.4 after my next scheduling slice in the OS ends and I start to feel pret= ty, what would be the delay?". =C2=A0A=C2=A0sorting oracle is a useful conc= ept to consider when thinking about the system as a whole. =C2=A0The oracle= that answers questions it can't possibly answer is not a useful concept.= =C2=A0

A literal sorting oracle operated by the IS= P will, however, *not* be queried by P2P apps and is, therefore, not releva= nt.

Passing just a few IP numbers to such an oracl= e is not enough because it won't solve the localization problem: chances ar= e none of the few are nearby.

Passing the entire s= warm or nearly the entire swarm to the oracle is not something that we woul= d do in BitTorrent. =C2=A0I expect other P2P apps with users will also not = consider this privacy horror seriously.

The sortin= g needs to happen inside the client.

P2P apps alre= ady can easily have a lot of information about the network topology. =C2=A0= For example, it is entirely practical to download the entire Internet routi= ng table to every client and keep it current. =C2=A0The routing table, is o= f course, publicly available at a looking glass near you. =C2=A0What P2P ap= ps don't know about the topology is what the ISP would actually prefer.

The sort of things that it would be useful to know ar= e:

* Does the ISP prefer local traffic?
=
* Which IP ranges are local?

* Are = there any IP ranges best avoided? =C2=A0(Mobile or DSL when fiber is availa= ble, for example.)

Here is an example of a solutio= n that would answer this sort of questions.

1. The= client discovers an URL using a mechanism similar to BEP 22. =C2=A0Say the= URL is http://nms.example.net/ip-routing-policy

2= . The client checks how long ago it has downloaded this URL. =C2=A0If more = than a month ago, downloads again. =C2=A0The URL is a file containing thing= s like:

IP4:1.2.3/24 prefer
IP4:1.2.4/24= avoid
ASN:16 prefer
ASN:18 prefer

=
Such a solution would be very useful for P2P apps. =C2=A0ISPs will be = able to decide how much information they want to reveal about their own net= work topology and business arrangements. =C2=A0The amount of information re= vealed is the same as through a literal sorting oracle if I'm allowed to as= k an unlimited number of sorting questions. =C2=A0Every concerned party wil= l thus have an incentive to use this solution. =C2=A0Solution is also easy = to deploy: for discovery, the ISP will need to add one line to a forward DN= S zone file; for the actual service, it'll need to use a simple script in d= aily cron to post-process "show ip bgp" output or equivalent.
The discovery mechanism would be easy to generalize and use for= other kinds of discovery.

The ALTO information se= rvice would be useful for anything that can choose traffic sources/destinat= ions: P2P, CDN, mirror selection, etc.



_______________________________________________ p2pi mailing list p2pi@ietf.org https://www.ietf.org/mailman/listinfo/p2pi ------=_Part_4410_1940680520.1217710620744-- --===============0738254833== 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 --===============0738254833==-- From p2pi-bounces@ietf.org Sat Aug 2 14:17: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 1ADE33A6B4F; Sat, 2 Aug 2008 14:17: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 9CD3B3A6B4F for ; Sat, 2 Aug 2008 14:17:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MKy13S9cIhk3 for ; Sat, 2 Aug 2008 14:17:56 -0700 (PDT) Received: from netra.cs.yale.edu (netra.cs.yale.edu [128.36.229.21]) by core3.amsl.com (Postfix) with ESMTP id 3C00D3A68ED for ; Sat, 2 Aug 2008 14:17:56 -0700 (PDT) Received: from [127.0.0.1] (dhcp130132249203.its.yale.edu [130.132.249.203]) by netra.cs.yale.edu (Postfix) with ESMTP id E06A6409512; Sat, 2 Aug 2008 17:18:19 -0400 (EDT) Message-ID: <4894CF1C.2030904@cs.yale.edu> Date: Sat, 02 Aug 2008 17:18:20 -0400 From: "Y. Richard Yang" Organization: Yale University User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) MIME-Version: 1.0 To: Stanislav Shalunov References: <2BC23947-E7E7-4E59-98B2-05E79AE8BA78@shlang.com> In-Reply-To: <2BC23947-E7E7-4E59-98B2-05E79AE8BA78@shlang.com> Cc: p2pi@ietf.org Subject: Re: [p2pi] ALTO service privacy, performance, and architecture X-BeenThere: p2pi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: P2P Infrastructure Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: p2pi-bounces@ietf.org Errors-To: p2pi-bounces@ietf.org Hi Stansilav, In short, I like your points. The P4P team, including those here at Yale and Laird, had thought about the type of interface for a while. There were many discussions on the type of interface, in particular, a sorting interface or the P4P interface or some other type of interface (e.g., your proposal). We argue that the sorting interface, although simple and can be considered as a special case of the p4p distance (vcost) interface, we feel that it is limited and can have many issues. The virtual cost interface used in the current P4P field test actually is quite similar to your proposal, with three differences: - Like Laird said in the previous email, we allowing the addition of sources, instead of only destinations, for specifying ISP preference. - Instead of a binary value (avoid/prefer), we allow a range of numerical values. - we query the ISP servers, instead of URL/HTML web pages. Directly using a URL is quite interesting. We will need be able to update the web page, access control, etc. Richard Stanislav Shalunov wrote: > Much time has been spent discussing the operation of a sorting oracle > or oracles answering questions like "What is the load on this link?", > "Where did I put my glasses?", "How can I make $100M dollars this > year?", "What is the link capacity between 1.2.3.4 and 1.2.3.5?", "If > I were to send a packet to 1.2.3.4 after my next scheduling slice in > the OS ends and I start to feel pretty, what would be the delay?". > A sorting oracle is a useful concept to consider when thinking about > the system as a whole. The oracle that answers questions it can't > possibly answer is not a useful concept. > > A literal sorting oracle operated by the ISP will, however, *not* be > queried by P2P apps and is, therefore, not relevant. > > Passing just a few IP numbers to such an oracle is not enough because > it won't solve the localization problem: chances are none of the few > are nearby. > > Passing the entire swarm or nearly the entire swarm to the oracle is > not something that we would do in BitTorrent. I expect other P2P apps > with users will also not consider this privacy horror seriously. > > The sorting needs to happen inside the client. > > P2P apps already can easily have a lot of information about the > network topology. For example, it is entirely practical to download > the entire Internet routing table to every client and keep it current. > The routing table, is of course, publicly available at a looking > glass near you. What P2P apps don't know about the topology is what > the ISP would actually prefer. > > The sort of things that it would be useful to know are: > > * Does the ISP prefer local traffic? > > * Which IP ranges are local? > > * Are there any IP ranges best avoided? (Mobile or DSL when fiber is > available, for example.) > > Here is an example of a solution that would answer this sort of questions. > > 1. The client discovers an URL using a mechanism similar to BEP 22. > Say the URL is http://nms.example.net/ip-routing-policy > > 2. The client checks how long ago it has downloaded this URL. If more > than a month ago, downloads again. The URL is a file containing > things like: > > IP4:1.2.3/24 prefer > IP4:1.2.4/24 avoid > ASN:16 prefer > ASN:18 prefer > > Such a solution would be very useful for P2P apps. ISPs will be able > to decide how much information they want to reveal about their own > network topology and business arrangements. The amount of information > revealed is the same as through a literal sorting oracle if I'm > allowed to ask an unlimited number of sorting questions. Every > concerned party will thus have an incentive to use this solution. > Solution is also easy to deploy: for discovery, the ISP will need to > add one line to a forward DNS zone file; for the actual service, it'll > need to use a simple script in daily cron to post-process "show ip > bgp" output or equivalent. > > The discovery mechanism would be easy to generalize and use for other > kinds of discovery. > > The ALTO information service would be useful for anything that can > choose traffic sources/destinations: P2P, CDN, mirror selection, etc. > > -- > Stanislav Shalunov > > Hacking Startups > > ------------------------------------------------------------------------ > > _______________________________________________ > 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 Aug 2 14:33: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 A60FE3A6B4E; Sat, 2 Aug 2008 14:33: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 D0B883A6B24 for ; Sat, 2 Aug 2008 14:33:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.19 X-Spam-Level: X-Spam-Status: No, score=-10.19 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, HABEAS_ACCREDITED_COI=-8, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1ABINdqUw4r8 for ; Sat, 2 Aug 2008 14:33:49 -0700 (PDT) Received: from dkny.pando.com (dkny.pando.com [67.99.55.163]) by core3.amsl.com (Postfix) with ESMTP id 42BBF3A6B4E for ; Sat, 2 Aug 2008 14:33:49 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by dkny.pando.com (Postfix) with ESMTP id B0B90E10B1E; Sat, 2 Aug 2008 17:34:12 -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 D1axi+DaBar4; Sat, 2 Aug 2008 17:33:59 -0400 (EDT) Received: from dkny.pando.com (dkny.pando.com [10.10.60.11]) by dkny.pando.com (Postfix) with ESMTP id 516B6E10B6C; Sat, 2 Aug 2008 17:33:59 -0400 (EDT) Date: Sat, 2 Aug 2008 17:33:59 -0400 (EDT) From: Laird Popkin To: "Y. Richard Yang" Message-ID: <452173435.97941217712839289.JavaMail.root@dkny.pando.com> In-Reply-To: <1973750549.97921217712604616.JavaMail.root@dkny.pando.com> MIME-Version: 1.0 X-Originating-IP: [71.187.207.81] Cc: p2pi@ietf.org Subject: Re: [p2pi] ALTO service privacy, performance, and architecture X-BeenThere: p2pi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: P2P Infrastructure Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: p2pi-bounces@ietf.org Errors-To: p2pi-bounces@ietf.org Keep in mind that there's no real difference between "getting a file from an URL" and "getting a response from a web service", since any parameters that would be in the request could also be in the URL, and the response "file" could be dynamically generated if desired. So the only difference is in more subtle tradeoffs, such as personal preferences and fairly small differences in efficiency (e.g. constructing an URL is less work than constructing a SOAP request). The format of the returned data is actually more of an issue, since the data volume is larger, making issues of efficiency more important. We're using XML right now, which is actually fairly space efficient (LZW does very well with XML) but an XML parser has much more overhead than a more limited message handler probably would, so it could make sense to move to some other data format, so long as it's extensible, versioned, etc. - Laird Popkin, CTO, Pando Networks mobile: 646/465-0570 ----- Original Message ----- From: "Y. Richard Yang" To: "Stanislav Shalunov" Cc: p2pi@ietf.org Sent: Saturday, August 2, 2008 5:18:20 PM (GMT-0500) America/New_York Subject: Re: [p2pi] ALTO service privacy, performance, and architecture Hi Stansilav, In short, I like your points. The P4P team, including those here at Yale and Laird, had thought about the type of interface for a while. There were many discussions on the type of interface, in particular, a sorting interface or the P4P interface or some other type of interface (e.g., your proposal). We argue that the sorting interface, although simple and can be considered as a special case of the p4p distance (vcost) interface, we feel that it is limited and can have many issues. The virtual cost interface used in the current P4P field test actually is quite similar to your proposal, with three differences: - Like Laird said in the previous email, we allowing the addition of sources, instead of only destinations, for specifying ISP preference. - Instead of a binary value (avoid/prefer), we allow a range of numerical values. - we query the ISP servers, instead of URL/HTML web pages. Directly using a URL is quite interesting. We will need be able to update the web page, access control, etc. Richard Stanislav Shalunov wrote: > Much time has been spent discussing the operation of a sorting oracle > or oracles answering questions like "What is the load on this link?", > "Where did I put my glasses?", "How can I make $100M dollars this > year?", "What is the link capacity between 1.2.3.4 and 1.2.3.5?", "If > I were to send a packet to 1.2.3.4 after my next scheduling slice in > the OS ends and I start to feel pretty, what would be the delay?". > A sorting oracle is a useful concept to consider when thinking about > the system as a whole. The oracle that answers questions it can't > possibly answer is not a useful concept. > > A literal sorting oracle operated by the ISP will, however, *not* be > queried by P2P apps and is, therefore, not relevant. > > Passing just a few IP numbers to such an oracle is not enough because > it won't solve the localization problem: chances are none of the few > are nearby. > > Passing the entire swarm or nearly the entire swarm to the oracle is > not something that we would do in BitTorrent. I expect other P2P apps > with users will also not consider this privacy horror seriously. > > The sorting needs to happen inside the client. > > P2P apps already can easily have a lot of information about the > network topology. For example, it is entirely practical to download > the entire Internet routing table to every client and keep it current. > The routing table, is of course, publicly available at a looking > glass near you. What P2P apps don't know about the topology is what > the ISP would actually prefer. > > The sort of things that it would be useful to know are: > > * Does the ISP prefer local traffic? > > * Which IP ranges are local? > > * Are there any IP ranges best avoided? (Mobile or DSL when fiber is > available, for example.) > > Here is an example of a solution that would answer this sort of questions. > > 1. The client discovers an URL using a mechanism similar to BEP 22. > Say the URL is http://nms.example.net/ip-routing-policy > > 2. The client checks how long ago it has downloaded this URL. If more > than a month ago, downloads again. The URL is a file containing > things like: > > IP4:1.2.3/24 prefer > IP4:1.2.4/24 avoid > ASN:16 prefer > ASN:18 prefer > > Such a solution would be very useful for P2P apps. ISPs will be able > to decide how much information they want to reveal about their own > network topology and business arrangements. The amount of information > revealed is the same as through a literal sorting oracle if I'm > allowed to ask an unlimited number of sorting questions. Every > concerned party will thus have an incentive to use this solution. > Solution is also easy to deploy: for discovery, the ISP will need to > add one line to a forward DNS zone file; for the actual service, it'll > need to use a simple script in daily cron to post-process "show ip > bgp" output or equivalent. > > The discovery mechanism would be easy to generalize and use for other > kinds of discovery. > > The ALTO information service would be useful for anything that can > choose traffic sources/destinations: P2P, CDN, mirror selection, etc. > > -- > Stanislav Shalunov > > Hacking Startups > > ------------------------------------------------------------------------ > > _______________________________________________ > p2pi mailing list > p2pi@ietf.org > https://www.ietf.org/mailman/listinfo/p2pi > _______________________________________________ p2pi mailing list p2pi@ietf.org https://www.ietf.org/mailman/listinfo/p2pi _______________________________________________ p2pi mailing list p2pi@ietf.org https://www.ietf.org/mailman/listinfo/p2pi From p2pi-bounces@ietf.org Sat Aug 2 14:37: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 87A743A6B4E; Sat, 2 Aug 2008 14:37: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 12BBC3A68FF for ; Sat, 2 Aug 2008 14:37:35 -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 WYSxQRBIEiBz for ; Sat, 2 Aug 2008 14:37:34 -0700 (PDT) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.225]) by core3.amsl.com (Postfix) with ESMTP id 472AE3A6B4E for ; Sat, 2 Aug 2008 14:37:33 -0700 (PDT) Received: by rv-out-0506.google.com with SMTP id b25so1331976rvf.49 for ; Sat, 02 Aug 2008 14:37:57 -0700 (PDT) Received: by 10.114.26.18 with SMTP id 18mr13114876waz.130.1217713077239; Sat, 02 Aug 2008 14:37:57 -0700 (PDT) Received: from Inbox ( [75.211.181.9]) by mx.google.com with ESMTPS id l27sm4107121waf.27.2008.08.02.14.37.54 (version=SSLv3 cipher=RC4-MD5); Sat, 02 Aug 2008 14:37:56 -0700 (PDT) MIME-Version: 1.0 From: Stanislav Shalunov Date: Sat, 2 Aug 2008 14:37:56 -0700 Importance: normal X-Priority: 3 To: Laird Popkin Message-ID: <4894d3b4.1bbc720a.5b6a.ffffbebc@mx.google.com> Cc: p2pi@ietf.org Subject: Re: [p2pi] ALTO service privacy, performance, and architecture X-BeenThere: p2pi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: P2P Infrastructure Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Sender: p2pi-bounces@ietf.org Errors-To: p2pi-bounces@ietf.org VGhlcmUgaXMgYSByZXNvbHV0aW9uIG9mICJsb2NhbCIgdGhhdCdzIHZlcnkgc3BlY2lhbCBhbmQg cmVsZXZhbnQgZm9yIHRoZSBJU1AuICBUaGlzIHJlc29sdXRpb24gaXMgYWxzbyByZWxldmFudCBm b3IgdXNlcnMgaW4gY291bnRpZXMgd2hlcmUgcGVyIGJpdCBlbmQtdXNlciBjaGFyZ2VzIGFyZSBj b252ZW50aW9uYWwuCgoiTG9jYWwiID0gdGhlIElTUCBwYXlzIGV4dGVybmFsIHBhcnRpZXMgbm90 aGluZyBwZXIgYml0LgoKVGhlIElTUCB3aWxsIGxpa2VseSBjaG9vc2Ugbm90IHRvIHJldmVhbCBl dmVyeSBJUCByYW5nZSB3aXRoIHRoaXMgcHJvcGVydHksIGJ1dCByZXZlYWxpbmcgc29tZSB3b3Vs ZCBhbHJlYWR5IGJlIHVzZWZ1bC4KCkZpbmVyIHJlc29sdXNpb25zIHRoYW4gdGhpcyBhcmUgbGVz cyB1c2VmdWwsIGJlY2F1c2UgeW91IG5lZWQgcm91Z2hseSAyMCBsb2NhbCBwZWVycyBmb3IgbG9j YWxpemF0aW9uIG9uIERTTCBvciBjYWJsZSBhbmQgZ2V0dGluZyB0aGlzIG1hbnkgb3V0IG9mIHRo ZSB0aG91c2FuZHMgaW4gdGhlIGJpZ2dlc3Qgc3dhcm1zIHRoYXQgYXJlIGluIHRoaXMgbGFyZ2Vz dCBsb2NhbCB6b25lIGlzIGFscmVhZHkgY2hhbGxlbmdpbmcuCgpTb21lIGZ1cnRoZXIgbG9jYWxp emF0aW9uIGNvdWxkIGJlIG1hZGUgcG9zc2libGUgd2l0aCBzb3VyY2UgZGVwZW5kZW5jZSBhbmQg d2VpZ2h0cywgYnV0IHRoYXQncyBwcm9iYWJseSBvdmVya2lsbC4KClRoaXJkLXBhcnR5IHF1ZXJp ZXMgY2FuIGdvIGVpdGhlciB3YXkuICBUaGUgdHJhY2tlciBjb3VsZCBsZWFybiBmcm9tIHBlZXJz IGlmIHN1Y2ggcXVlcmllcyBhcmUgbm90IHN1cHBvcnRlZC4gIEluIHRoZSBhcmNoaXRlY3R1cmUg SSBkZXNjcmliZSwgc3RhcnRpbmcgd2l0aCBhbiBJUCBhZGRyZXNzIG90aGVyIHRoYW4geW91ciBv d24gd2lsbCByZXN1bHQgYW4gYW5zd2VyIG90aGVyIHRoYW4gbG9jYWwuICBUaGUgSVNQIGNhbiBj b250cm9sIGFjY2VzcyB0byB0aGUgVVJMIGJ5IHNvdXJjZSBJUC4KCkRvZXMgdGhpcyBtYWtlIHNl bnNlPwoKLS0gU3RhcwoKCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tCkZyb206ICJMYWlyZCBQ b3BraW4iIDxsYWlyZEBwYW5kby5jb20+ClRvOiAiU3RhbmlzbGF2IFNoYWx1bm92IiA8c2hhbHVu b3ZAc2hsYW5nLmNvbT4KQ2M6IHAycGlAaWV0Zi5vcmcKU2VudDogOC8yLzA4IDE6NTcgUE0KU3Vi amVjdDogUmU6IFtwMnBpXSBBTFRPIHNlcnZpY2UgcHJpdmFjeSwgcGVyZm9ybWFuY2UsIGFuZCBh cmNoaXRlY3R1cmUKCklnbm9yaW5nIHRoZSBzYXJjYXNtLCBJIGFncmVlIHdpdGggbXVjaCBvZiB3 aGF0IHlvdSd2ZSB3cml0dGVuLCB3aXRoIHRoZSBjYXZlYXQgdGhhdCB0aGUgYW5zd2VycyB0aGF0 IHRoZSBvcmFjbGUgcHJvdmlkZXMgbmVlZCB0byBiZSByZWxhdGl2ZSB0byBzb21lIHBvaW50LiBG b3IgZXhhbXBsZSwgdGhlIGFuc3dlciB0byB0aGUgcXVlc3Rpb24gIndoaWNoIElQIHJhbmdlcyBh cmUgbG9jYWwiIGlzIGJ5IGRlZmluaXRpb24gZGlmZmVyZW50IGZvciBlYWNoIGxvY2FsaXR5IHRo YXQgdGhlIElTUCBjYXJlcyBhYm91dC4gQWxzbywgZm9yIG1hbnkgcDJwIGFyY2hpdGVjdHVyZXMg dGhpcyBzZXJ2aWNlIG5lZWRzIHRvIGJlIGFjY2Vzc2libGUgYnkgYSB0aGlyZCBwYXJ0eSAoZS5n LiBhIFRyYWNrZXIpIGFza2luZyBvbiBiZWhhbGYgb2YgYSBjbGllbnQsIGFuZCBzaG91bGQgYmUg YXBwbGljYWJsZSB0byBhbnkgcDJwIG5ldHdvcmsgKG9yIG90aGVyIGFwcGxpY2F0aW9uKSBzbyB0 aGUgbWVjaGFuaXNtIGRlc2NyaWJlZCB3b3VsZCBuZWVkIHRvIGJlIGdlbmVyYWxpemVkIHNvbWV3 aGF0LiAKCi3CoExhaXJkwqBQb3BraW4swqBDVE8swqBQYW5kb8KgTmV0d29ya3MgCsKgwqBtb2Jp bGU6wqA2NDYvNDY1LTA1NzAgLsKgIAoKX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX18KcDJwaSBtYWlsaW5nIGxpc3QKcDJwaUBpZXRmLm9yZwpodHRwczovL3d3 dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3AycGkK From p2pi-bounces@ietf.org Sat Aug 2 14:39: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 E2ABA3A68FF; Sat, 2 Aug 2008 14:39: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 0CB083A68FF for ; Sat, 2 Aug 2008 14: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=[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 lOichlLvtNIj for ; Sat, 2 Aug 2008 14:39:46 -0700 (PDT) Received: from QMTA03.westchester.pa.mail.comcast.net (qmta03.westchester.pa.mail.comcast.net [76.96.62.32]) by core3.amsl.com (Postfix) with ESMTP id 1DC173A6803 for ; Sat, 2 Aug 2008 14:39:46 -0700 (PDT) Received: from OMTA11.westchester.pa.mail.comcast.net ([76.96.62.36]) by QMTA03.westchester.pa.mail.comcast.net with comcast id xWLD1Z0200mv7h053Zg9Sx; Sat, 02 Aug 2008 21:40:09 +0000 Received: from poweredge.velvetsea.net ([76.182.22.132]) by OMTA11.westchester.pa.mail.comcast.net with comcast id xZff1Z00B2qze2s3XZfkHn; Sat, 02 Aug 2008 21:40:04 +0000 X-Authority-Analysis: v=1.0 c=1 a=HQ6x2VH6PSwA:10 a=Mr5i1LQ58koA:10 a=By_OErhAiwBJ8PoiFJMA:9 a=KopTBiW_AIRpCUKDXITXzq9XR9MA:4 a=MxZ3bB5I4kYA:10 Received: from desktop.velvetsea.net (desktop.velvetsea.net [192.168.1.4]) by poweredge.velvetsea.net (Postfix) with ESMTP id 59676424001; Sat, 2 Aug 2008 17:39:39 -0400 (EDT) From: Richard Alimi To: p2pi@ietf.org Date: Sat, 2 Aug 2008 17:39:39 -0400 User-Agent: KMail/1.10.0 (Linux/2.6.24.4; KDE/4.1.1; i686; ; ) References: <2BC23947-E7E7-4E59-98B2-05E79AE8BA78@shlang.com> <4894CF1C.2030904@cs.yale.edu> In-Reply-To: <4894CF1C.2030904@cs.yale.edu> MIME-Version: 1.0 Content-Disposition: inline Message-Id: <200808021739.39172.richard.alimi@yale.edu> Subject: Re: [p2pi] ALTO service privacy, performance, and architecture X-BeenThere: p2pi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: P2P Infrastructure Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: p2pi-bounces@ietf.org Errors-To: p2pi-bounces@ietf.org > - we query the ISP servers, instead of URL/HTML web pages. Directly > using a URL is quite interesting. We will need be able to update the web > page, access control, etc. To add to Richard's last point, we have been rethinking our P4P protocol spec in the past couple of weeks and have been moving to a REST-based approach which would provide this behavior and would integrate well with authentication and access control (HTTP basic/digest auth, SSL certs) and encryption (SSL), and should ease adoption by P2P application developers. Since some queries may be particularly common and small and SSL/HTTP/TCP may become an overhead (as has been mentioned before here by Laird and others), we are allowing certain queries via UDP. -- Richard Alimi Department of Computer Science Yale University _______________________________________________ p2pi mailing list p2pi@ietf.org https://www.ietf.org/mailman/listinfo/p2pi From p2pi-bounces@ietf.org Sat Aug 2 15: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 0F4EA3A6B8F; Sat, 2 Aug 2008 15: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 A31C53A6B8D for ; Sat, 2 Aug 2008 15:01:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4CKb+d8NhXnC for ; Sat, 2 Aug 2008 15:01:22 -0700 (PDT) Received: from netra.cs.yale.edu (netra.cs.yale.edu [128.36.229.21]) by core3.amsl.com (Postfix) with ESMTP id BE9513A6B50 for ; Sat, 2 Aug 2008 14:59:55 -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 A15794094F2; Sat, 2 Aug 2008 18:00:19 -0400 (EDT) Date: Sat, 2 Aug 2008 18:00:19 -0400 (EDT) From: "Y. R. Yang" To: Stanislav Shalunov In-Reply-To: <4894d3b4.1bbc720a.5b6a.ffffbebc@mx.google.com> Message-ID: References: <4894d3b4.1bbc720a.5b6a.ffffbebc@mx.google.com> MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="612390885-1006206311-1217714419=:8969" Cc: p2pi@ietf.org Subject: Re: [p2pi] ALTO service privacy, performance, and architecture X-BeenThere: p2pi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: P2P Infrastructure Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: p2pi-bounces@ietf.org Errors-To: p2pi-bounces@ietf.org This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --612390885-1006206311-1217714419=:8969 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 Content-Transfer-Encoding: QUOTED-PRINTABLE On Sat, 2 Aug 2008, 2:37pm -0700, Stanislav Shalunov wrote: > There is a resolution of "local" that's very special and relevant for=20 > the ISP. This resolution is also relevant for users in counties where=20 > per bit end-user charges are conventional. > "Local" =3D the ISP pays external parties nothing per bit. > The ISP will likely choose not to reveal every IP range with this=20 > property, but revealing some would already be useful. > Finer resolutions than this are less useful, because you need roughly 20= =20 > local peers for localization on DSL or cable and getting this many out=20 > of the thousands in the biggest swarms that are in this largest local=20 > zone is already challenging. I take your local (i.e., not paying external parties) means within the=20 same ISP. From our running test, we do often can see many local choices and thus would like more information to make the choice. Another reason for finer information is that you may not want to choose=20 only local. The preference can be _is_better_than_ _is_better_than_ This showed up in our current experiment (configured by an ISP), and=20 turned out to be able to help applications very well. Do you think this will be too complicated? Richard > Some further localization could be made possible with source dependence= =20 > and weights, but that's probably overkill. > Third-party queries can go either way. The tracker could learn from=20 > peers if such queries are not supported. In the architecture I=20 > describe, starting with an IP address other than your own will result an= =20 > answer other than local. The ISP can control access to the URL by > source IP. > Does this make sense? > -- Stas -----Original Message----- From: "Laird Popkin" To: "Stanislav Shalunov" Cc: p2pi@ietf.org Sent: 8/2/08 1:57 PM Subject: Re: [p2pi] ALTO service privacy, performance, and architecture Ignoring the sarcasm, I agree with much of what you've written, with the ca= veat that the answers that the oracle provides need to be relative to some = point. For example, the answer to the question "which IP ranges are local" = is by definition different for each locality that the ISP cares about. Also= , for many p2p architectures this service needs to be accessible by a third= party (e.g. a Tracker) asking on behalf of a client, and should be applica= ble to any p2p network (or other application) so the mechanism described wo= uld need to be generalized somewhat.=20 -=A0Laird=A0Popkin,=A0CTO,=A0Pando=A0Networks=20 =A0=A0mobile:=A0646/465-0570 .=A0=20 _______________________________________________ p2pi mailing list p2pi@ietf.org https://www.ietf.org/mailman/listinfo/p2pi --612390885-1006206311-1217714419=:8969 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 --612390885-1006206311-1217714419=:8969-- From p2pi-bounces@ietf.org Sat Aug 2 15:03: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 66FA83A687C; Sat, 2 Aug 2008 15:03: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 20F253A687C for ; Sat, 2 Aug 2008 15:03:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.447 X-Spam-Level: X-Spam-Status: No, score=0.447 tagged_above=-999 required=5 tests=[AWL=0.310, BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, J_CHICKENPOX_57=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h5jMdWhkG5an for ; Sat, 2 Aug 2008 15:03:55 -0700 (PDT) Received: from pacdcimo01.cable.comcast.com (PacdcIMO01.cable.comcast.com [24.40.8.145]) by core3.amsl.com (Postfix) with ESMTP id 9A4F53A6803 for ; Sat, 2 Aug 2008 15:03:55 -0700 (PDT) Received: from ([10.52.116.30]) by pacdcimo01.cable.comcast.com with ESMTP id 5503620.9983552; Sat, 02 Aug 2008 18:04:04 -0400 Received: from PACDCEXCMB06.cable.comcast.com ([24.40.15.22]) by PAOAKEXCSMTP01.cable.comcast.com with Microsoft SMTPSVC(6.0.3790.3959); Sat, 2 Aug 2008 18:04:03 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Sat, 2 Aug 2008 18:04:03 -0400 Message-ID: <74CCBBDF76102846AFA7B29F3A98D3F601940670@PACDCEXCMB06.cable.comcast.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [p2pi] why I didn't hum yes (yet) Thread-Index: Acj0t96Mvqo/+KfFQt+8dIGmjYQuDAAMST57 References: <1232737442.90411217507981759.JavaMail.root@dkny.pando.com><1959788251.90461217508317275.JavaMail.root@dkny.pando.com><200807311754.m6VHsBVg000355@bagheera.jungle.bt.co.uk><74CCBBDF76102846AFA7B29F3A98D3F601940660@PACDCEXCMB06.cable.comcast.com> <200808021551.m72FpOAN003831@bagheera.jungle.bt.co.uk> From: "Woundy, Richard" To: "Bob Briscoe" X-OriginalArrivalTime: 02 Aug 2008 22:04:03.0258 (UTC) FILETIME=[ACBC69A0:01C8F4EB] Cc: p2pi@ietf.org Subject: Re: [p2pi] why I didn't hum yes (yet) X-BeenThere: p2pi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: P2P Infrastructure Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: p2pi-bounces@ietf.org Errors-To: p2pi-bounces@ietf.org >Do you mean uploading by p2p apps that P4P has helped shift, or uploading by all apps including other p2p systems? I meant only P2P uploading that has been influenced by P4P, which is a very small proportion of our current P2P traffic. That's because we have only a handful of cooperating P2P trackers (from one source) in the current P4P trial, in a world with tens of thousands of trackers (from many different sources). >I hope I've made clear I'm not saying I believe P4P is wrong, I'm just asking for rigor in the claims of 'better'. That's reasonable. Incidentally, I was just reading some comments from journalist Thomas Friedman (New York Times) that seem appropriate to quote here: "A lot of journalists have lost the distinction between skepticism and cynicism. A skeptic says, 'I don't know. I'm going to find out.' A cynic says, 'I already know. I don't need to find out.'" So I appreciate your skepticism on this topic. :) -- Rich ________________________________ From: p2pi-bounces@ietf.org on behalf of Bob Briscoe Sent: Sat 8/2/2008 11:51 AM To: Woundy, Richard Cc: p2pi@ietf.org Subject: Re: [p2pi] why I didn't hum yes (yet) Rich, Thanks - this data is getting more useful. More inline... At 09:25 01/08/2008, Woundy, Richard wrote: >Bob, > >I feel compelled to respond to some of your points. > >At Comcast, we studied the P4P results from Verizon earlier this >year, before we committed to a trial this summer. There were three >items of interest from those results: > >1. > Faster downloads for P2P users >2. > Reduced backbone transit traffic for the ISP >3. > * The same aggregate amount of uploading by ISP customers Do you mean uploading by p2p apps that P4P has helped shift, or uploading by all apps including other p2p systems? If you mean not just P4P apps but all apps, getting no increase in uploading could be an effect of the performance probing of non-P4P apps finding that Comcast's upstream is getting congested so they naturally choose peers in other networks to download from instead of yours (as you say below). In that case, P4P can indeed be judged as 'better'. Essentially it would be initiating a shuffle around of /all/ the transit flows so more were local, not just it's own. I hope I've made clear I'm not saying I believe P4P is wrong, I'm just asking for rigor in the claims of 'better'. >We're not ready to reveal the results of our own recently-concluded >P4P trial, but suffice it to say that we are seeing similar results. >I suspect the reason behind point #3 is that P2P uploads within the >ISP displace the P2P uploads outside the ISP. And the reason behind >point #2 may be that there are fewer outside factors (e.g. multiple >transit backbones) that could cause congestion. > >We need to perform more analysis before we can conclude that ISP >localization doesn't increase upstream traffic, but at least on >average it does not increase upstream traffic. If it turns out that >P4P localization is cost-neutral on an access basis, then that would >be a critical item to retain for ALTO. Certainly. And I'm glad you're not jumping to conclusions. >BTW, I agree with many of your other comments. For example, I agree >that minimizing RTT for P2P connections isn't all that critical. For >example, I've heard that clever P2P users are often motivated (where >possible) to select peers in Japan and Korea, because higher upload >throughput trumps RTT every time. Just to be clear, I was saying RTT /will/ become much less critical over the next year or so as these new congestion controls become widespread. That drastically cuts the incentive for p2p users to voluntarily ask an oracle (losing your point 1: 'faster downloads for p2p users'). > >It costs more (bit for bit) to upgrade access and backhaul than it > does to upgrade interconnect (there's a considerable economy of > scale). If someone from a cablecco has told you it's most important > to reduce transit costs, you'll find they did NOT mean "and at the > same time please introduce higher backhaul and access costs instead". > >I've been talking to Laird, and I seem to be from a 'cableco', so >maybe you're referring to me. (And maybe I'm one of the amateurs as well.) :^/ :) > >But I am pretty sure I have been consistent on this point, from the >P2PI Workshop to the ALTO BOF to other private conversations -- our >broadband access costs are much higher than our backbone / transit >costs. As my boss would say, "backhoe costs don't follow Moore's >Law". For Comcast, minimizing transit costs is nice but not the >fundamental concern. Everyone on the list, please take this to heart. > >BTW, I have heard that for other ISPs, transit costs *are* a >fundamental issue. And not just in the so-called "third world". Certainly, Telecom New Zealand say this and our friends in Oz. Bob > >-- Rich > > >Laird, > >At 13:45 31/07/2008, Laird Popkin wrote: > >Addressing remark 1: localizing network traffic (based on the p4p > >field tests, which used ISP network maps and an "oracle") shows a > >strong benefit in transit reduction and in performance improvement, > >for networks that are DSL, Cable or FTTH. > >I think my rather important previous point got missed (sorry my mail >had a lot of points)... > >Neither of these metrics for 'better' impresses me much at all. > >* If performance of p2p is better, and if there is shared congestion >with other non-p2p users on the same local network, this means the >performance of others will most likely be worse. Overall, is this >better or worse? > >* If there's transit reduction, equivalent traffic will instead be >being uploaded from the local network. Again, if the local network >already has shared congestion upstream (a cable network does), that's >making it _worse_ both for local p2p & non-p2p users. > > >It costs more (bit for bit) to upgrade access and backhaul than it >does to upgrade interconnect (there's a considerable economy of >scale). If someone from a cablecco has told you it's most important >to reduce transit costs, you'll find they did NOT mean "and at the >same time please introduce higher backhaul and access costs instead". > >See the picture I posted yesterday to this list: > > >The Internetwork is provided to be used. Let's not assume a >DISINTERNET is 'better' without being clear what 'better' means. > >I've seen no research that uses a full cost-benefit analysis. That's >hard (e.g. what's the relative value of p2p bits versus non-p2p >bits). But without such a study, unfortunately, what everyone is >calling 'better' looks like 'worse' to me on second looks - at least >for networks with a congested upstream. > >On third looks (ie a full study) it might not be worse. But can >people please enter this debate on the assumption that network >economics is dangerous in the hands of amateurs (which includes the >large majority of folks even in telcos/cablecos). > > >Bob > > > >____________________________________________________________________________ >Bob Briscoe, Networks Research Centre, BT Research >B54/77 Adastral Park,Martlesham Heath,Ipswich,IP5 3RE,UK. +44 1473 645196 > > >_______________________________________________ >p2pi mailing list >p2pi@ietf.org >https://www.ietf.org/mailman/listinfo/p2pi ____________________________________________________________________________ Bob Briscoe, Networks Research Centre, BT Research B54/77 Adastral Park,Martlesham Heath,Ipswich,IP5 3RE,UK. +44 1473 645196 _______________________________________________ p2pi mailing list p2pi@ietf.org https://www.ietf.org/mailman/listinfo/p2pi _______________________________________________ p2pi mailing list p2pi@ietf.org https://www.ietf.org/mailman/listinfo/p2pi From p2pi-bounces@ietf.org Sat Aug 2 15:10:50 2008 Return-Path: X-Original-To: p2pi-archive@ietf.org Delivered-To: ietfarch-p2pi-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2B6BD3A6AA5; Sat, 2 Aug 2008 15:10:50 -0700 (PDT) X-Original-To: p2pi@core3.amsl.com Delivered-To: p2pi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C147E3A6AA5 for ; Sat, 2 Aug 2008 15:10:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.186 X-Spam-Level: X-Spam-Status: No, score=-6.186 tagged_above=-999 required=5 tests=[AWL=0.413, 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 cV3vuZ2-FiWm for ; Sat, 2 Aug 2008 15:10:49 -0700 (PDT) Received: from exprod7og105.obsmtp.com (exprod7og105.obsmtp.com [64.18.2.163]) by core3.amsl.com (Postfix) with ESMTP id F02FD3A6880 for ; Sat, 2 Aug 2008 15:10:47 -0700 (PDT) Received: from source ([66.129.228.6]) by exprod7ob105.postini.com ([64.18.6.12]) with SMTP; Sat, 02 Aug 2008 15:11:11 PDT Received: from p-emlb01-sac.jnpr.net ([66.129.254.46]) by p-emsmtp01.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Sat, 2 Aug 2008 15:10:56 -0700 Received: from emailwf1.jnpr.net ([10.10.2.33]) by p-emlb01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Sat, 2 Aug 2008 15:10:56 -0700 Received: from proton.jnpr.net ([10.10.2.37]) by emailwf1.jnpr.net with Microsoft SMTPSVC(6.0.3790.1830); Sat, 2 Aug 2008 18:10:55 -0400 Received: from 172.23.1.57 ([172.23.1.57]) by proton.jnpr.net ([10.10.2.37]) with Microsoft Exchange Server HTTP-DAV ; Sat, 2 Aug 2008 22:10:55 +0000 User-Agent: Microsoft-Entourage/12.11.0.080522 Date: Sat, 02 Aug 2008 15:10:52 -0700 From: Reinaldo Penno To: , Laird Popkin Message-ID: Thread-Topic: Is P4P protocol public domain so its functionality can be reviewed? Thread-Index: Acj07KBdUF1pLsSn80m29krPELJXfQ== In-Reply-To: <200808021739.39172.richard.alimi@yale.edu> X-Priority: 1 Mime-version: 1.0 X-OriginalArrivalTime: 02 Aug 2008 22:10:55.0631 (UTC) FILETIME=[A28789F0:01C8F4EC] Subject: [p2pi] Is P4P protocol public domain so its functionality can be reviewed? X-BeenThere: p2pi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: P2P Infrastructure Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: p2pi-bounces@ietf.org Errors-To: p2pi-bounces@ietf.org Is the P4P protocol public domain? I'm saying this because every time somebody suggests a different approach the answer is invariably "P4P can do this" or "we in P4P were _just_ thinking about this". Any protocol candidate to IETF standardization needs to be public documented in a RFC or some public domain site. We (as in the wide public) need to understand in-depth how P4P works, so it can be peer reviewed, everybody can have a opinion about it and not just drink from the cool-aid. Thanks, Reinaldo _______________________________________________ p2pi mailing list p2pi@ietf.org https://www.ietf.org/mailman/listinfo/p2pi From p2pi-bounces@ietf.org Sat Aug 2 15:15: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 C2DD83A692B; Sat, 2 Aug 2008 15:15: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 12E403A6B6A for ; Sat, 2 Aug 2008 15:15:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iNEZSg02rNWA for ; Sat, 2 Aug 2008 15:15:38 -0700 (PDT) Received: from QMTA04.emeryville.ca.mail.comcast.net (qmta04.emeryville.ca.mail.comcast.net [76.96.30.40]) by core3.amsl.com (Postfix) with ESMTP id 471883A692B for ; Sat, 2 Aug 2008 15:15:38 -0700 (PDT) Received: from OMTA12.emeryville.ca.mail.comcast.net ([76.96.30.44]) by QMTA04.emeryville.ca.mail.comcast.net with comcast id xZB41Z0010x6nqcA4aG2zF; Sat, 02 Aug 2008 22:16:02 +0000 Received: from poweredge.velvetsea.net ([76.182.22.132]) by OMTA12.emeryville.ca.mail.comcast.net with comcast id xaFp1Z0012qze2s8YaFrJ9; Sat, 02 Aug 2008 22:16:00 +0000 X-Authority-Analysis: v=1.0 c=1 a=HQ6x2VH6PSwA:10 a=Mr5i1LQ58koA:10 a=oz4ovGKR7ruKBf8Q6k4A:9 a=tpnynWdlTADJU2oEYWoA:7 a=Dhthj94rB2U3nQ2BNIBIGXryyQ8A:4 a=LY0hPdMaydYA:10 Received: from desktop.velvetsea.net (desktop.velvetsea.net [192.168.1.4]) by poweredge.velvetsea.net (Postfix) with ESMTP id BE70D424001; Sat, 2 Aug 2008 18:15:48 -0400 (EDT) From: Richard Alimi To: p2pi@ietf.org Date: Sat, 2 Aug 2008 18:15:48 -0400 User-Agent: KMail/1.10.0 (Linux/2.6.24.4; KDE/4.1.1; i686; ; ) References: <4894d3b4.1bbc720a.5b6a.ffffbebc@mx.google.com> In-Reply-To: <4894d3b4.1bbc720a.5b6a.ffffbebc@mx.google.com> MIME-Version: 1.0 Content-Disposition: inline Message-Id: <200808021815.48477.richard.alimi@yale.edu> Subject: Re: [p2pi] ALTO service privacy, performance, and architecture X-BeenThere: p2pi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: P2P Infrastructure Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Sender: p2pi-bounces@ietf.org Errors-To: p2pi-bounces@ietf.org T24gU2F0dXJkYXkgMDIgQXVndXN0IDIwMDggMTc6Mzc6NTYgU3RhbmlzbGF2IFNoYWx1bm92IHdy b3RlOgo+IFRoZXJlIGlzIGEgcmVzb2x1dGlvbiBvZiAibG9jYWwiIHRoYXQncyB2ZXJ5IHNwZWNp YWwgYW5kIHJlbGV2YW50IGZvciB0aGUKPiBJU1AuICBUaGlzIHJlc29sdXRpb24gaXMgYWxzbyBy ZWxldmFudCBmb3IgdXNlcnMgaW4gY291bnRpZXMgd2hlcmUgcGVyIGJpdAo+IGVuZC11c2VyIGNo YXJnZXMgYXJlIGNvbnZlbnRpb25hbC4KPgo+ICJMb2NhbCIgPSB0aGUgSVNQIHBheXMgZXh0ZXJu YWwgcGFydGllcyBub3RoaW5nIHBlciBiaXQuCgpBbm90aGVyIHBvc3NpYmlsaXR5IGlzIGZvciAi bG9jYWxpdHkiIHRvIG5vdCBiZSBhIHNwYXRpYWwvZ2VvZ3JhcGhpYyBjb25jZXB0LiAKT25lIGlk ZWEgdGhhdCB3ZSBoYXZlIGNvbnNpZGVyZWQgaW4gUDRQIHdhcyB0byBkZWZpbmUgUElEcyBmb3Ig ZGlmZmVyZW50IApjb25nZXN0aW9uIHN0YXRlcy4gRm9yIGV4YW1wbGUsIG9uZSBjb3VsZCBkZWZp bmUgMyBQSURzOiBoaWdoLWNvbmdlc3Rpb24sIAptZWRpdW0tY29uZ2VzdGlvbiwgYW5kIGxvdy1j b25nZXN0aW9uLiBUaGVuLCAoZS5nLiwgaW4gYSBjYWJsZSBuZXR3b3JrKSBDTVRTcyAKY2FuIGJl IHBlcmlvZGljYWxseSBtb3ZlZCBiZXR3ZWVuIFBJRHMgYmFzZWQgb24gdGhlaXIgbGV2ZWwgb2Yg ZGV0ZWN0ZWQgCmNvbmdlc3Rpb24uIMKgVGhlbiwgZm9yIGV4YW1wbGUsIHBlZXJzIGluIHRoZSBQ SUQgZm9yIGxvdy1jb25nZXN0aW9uIHN0YXRlIGNhbiAKbW9yZS1wcmVmZXJlbnRpYWxseSBwZWVy IHdpdGggZWFjaCBvdGhlciBhbmQgY29zdHMgd291bGQgYmUgZGVmaW5lZCBiZXR3ZWVuIAplYWNo IGNvbmdlc3Rpb24gc3RhdGUuIMKgT2YgY291cnNlLCB0aGUgbmF0dXJlIG9mIGNvbmdlc3Rpb24g KGUuZy4sIAp1cHN0cmVhbS9kb3duc3RyZWFtKSBtYXkgYWxzbyBuZWVkIHRvIGJlIHRha2VuIGlu dG8gYWNjb3VudC4KCj4gVGhpcmQtcGFydHkgcXVlcmllcyBjYW4gZ28gZWl0aGVyIHdheS4gIFRo ZSB0cmFja2VyIGNvdWxkIGxlYXJuIGZyb20gcGVlcnMKPiBpZiBzdWNoIHF1ZXJpZXMgYXJlIG5v dCBzdXBwb3J0ZWQuICBJbiB0aGUgYXJjaGl0ZWN0dXJlIEkgZGVzY3JpYmUsCj4gc3RhcnRpbmcg d2l0aCBhbiBJUCBhZGRyZXNzIG90aGVyIHRoYW4geW91ciBvd24gd2lsbCByZXN1bHQgYW4gYW5z d2VyIG90aGVyCj4gdGhhbiBsb2NhbC4gIFRoZSBJU1AgY2FuIGNvbnRyb2wgYWNjZXNzIHRvIHRo ZSBVUkwgYnkgc291cmNlIElQLgoKRm9yIHRyYWNrZXItYmFzZWQgc3lzdGVtcywgaG93IGRvZXMg dGhpcyB3b3JrPyDCoFRoZSBzb3VyY2UgSVAgYWRkcmVzcyBmb3Igc3VjaCAKYSBxdWVyeSB3b3Vs ZCBiZSB0aGUgdHJhY2tlciBJUCBhZGRyZXNzLCBpbnN0ZWFkIG9mIHRoZSBjbGllbnQncyBJUCBh ZGRyZXNzIAood2hpY2ggc2hvdWxkIGJlIHRoZSBmcmFtZS1vZi1yZWZlcmVuY2UgZm9yIGFueSBy ZWNvbW1lbmRhdGlvbnMpLiAKCk9yLCBhcmUgeW91IGVudmlzaW9uaW5nIHRoYXQgY2xpZW50cyBy ZXRyaWV2ZSB0aGUgcmVjb21tZW5kYXRpb25zIGFuZCB0aGVuIAptZXJnZSB0aGVtIHdpdGggd2hh dGV2ZXIgaW5mb3JtYXRpb24gdGhlIHRyYWNrZXIgc2VuZHMgdGhlbT8gwqBPciBkbyBjbGllbnRz IAp0aGVuIGZvcndhcmQgdGhlc2UgcmVjb21tZW5kYXRpb25zIHRvIHRoZSB0cmFja2VyIHRvIHV0 aWxpemUgaW4gaXRzIHBlZXIgCnNlbGVjdGlvbj8KCi0tIApSaWNoYXJkIEFsaW1pCkRlcGFydG1l bnQgb2YgQ29tcHV0ZXIgU2NpZW5jZQpZYWxlIFVuaXZlcnNpdHkKCl9fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fCnAycGkgbWFpbGluZyBsaXN0CnAycGlAaWV0 Zi5vcmcKaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9wMnBpCg== From p2pi-bounces@ietf.org Sat Aug 2 15:23:47 2008 Return-Path: X-Original-To: p2pi-archive@ietf.org Delivered-To: ietfarch-p2pi-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5127D3A6B7F; Sat, 2 Aug 2008 15:23:47 -0700 (PDT) X-Original-To: p2pi@core3.amsl.com Delivered-To: p2pi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7C7B73A6B7F for ; Sat, 2 Aug 2008 15:23:46 -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 pH-P-216IVDr for ; Sat, 2 Aug 2008 15:23:45 -0700 (PDT) Received: from netra.cs.yale.edu (netra.cs.yale.edu [128.36.229.21]) by core3.amsl.com (Postfix) with ESMTP id 6EBAD3A6B78 for ; Sat, 2 Aug 2008 15:23:45 -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 609424094F2; Sat, 2 Aug 2008 18:24:09 -0400 (EDT) Date: Sat, 2 Aug 2008 18:24:08 -0400 (EDT) From: "Y. R. Yang" To: Reinaldo Penno In-Reply-To: Message-ID: References: MIME-Version: 1.0 Cc: p2pi@ietf.org Subject: Re: [p2pi] Is P4P protocol public domain so its functionality can be reviewed? X-BeenThere: p2pi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: P2P Infrastructure Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: p2pi-bounces@ietf.org Errors-To: p2pi-bounces@ietf.org Hi Reinaldo, The design principles of P4P are specified in some detail in this SIGCOMM'08 paper: http://cs-www.cs.yale.edu/homes/yry/projects/p4p/p4p-sigcomm08.pdf Of course, the paper can be only 12 pages :-) and many details are not there. Also, the protocols/system are evolving, with extremely valuable discussions like in this group. Yale is considering releasing much of the system from the Yale side (ISP P4P configuration language (two versions), the protocol APIs, application optimization engine for computing peering guidelines for file sharing). Of course we will need to get permissions from others since it gets a lot of inputs from others. Note that we have no detailed writeup. Many things (configuration language, protocol, API, and algorithms) are in code. I think writing them down will be on the agenda for the next P4P working group meeting on August 5. Any help will be greatly appreciated. Richard On Sat, 2 Aug 2008, 3:10pm -0700, Reinaldo Penno wrote: > Is the P4P protocol public domain? I'm saying this because every time > somebody suggests a different approach the answer is invariably > > "P4P can do this" or "we in P4P were _just_ thinking about this". > > Any protocol candidate to IETF standardization needs to be public > documented in a RFC or some public domain site. We (as in the wide > public) need to understand in-depth how P4P works, so it can be peer > reviewed, everybody can have a opinion about it and not just drink from > the cool-aid. > > Thanks, > > Reinaldo > > > > > _______________________________________________ > 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 Aug 2 16:00:34 2008 Return-Path: X-Original-To: p2pi-archive@ietf.org Delivered-To: ietfarch-p2pi-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EC95B3A68D8; Sat, 2 Aug 2008 16:00:34 -0700 (PDT) X-Original-To: p2pi@core3.amsl.com Delivered-To: p2pi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D7C043A67A6 for ; Sat, 2 Aug 2008 16:00:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.255 X-Spam-Level: X-Spam-Status: No, score=-6.255 tagged_above=-999 required=5 tests=[AWL=0.344, 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 iz-b+sQr2m93 for ; Sat, 2 Aug 2008 16:00:33 -0700 (PDT) Received: from exprod7og116.obsmtp.com (exprod7ob116.obsmtp.com [64.18.2.218]) by core3.amsl.com (Postfix) with ESMTP id 5B0753A69DB for ; Sat, 2 Aug 2008 16:00:17 -0700 (PDT) Received: from source ([66.129.228.6]) by exprod7ob116.postini.com ([64.18.6.12]) with SMTP; Sat, 02 Aug 2008 16:00:38 PDT Received: from p-emlb01-sac.jnpr.net ([66.129.254.46]) by p-emsmtp01.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Sat, 2 Aug 2008 16:00:25 -0700 Received: from emailwf1.jnpr.net ([10.10.2.33]) by p-emlb01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Sat, 2 Aug 2008 16:00:25 -0700 Received: from proton.jnpr.net ([10.10.2.37]) by emailwf1.jnpr.net with Microsoft SMTPSVC(6.0.3790.1830); Sat, 2 Aug 2008 19:00:24 -0400 Received: from 172.23.1.57 ([172.23.1.57]) by proton.jnpr.net ([10.10.2.37]) with Microsoft Exchange Server HTTP-DAV ; Sat, 2 Aug 2008 23:00:23 +0000 User-Agent: Microsoft-Entourage/12.11.0.080522 Date: Sat, 02 Aug 2008 16:00:21 -0700 From: Reinaldo Penno To: "Y. R. Yang" Message-ID: Thread-Topic: [p2pi] Is P4P protocol public domain so its functionality can be reviewed? Thread-Index: Acj084oGFW7oUPuI7Ui5MqIQjg5Ldw== In-Reply-To: Mime-version: 1.0 X-OriginalArrivalTime: 02 Aug 2008 23:00:24.0364 (UTC) FILETIME=[8C083EC0:01C8F4F3] Cc: p2pi@ietf.org Subject: Re: [p2pi] Is P4P protocol public domain so its functionality can be reviewed? X-BeenThere: p2pi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: P2P Infrastructure Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: p2pi-bounces@ietf.org Errors-To: p2pi-bounces@ietf.org Thanks for the response Richard. I'm very familiar with your paper. I appreciate the effort but if distill your comments the answer is "no, no public domain at this point", correct? It would be good to get timelines for the release of information. I'm not a member (as many others) of P4P so I'm not sure how much help I can provide. On the other hand access to your code would be a good start, is there a link to that? But the bottom line is that I feel it very difficult as a IETF participant to have discussions around a proprietary protocol that we do not have access. At this point the information other IETF participants have regarding P4P are functionality claimed in some emails that cannot be reviewed or verified. Thanks, Reinaldo On 8/2/08 3:24 PM, "Y. R. Yang" wrote: > > Hi Reinaldo, > > The design principles of P4P are specified in some detail in this > SIGCOMM'08 paper: > http://cs-www.cs.yale.edu/homes/yry/projects/p4p/p4p-sigcomm08.pdf > > Of course, the paper can be only 12 pages :-) and many details are not > there. Also, the protocols/system are evolving, with extremely valuable > discussions like in this group. Yale is considering releasing much of the > system from the Yale side (ISP P4P configuration language (two versions), > the protocol APIs, application optimization engine for computing peering > guidelines for file sharing). Of course we will need to get permissions > from others since it gets a lot of inputs from others. > > Note that we have no detailed writeup. Many things (configuration > language, protocol, API, and algorithms) are in code. I think writing them > down will be on the agenda for the next P4P working group meeting on > August 5. Any help will be greatly appreciated. > > Richard > > On Sat, 2 Aug 2008, 3:10pm -0700, Reinaldo Penno wrote: > >> Is the P4P protocol public domain? I'm saying this because every time >> somebody suggests a different approach the answer is invariably >> >> "P4P can do this" or "we in P4P were _just_ thinking about this". >> >> Any protocol candidate to IETF standardization needs to be public >> documented in a RFC or some public domain site. We (as in the wide >> public) need to understand in-depth how P4P works, so it can be peer >> reviewed, everybody can have a opinion about it and not just drink from >> the cool-aid. >> >> Thanks, >> >> Reinaldo >> >> >> >> >> _______________________________________________ >> 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 Aug 2 16:30: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 7DE633A69EC; Sat, 2 Aug 2008 16:30: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 0298E3A6982 for ; Sat, 2 Aug 2008 16:30:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.25 X-Spam-Level: X-Spam-Status: No, score=-2.25 tagged_above=-999 required=5 tests=[AWL=0.350, 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 Mhf9kqmmXnuO for ; Sat, 2 Aug 2008 16:30:25 -0700 (PDT) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.224]) by core3.amsl.com (Postfix) with ESMTP id 4A1DD3A6B78 for ; Sat, 2 Aug 2008 16:30:21 -0700 (PDT) Received: by rv-out-0506.google.com with SMTP id b25so1346468rvf.49 for ; Sat, 02 Aug 2008 16:30:44 -0700 (PDT) Received: by 10.114.137.2 with SMTP id k2mr13209791wad.95.1217719844702; Sat, 02 Aug 2008 16:30:44 -0700 (PDT) Received: from ?192.168.1.103? ( [67.188.243.194]) by mx.google.com with ESMTPS id d20sm4251066waa.37.2008.08.02.16.30.44 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sat, 02 Aug 2008 16:30:44 -0700 (PDT) Message-Id: <5156BEE8-42F5-43A1-89F2-C5C0775A9FD5@shlang.com> From: Stanislav Shalunov To: "Y. Richard Yang" In-Reply-To: <4894CF1C.2030904@cs.yale.edu> Mime-Version: 1.0 (Apple Message framework v926) Date: Sat, 2 Aug 2008 16:30:42 -0700 References: <2BC23947-E7E7-4E59-98B2-05E79AE8BA78@shlang.com> <4894CF1C.2030904@cs.yale.edu> X-Mailer: Apple Mail (2.926) Cc: p2pi@ietf.org Subject: Re: [p2pi] ALTO service privacy, performance, and architecture X-BeenThere: p2pi@ietf.org 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 Aug 2, 2008, at 2:18 PM, Y. Richard Yang wrote: > - Like Laird said in the previous email, we allowing the addition of > sources, instead of only destinations, for specifying ISP preference. It's important for privacy reasons that the app should not have to tell the ISP about every IP address it might consider connecting to. WRT asking about sources other than yourself, I'm fine either way, because the tracker can get the information from the peers. > - Instead of a binary value (avoid/prefer), we allow a range of > numerical values. I'm just using prefer/avoid as examples. The actual format and semantics can be different. > - we query the ISP servers, instead of URL/HTML web pages. Directly > using a URL is quite interesting. We will need be able to update the > web page, access control, etc. That's nearly the same. I would definitely not make the format HTML. (Personally, I'd prefer a microformat, but XML, as heavy as it is, would be functionally close.) It doesn't even need to be an HTTP URL, of course. The sort of architecture I describe is one example of where your P4P trackers could get the information from. Generic building blocks are good. Thank you, -- Stanislav Shalunov _______________________________________________ p2pi mailing list p2pi@ietf.org https://www.ietf.org/mailman/listinfo/p2pi From p2pi-bounces@ietf.org Sat Aug 2 16:43: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 64B683A6B8B; Sat, 2 Aug 2008 16:43: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 8A37D3A6B8D for ; Sat, 2 Aug 2008 16:43:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.319 X-Spam-Level: X-Spam-Status: No, score=-2.319 tagged_above=-999 required=5 tests=[AWL=0.280, 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 c1qtuRUVgsJ2 for ; Sat, 2 Aug 2008 16:43:39 -0700 (PDT) Received: from wf-out-1314.google.com (wf-out-1314.google.com [209.85.200.169]) by core3.amsl.com (Postfix) with ESMTP id BBBEE3A6B8B for ; Sat, 2 Aug 2008 16:43:39 -0700 (PDT) Received: by wf-out-1314.google.com with SMTP id 27so1467097wfd.31 for ; Sat, 02 Aug 2008 16:43:50 -0700 (PDT) Received: by 10.142.240.9 with SMTP id n9mr4334836wfh.214.1217720630373; Sat, 02 Aug 2008 16:43:50 -0700 (PDT) Received: from ?192.168.1.103? ( [67.188.243.194]) by mx.google.com with ESMTPS id 30sm5434376wfc.5.2008.08.02.16.43.49 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sat, 02 Aug 2008 16:43:49 -0700 (PDT) Message-Id: <2DB3849B-CBD9-4554-A9F4-51B4BC4ACF33@shlang.com> From: Stanislav Shalunov To: "Y. R. Yang" In-Reply-To: Mime-Version: 1.0 (Apple Message framework v926) Date: Sat, 2 Aug 2008 16:43:48 -0700 References: <4894d3b4.1bbc720a.5b6a.ffffbebc@mx.google.com> X-Mailer: Apple Mail (2.926) Cc: p2pi@ietf.org Subject: Re: [p2pi] ALTO service privacy, performance, and architecture X-BeenThere: p2pi@ietf.org 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 Aug 2, 2008, at 3:00 PM, Y. R. Yang wrote: > I take your local (i.e., not paying external parties) means within the > same ISP. Mostly broader than that. No-cost peering arrangements are common and often exposed to the users already, just not in a machine-readable form. > From our running test, we do often can see many local choices > and thus would like more information to make the choice. The choice between zero cost and zero cost is probably not something the ISP cares deeply about, thus it would have little incentive to provide more detailed resolution of information about its network. As an aside, being able to use only same-AS peers is very uncommon in BitTorrent swarms that comprise most of P2P network use. > Another reason for finer information is that you may not want to > choose > only local. The preference can be > > _is_better_than_ _is_better_than_ > > This showed up in our current experiment (configured by an ISP), and > turned out to be able to help applications very well. > > Do you think this will be too complicated? This should fit nicely into what I describe if we replace avoid/prefer with a numeric cost scale. The ISP needs to have an incentive to provide the information for the scheme to be deployable. The ISP has a strong incentive to tell the apps what's free for it. The apps have a good incentive to use it in countries without per-bit end-user charges (like the US) and an extremely strong incentive to use it in countries with per-bit end-user charges (most of the rest of the world). In the former case, the app/user incentive is not provoking blocking/throttling, while in the latter case the incentive is reducing the bill for the user. -- Stanislav Shalunov _______________________________________________ p2pi mailing list p2pi@ietf.org https://www.ietf.org/mailman/listinfo/p2pi From p2pi-bounces@ietf.org Sat Aug 2 16:50: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 1EAF43A69F9; Sat, 2 Aug 2008 16:50:53 -0700 (PDT) X-Original-To: p2pi@core3.amsl.com Delivered-To: p2pi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 93E0E3A69F9 for ; Sat, 2 Aug 2008 16:50:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.366 X-Spam-Level: X-Spam-Status: No, score=-2.366 tagged_above=-999 required=5 tests=[AWL=0.233, 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 XmF0j5oTFtG6 for ; Sat, 2 Aug 2008 16:50:50 -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 CA8753A68A1 for ; Sat, 2 Aug 2008 16:50:50 -0700 (PDT) Received: by wf-out-1314.google.com with SMTP id 27so1468309wfd.31 for ; Sat, 02 Aug 2008 16:51:14 -0700 (PDT) Received: by 10.142.229.4 with SMTP id b4mr4353228wfh.143.1217721074852; Sat, 02 Aug 2008 16:51:14 -0700 (PDT) Received: from ?192.168.1.103? ( [67.188.243.194]) by mx.google.com with ESMTPS id 24sm2690297wff.17.2008.08.02.16.51.14 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sat, 02 Aug 2008 16:51:14 -0700 (PDT) Message-Id: From: Stanislav Shalunov To: Richard Alimi In-Reply-To: <200808021812.46743.rich@velvetsea.net> Mime-Version: 1.0 (Apple Message framework v926) Date: Sat, 2 Aug 2008 16:51:12 -0700 References: <4894d3b4.1bbc720a.5b6a.ffffbebc@mx.google.com> <200808021812.46743.rich@velvetsea.net> X-Mailer: Apple Mail (2.926) Cc: p2pi@ietf.org Subject: Re: [p2pi] ALTO service privacy, performance, and architecture X-BeenThere: p2pi@ietf.org 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 Aug 2, 2008, at 3:12 PM, Richard Alimi wrote: > Another possibility is for "locality" to not be a spatial/geographic > concept. > One idea that we have considered in P4P was to define PIDs for > different > congestion states. For example, one could define 3 PIDs: high- > congestion, > medium-congestion, and low-congestion. Then, (e.g., in a cable > network) CMTSs > can be periodically moved between PIDs based on their level of > detected > congestion. Then, for example, peers in the PID for low-congestion > state can > more-preferentially peer with each other and costs would be defined > between > each congestion state. Of course, the nature of congestion (e.g., > upstream/downstream) may also need to be taken into account. This is transport information. I don't think that conveying it belongs anywhere outside of the transport area. ALTO is outside the transport area. > Or, are you envisioning that clients retrieve the recommendations > and then > merge them with whatever information the tracker sends them? That's the main deployment path if we are to help the ISPs with the real problem. There are many more tracker codebases that matter than client codebases that matter. > Or do clients > then forward these recommendations to the tracker to utilize in its > peer > selection? I think this is a reasonable option if operators find an interface that takes source IP as an input worrisome. -- Stanislav Shalunov _______________________________________________ p2pi mailing list p2pi@ietf.org https://www.ietf.org/mailman/listinfo/p2pi From p2pi-bounces@ietf.org Sat Aug 2 16:55: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 6B88B3A69DB; Sat, 2 Aug 2008 16:55: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 422023A68A1 for ; Sat, 2 Aug 2008 16:55:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.399 X-Spam-Level: X-Spam-Status: No, score=-2.399 tagged_above=-999 required=5 tests=[AWL=0.200, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5n-lYTWyEV8P for ; Sat, 2 Aug 2008 16:55:18 -0700 (PDT) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.235]) by core3.amsl.com (Postfix) with ESMTP id 85FC73A69DB for ; Sat, 2 Aug 2008 16:55:18 -0700 (PDT) Received: by rv-out-0506.google.com with SMTP id b25so1349598rvf.49 for ; Sat, 02 Aug 2008 16:55:40 -0700 (PDT) Received: by 10.114.133.1 with SMTP id g1mr13168651wad.149.1217721340560; Sat, 02 Aug 2008 16:55:40 -0700 (PDT) Received: from ?192.168.1.103? ( [67.188.243.194]) by mx.google.com with ESMTPS id k21sm4216568waf.8.2008.08.02.16.55.39 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sat, 02 Aug 2008 16:55:40 -0700 (PDT) Message-Id: <76E4BF6A-7C26-466A-BB58-19D04D6FF6EF@shlang.com> From: Stanislav Shalunov To: Richard Alimi In-Reply-To: <200808021734.54855.rich@velvetsea.net> Mime-Version: 1.0 (Apple Message framework v926) Date: Sat, 2 Aug 2008 16:55:38 -0700 References: <2BC23947-E7E7-4E59-98B2-05E79AE8BA78@shlang.com> <4894CF1C.2030904@cs.yale.edu> <200808021734.54855.rich@velvetsea.net> X-Mailer: Apple Mail (2.926) Cc: p2pi@ietf.org Subject: Re: [p2pi] ALTO service privacy, performance, and architecture X-BeenThere: p2pi@ietf.org 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 Aug 2, 2008, at 2:34 PM, Richard Alimi wrote: > Since some queries may be particularly common and small and SSL/HTTP/ > TCP may > become an overhead (as has been mentioned before here by Laird and > others), we > are allowing certain queries via UDP. Not sure which queries these are. I find it unlikely that large- volume queries would not have prohibitive privacy implications. What else would one ask for a lot if it's not a bunch of possible destination IPs? -- Stanislav Shalunov _______________________________________________ p2pi mailing list p2pi@ietf.org https://www.ietf.org/mailman/listinfo/p2pi From p2pi-bounces@ietf.org Sat Aug 2 17:10: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 09B6B3A6A0B; Sat, 2 Aug 2008 17:10: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 726FB3A6B70 for ; Sat, 2 Aug 2008 17:10:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id St46L7MDqkMa for ; Sat, 2 Aug 2008 17:10:02 -0700 (PDT) Received: from QMTA01.emeryville.ca.mail.comcast.net (qmta01.emeryville.ca.mail.comcast.net [76.96.30.16]) by core3.amsl.com (Postfix) with ESMTP id C58B33A6A07 for ; Sat, 2 Aug 2008 17:10:02 -0700 (PDT) Received: from OMTA01.emeryville.ca.mail.comcast.net ([76.96.30.11]) by QMTA01.emeryville.ca.mail.comcast.net with comcast id xbni1Z00A0EPchoA1cASyx; Sun, 03 Aug 2008 00:10:26 +0000 Received: from poweredge.velvetsea.net ([76.182.22.132]) by OMTA01.emeryville.ca.mail.comcast.net with comcast id xcAF1Z00B2qze2s8McAJki; Sun, 03 Aug 2008 00:10:24 +0000 X-Authority-Analysis: v=1.0 c=1 a=HQ6x2VH6PSwA:10 a=Mr5i1LQ58koA:10 a=UtkTuAfLCSkyl49cI6UA:9 a=uukFiDs96YymPiLv0lsA:7 a=XhqhktzXK4CchhTq2VPXRPiamWwA:4 a=LY0hPdMaydYA:10 Received: from desktop.velvetsea.net (desktop.velvetsea.net [192.168.1.4]) by poweredge.velvetsea.net (Postfix) with ESMTP id 1F293424001; Sat, 2 Aug 2008 20:10:15 -0400 (EDT) From: Richard Alimi To: Stanislav Shalunov Date: Sat, 2 Aug 2008 20:10:14 -0400 User-Agent: KMail/1.10.0 (Linux/2.6.24.4; KDE/4.1.1; i686; ; ) References: <2BC23947-E7E7-4E59-98B2-05E79AE8BA78@shlang.com> <200808021734.54855.rich@velvetsea.net> <76E4BF6A-7C26-466A-BB58-19D04D6FF6EF@shlang.com> In-Reply-To: <76E4BF6A-7C26-466A-BB58-19D04D6FF6EF@shlang.com> MIME-Version: 1.0 Content-Disposition: inline Message-Id: <200808022010.14891.richard.alimi@yale.edu> Cc: p2pi@ietf.org Subject: Re: [p2pi] ALTO service privacy, performance, and architecture X-BeenThere: p2pi@ietf.org X-Mailman-Version: 2.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 On Saturday 02 August 2008 19:55:38 Stanislav Shalunov wrote: > On Aug 2, 2008, at 2:34 PM, Richard Alimi wrote: > > Since some queries may be particularly common and small and SSL/HTTP/ > > TCP may > > become an overhead (as has been mentioned before here by Laird and > > others), we > > are allowing certain queries via UDP. > > Not sure which queries these are. I find it unlikely that large- > volume queries would not have prohibitive privacy implications. What > else would one ask for a lot if it's not a bunch of possible > destination IPs? The query in the P4P protocol that I'm referring to is for a client to obta= in = its PID (a la DHCP). =A0It locates its ISP's iTracker (e.g., via DNS SRV), = queries for its PID, and then uses that (iTracker,PID) pair when either = registering with an application tracker, or querying the iTracker itself = (e.g., for tracker-less systems). =A0ISPs with many subscribers may need th= is to = be UDP. -- = Richard Alimi Department of Computer Science Yale University = _______________________________________________ p2pi mailing list p2pi@ietf.org https://www.ietf.org/mailman/listinfo/p2pi From p2pi-bounces@ietf.org Sat Aug 2 17:28: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 211C13A6C09; Sat, 2 Aug 2008 17:28: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 1E9BC3A6C02 for ; Sat, 2 Aug 2008 17:28:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.606 X-Spam-Level: X-Spam-Status: No, score=-5.606 tagged_above=-999 required=5 tests=[AWL=-0.403, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b80EsJlYrzIA for ; Sat, 2 Aug 2008 17:28:06 -0700 (PDT) Received: from exprod7og110.obsmtp.com (exprod7og110.obsmtp.com [64.18.2.173]) by core3.amsl.com (Postfix) with ESMTP id 8893A3A6C09 for ; Sat, 2 Aug 2008 17:28:04 -0700 (PDT) Received: from source ([66.129.228.6]) by exprod7ob110.postini.com ([64.18.6.12]) with SMTP; Sat, 02 Aug 2008 17:28:03 PDT Received: from p-emlb01-sac.jnpr.net ([66.129.254.46]) by p-emsmtp02.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Sat, 2 Aug 2008 17:24:58 -0700 Received: from antipi.jnpr.net ([10.10.2.34]) by p-emlb01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Sat, 2 Aug 2008 17:24:58 -0700 Received: from proton.jnpr.net ([10.10.2.37]) by antipi.jnpr.net with Microsoft SMTPSVC(6.0.3790.1830); Sat, 2 Aug 2008 20:24:57 -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 ; Sun, 3 Aug 2008 00:24:56 +0000 User-Agent: Microsoft-Entourage/12.11.0.080522 Date: Sat, 02 Aug 2008 17:24:53 -0700 From: Reinaldo Penno To: Richard Alimi , Stanislav Shalunov Message-ID: Thread-Topic: [p2pi] ALTO service privacy, performance, and architecture Thread-Index: Acj0/1ks0A6tuC1TU0WNzf2F+tDnZg== In-Reply-To: <200808022010.14891.richard.alimi@yale.edu> Mime-version: 1.0 X-OriginalArrivalTime: 03 Aug 2008 00:24:57.0058 (UTC) FILETIME=[5B97EC20:01C8F4FF] Cc: p2pi@ietf.org Subject: Re: [p2pi] ALTO service privacy, performance, and architecture X-BeenThere: p2pi@ietf.org X-Mailman-Version: 2.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 Hi, I just want to remind that we are here because of file-sharing and not really closed P2P networks where itrackers, apptrackers and others cooperate nicely. This is the easy case and today does not cause problems to ISPs. And maybe never will. So, when you say "tracker-less" systems you mean a P2P network without a tracker (Gnutella) or a P2P network where the tracker is something like thepiratebay? The two 'systems' (as you put it) are quite different. In the case where there is a tracker on the Internet that does not cooperate (which is 99.99% of P2P traffic today) I'm not sure how ALTO would work without the ISP tracker pushing information to the clients (since the clients might not send info to the tracker). For private trackers (which have the really hardcore users) it is not clear how ALTO can influence their behavior since the whole point is to stay within the private tracker's given peers. If we cannot tackle these two scenarios, ISPs continue to suffer. Thanks, Reinaldo On 8/2/08 5:10 PM, "Richard Alimi" wrote: > On Saturday 02 August 2008 19:55:38 Stanislav Shalunov wrote: >> On Aug 2, 2008, at 2:34 PM, Richard Alimi wrote: >>> Since some queries may be particularly common and small and SSL/HTTP/ >>> TCP may >>> become an overhead (as has been mentioned before here by Laird and >>> others), we >>> are allowing certain queries via UDP. >> = >> Not sure which queries these are. I find it unlikely that large- >> volume queries would not have prohibitive privacy implications. What >> else would one ask for a lot if it's not a bunch of possible >> destination IPs? > = > The query in the P4P protocol that I'm referring to is for a client to ob= tain > its PID (a la DHCP). =A0It locates its ISP's iTracker (e.g., via DNS SRV), > queries for its PID, and then uses that (iTracker,PID) pair when either > registering with an application tracker, or querying the iTracker itself > (e.g., for tracker-less systems). =A0ISPs with many subscribers may need = this to > be UDP. _______________________________________________ p2pi mailing list p2pi@ietf.org https://www.ietf.org/mailman/listinfo/p2pi From p2pi-bounces@ietf.org Sat Aug 2 17:31: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 32C253A6B37; Sat, 2 Aug 2008 17:31: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 333483A6A0B for ; Sat, 2 Aug 2008 17:31:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OcRMRAKYi0C0 for ; Sat, 2 Aug 2008 17:31:08 -0700 (PDT) Received: from QMTA04.emeryville.ca.mail.comcast.net (qmta04.emeryville.ca.mail.comcast.net [76.96.30.40]) by core3.amsl.com (Postfix) with ESMTP id 7086E3A68A1 for ; Sat, 2 Aug 2008 17:31:08 -0700 (PDT) Received: from OMTA12.emeryville.ca.mail.comcast.net ([76.96.30.44]) by QMTA04.emeryville.ca.mail.comcast.net with comcast id xbZ61Z00A0x6nqcA4cXYrk; Sun, 03 Aug 2008 00:31:32 +0000 Received: from poweredge.velvetsea.net ([76.182.22.132]) by OMTA12.emeryville.ca.mail.comcast.net with comcast id xcXK1Z00D2qze2s8YcXNda; Sun, 03 Aug 2008 00:31:30 +0000 X-Authority-Analysis: v=1.0 c=1 a=HQ6x2VH6PSwA:10 a=Mr5i1LQ58koA:10 a=HeFMBH3tvFJpMOjtiHcA:9 a=mLTJZLuoT7kTLNZadgkA:7 a=L7RYGGS79PJ9QYCF9M6bXWqabewA:4 a=MxZ3bB5I4kYA:10 Received: from desktop.velvetsea.net (desktop.velvetsea.net [192.168.1.4]) by poweredge.velvetsea.net (Postfix) with ESMTP id 08746424001; Sat, 2 Aug 2008 20:31:19 -0400 (EDT) From: Richard Alimi To: Stanislav Shalunov Date: Sat, 2 Aug 2008 20:31:18 -0400 User-Agent: KMail/1.10.0 (Linux/2.6.24.4; KDE/4.1.1; i686; ; ) References: <4894d3b4.1bbc720a.5b6a.ffffbebc@mx.google.com> <200808021812.46743.rich@velvetsea.net> In-Reply-To: MIME-Version: 1.0 Content-Disposition: inline Message-Id: <200808022031.18821.richard.alimi@yale.edu> Cc: p2pi@ietf.org Subject: Re: [p2pi] ALTO service privacy, performance, and architecture X-BeenThere: p2pi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: P2P Infrastructure Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: p2pi-bounces@ietf.org Errors-To: p2pi-bounces@ietf.org > > [ .. example snipped .. ] > > This is transport information. I don't think that conveying it > belongs anywhere outside of the transport area. ALTO is outside the > transport area. You're right that the particular example was related to transport-layer information, but the idea of extending "locality" to be more than a spatial/geographic concept may not be. > > Or, are you envisioning that clients retrieve the recommendations > > and then > > merge them with whatever information the tracker sends them? > > That's the main deployment path if we are to help the ISPs with the > real problem. There are many more tracker codebases that matter than > client codebases that matter. That is a good point, and particularly relevant for tracker-less systems. I agree that clients should be able to perform queries themselves, but shouldn't trackers be able to perform queries as well should they choose to support it? Allowing this at trackers may provide more opportunities for optimization since they know more swarm state (or possibly state across multiple swarms being hosted at the same tracker). > > Or do clients > > then forward these recommendations to the tracker to utilize in its > > peer > > selection? > > I think this is a reasonable option if operators find an interface > that takes source IP as an input worrisome. Do you think it is reasonable task for a tracker to merge individual recommendations (format of course is to be determined) amongst each individual client? That seems quite difficult unless they have a particularly uniform structure. -- Richard Alimi Department of Computer Science Yale University _______________________________________________ p2pi mailing list p2pi@ietf.org https://www.ietf.org/mailman/listinfo/p2pi From p2pi-bounces@ietf.org Sat Aug 2 17:47: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 D3CD828C14A; Sat, 2 Aug 2008 17:47: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 01F9A28C14A for ; Sat, 2 Aug 2008 17:47:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.424 X-Spam-Level: X-Spam-Status: No, score=-2.424 tagged_above=-999 required=5 tests=[AWL=0.175, 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 gugW912rgEVK for ; Sat, 2 Aug 2008 17:47:35 -0700 (PDT) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.230]) by core3.amsl.com (Postfix) with ESMTP id 25EF528C148 for ; Sat, 2 Aug 2008 17:47:34 -0700 (PDT) Received: by rv-out-0506.google.com with SMTP id b25so1355962rvf.49 for ; Sat, 02 Aug 2008 17:47:58 -0700 (PDT) Received: by 10.115.78.1 with SMTP id f1mr13211156wal.150.1217724478770; Sat, 02 Aug 2008 17:47:58 -0700 (PDT) Received: from ?192.168.1.103? ( [67.188.243.194]) by mx.google.com with ESMTPS id m17sm4271685waf.35.2008.08.02.17.47.58 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sat, 02 Aug 2008 17:47:58 -0700 (PDT) Message-Id: <7726427C-519E-46E4-8D86-EE4DD421BC4A@shlang.com> From: Stanislav Shalunov To: Richard Alimi In-Reply-To: <200808022031.18821.richard.alimi@yale.edu> Mime-Version: 1.0 (Apple Message framework v926) Date: Sat, 2 Aug 2008 17:47:56 -0700 References: <4894d3b4.1bbc720a.5b6a.ffffbebc@mx.google.com> <200808021812.46743.rich@velvetsea.net> <200808022031.18821.richard.alimi@yale.edu> X-Mailer: Apple Mail (2.926) Cc: p2pi@ietf.org Subject: Re: [p2pi] ALTO service privacy, performance, and architecture X-BeenThere: p2pi@ietf.org 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 Aug 2, 2008, at 5:31 PM, Richard Alimi wrote: > You're right that the particular example was related to transport- > layer > information, but the idea of extending "locality" to be more than a > spatial/geographic concept may not be. Perhaps. I believe we should start with useful examples we can come up with and only generalize in obvious directions. By the way, "no-cost" (the only real useful example I can think of) isn't necessarily geographic. > That is a good point, and particularly relevant for tracker-less > systems. I > agree that clients should be able to perform queries themselves, but > shouldn't > trackers be able to perform queries as well should they choose to > support it? That would be fine. > Allowing this at trackers may provide more opportunities for > optimization > since they know more swarm state (or possibly state across multiple > swarms > being hosted at the same tracker). Some trackers know more, some less. Remember that some trackers are really simple. Popular clients all know quite a lot about the swarm. > Do you think it is reasonable task for a tracker to merge individual > recommendations (format of course is to be determined) amongst each > individual > client? That seems quite difficult unless they have a particularly > uniform > structure. I expect a tracker would just use this merged information to influence the peers it gives out to a given peer. Might somehow publish it, in principle, but that will probably make ISPs uncomfortable if they were uncomfortable about the information being available outside of their network to begin with. -- Stanislav Shalunov _______________________________________________ p2pi mailing list p2pi@ietf.org https://www.ietf.org/mailman/listinfo/p2pi From p2pi-bounces@ietf.org Sat Aug 2 18:11: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 55A753A68F1; Sat, 2 Aug 2008 18:11: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 383EC3A68F1 for ; Sat, 2 Aug 2008 18:11:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KKt2ZPKnZdIj for ; Sat, 2 Aug 2008 18:11:38 -0700 (PDT) Received: from QMTA06.emeryville.ca.mail.comcast.net (qmta06.emeryville.ca.mail.comcast.net [76.96.30.56]) by core3.amsl.com (Postfix) with ESMTP id 68D753A67E9 for ; Sat, 2 Aug 2008 18:11:38 -0700 (PDT) Received: from OMTA14.emeryville.ca.mail.comcast.net ([76.96.30.60]) by QMTA06.emeryville.ca.mail.comcast.net with comcast id xc1L1Z01r1HpZEsA6dC2xo; Sun, 03 Aug 2008 01:12:02 +0000 Received: from poweredge.velvetsea.net ([76.182.22.132]) by OMTA14.emeryville.ca.mail.comcast.net with comcast id xdBp1Z00A2qze2s8adBruM; Sun, 03 Aug 2008 01:12:00 +0000 X-Authority-Analysis: v=1.0 c=1 a=HQ6x2VH6PSwA:10 a=Mr5i1LQ58koA:10 a=cyPhJQfg8zlvw5e0Qa4A:9 a=01G-hBsxvV1VgeMOBIgA:7 a=D5ByfBfzBzedyuLqlEPOUh-FexUA:4 a=MxZ3bB5I4kYA:10 Received: from desktop.velvetsea.net (desktop.velvetsea.net [192.168.1.4]) by poweredge.velvetsea.net (Postfix) with ESMTP id 18486424001; Sat, 2 Aug 2008 21:11:49 -0400 (EDT) From: Richard Alimi To: Reinaldo Penno Date: Sat, 2 Aug 2008 21:11:48 -0400 User-Agent: KMail/1.10.0 (Linux/2.6.24.4; KDE/4.1.1; i686; ; ) References: In-Reply-To: MIME-Version: 1.0 Content-Disposition: inline Message-Id: <200808022111.48738.richard.alimi@yale.edu> Cc: p2pi@ietf.org Subject: Re: [p2pi] ALTO service privacy, performance, and architecture X-BeenThere: p2pi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: P2P Infrastructure Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: 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 want to remind that we are here because of file-sharing and not > really closed P2P networks where itrackers, apptrackers and others > cooperate nicely. This is the easy case and today does not cause problems > to ISPs. And maybe never will. Let me make one clarification to your statement above. The itracker in P4P is not application specific, and thus is not part of any closed system. It can be queried by many P2P applications, and does not keep any swarm state. The field tests have been done with Pando, but nothing restricts it from being used for "public" P2P networks. Or did I misinterpret your meaning of "closed"? > So, when you say "tracker-less" systems you mean a P2P network without a > tracker (Gnutella) or a P2P network where the tracker is something like > thepiratebay? The two 'systems' (as you put it) are quite different. By "tracker-less," I was referring to a P2P network without a tracker. We consider thepiratebay a tracker-based system. > In the case where there is a tracker on the Internet that does not > cooperate (which is 99.99% of P2P traffic today) I'm not sure how ALTO > would work without the ISP tracker pushing information to the clients > (since the clients might not send info to the tracker). I agree that to cover the majority of the P2P traffic, it may be mostly be client-dependent in the beginning. The idea, however, is that as time goes on P2P developers and ISPs will each realize the benefits (better performance for P2P apps, and achieve particular network goals for ISPs) and begin support. Integration should be simple enough that P2P developers understand and use it. > For private trackers (which have the really hardcore users) it is not clear > how ALTO can influence their behavior since the whole point is to stay > within the private tracker's given peers. If we cannot tackle these two > scenarios, ISPs continue to suffer. Interesting point. If there are limited peers in a swarm, then there are limited opportunities for optimization (both for the P2P and ISP side). Is this a fundamental limit, though? Aside, of course, from "telling" them that their swarms should be larger :) Getting adoption in major public P2P clients/trackers is certainly important in order for this to make a large difference for ISP networks. -- Richard Alimi Department of Computer Science Yale University _______________________________________________ p2pi mailing list p2pi@ietf.org https://www.ietf.org/mailman/listinfo/p2pi From p2pi-bounces@ietf.org Sat Aug 2 18:22: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 1C54A3A6C77; Sat, 2 Aug 2008 18:22: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 801013A6C77 for ; Sat, 2 Aug 2008 18:22:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[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 R2kLvx+fLQbw for ; Sat, 2 Aug 2008 18:22:23 -0700 (PDT) Received: from QMTA07.emeryville.ca.mail.comcast.net (qmta07.emeryville.ca.mail.comcast.net [76.96.30.64]) by core3.amsl.com (Postfix) with ESMTP id CA4D53A6B65 for ; Sat, 2 Aug 2008 18:22:23 -0700 (PDT) Received: from OMTA05.emeryville.ca.mail.comcast.net ([76.96.30.43]) by QMTA07.emeryville.ca.mail.comcast.net with comcast id xaaA1Z0010vp7WLA7dNo1A; Sun, 03 Aug 2008 01:22:48 +0000 Received: from poweredge.velvetsea.net ([76.182.22.132]) by OMTA05.emeryville.ca.mail.comcast.net with comcast id xdNc1Z00B2qze2s8RdNfNz; Sun, 03 Aug 2008 01:22:45 +0000 X-Authority-Analysis: v=1.0 c=1 a=HQ6x2VH6PSwA:10 a=Mr5i1LQ58koA:10 a=AF1q_9GuUEx_ieccsYYA:9 a=87h73m5e9tHAi1svtTQA:7 a=tKS_h0CmUUP1tV_uzUbu6Xg1BgoA:4 a=MxZ3bB5I4kYA:10 Received: from desktop.velvetsea.net (desktop.velvetsea.net [192.168.1.4]) by poweredge.velvetsea.net (Postfix) with ESMTP id 6CEAA424001; Sat, 2 Aug 2008 21:22:36 -0400 (EDT) From: Richard Alimi To: Stanislav Shalunov Date: Sat, 2 Aug 2008 21:22:35 -0400 User-Agent: KMail/1.10.0 (Linux/2.6.24.4; KDE/4.1.1; i686; ; ) References: <4894d3b4.1bbc720a.5b6a.ffffbebc@mx.google.com> <200808022031.18821.richard.alimi@yale.edu> <7726427C-519E-46E4-8D86-EE4DD421BC4A@shlang.com> In-Reply-To: <7726427C-519E-46E4-8D86-EE4DD421BC4A@shlang.com> MIME-Version: 1.0 Content-Disposition: inline Message-Id: <200808022122.36022.richard.alimi@yale.edu> Cc: p2pi@ietf.org Subject: Re: [p2pi] ALTO service privacy, performance, and architecture X-BeenThere: p2pi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: P2P Infrastructure Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: p2pi-bounces@ietf.org Errors-To: p2pi-bounces@ietf.org > > Do you think it is reasonable task for a tracker to merge individual > > recommendations (format of course is to be determined) amongst each > > individual > > client? That seems quite difficult unless they have a particularly > > uniform > > structure. > > I expect a tracker would just use this merged information to influence > the peers it gives out to a given peer. Might somehow publish it, in > principle, but that will probably make ISPs uncomfortable if they were > uncomfortable about the information being available outside of their > network to begin with. Yes, but my question was concerning the merging of such ISP recommendations, and how to turn this into peer recommendations for each joining peer. That appears to be the particularly challenging part. One simple option of course is to use only that joining peer's set of recommendations (prefer AS1, I don't like AS2), look into the current set of peers in the swarm, and choose a set that matches those recommendations. More interesting things could probably be done with the merged set of information though. -- Richard Alimi Department of Computer Science Yale University _______________________________________________ p2pi mailing list p2pi@ietf.org https://www.ietf.org/mailman/listinfo/p2pi From p2pi-bounces@ietf.org Sat Aug 2 19:02: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 2C42D3A6911; Sat, 2 Aug 2008 19:02: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 273D93A69C5 for ; Sat, 2 Aug 2008 19:02:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.201 X-Spam-Level: X-Spam-Status: No, score=-10.201 tagged_above=-999 required=5 tests=[AWL=0.064, 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 L0WwsofsJ80C for ; Sat, 2 Aug 2008 19:02:31 -0700 (PDT) Received: from dkny.pando.com (dkny.pando.com [67.99.55.163]) by core3.amsl.com (Postfix) with ESMTP id EDD083A6911 for ; Sat, 2 Aug 2008 19:02:30 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by dkny.pando.com (Postfix) with ESMTP id C7829E10B6C; Sat, 2 Aug 2008 22:02: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 AZfFROpewfnU; Sat, 2 Aug 2008 22:02:29 -0400 (EDT) Received: from dkny.pando.com (dkny.pando.com [10.10.60.11]) by dkny.pando.com (Postfix) with ESMTP id 964B9E10B94; Sat, 2 Aug 2008 22:02:29 -0400 (EDT) Date: Sat, 2 Aug 2008 22:02:29 -0400 (EDT) From: Laird Popkin To: Reinaldo Penno Message-ID: <823639194.98531217728949588.JavaMail.root@dkny.pando.com> In-Reply-To: <2011018428.98511217728390950.JavaMail.root@dkny.pando.com> MIME-Version: 1.0 X-Originating-IP: [71.187.207.81] Cc: p2pi@ietf.org Subject: Re: [p2pi] Is P4P protocol public domain so its functionality can be reviewed? X-BeenThere: p2pi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: P2P Infrastructure Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: p2pi-bounces@ietf.org Errors-To: p2pi-bounces@ietf.org I'm sorry that it's frustrating that the P4P Working Group participants keep answering in that way, but IMO it's a natural outcome of the situation; the P4P Working Group has been working in this area for a year, so anyone coming into the topic is likely to suggest things or raise issues that have already been thought of within the group. The responses aren't meant to make anyone feel excluded, though I can see how it might come across that way. I agree that publishing more information on the P4P work would help. In addition to Yale's publications, there have been writeups (e.g. http://www.openp4p.net/ that provides an overview, http://www.pandoblog.com/?p=261 that talks about Pando's experiences implementing P4P). I believe that there have been other papers submitted, but which aren't yet published. We should have results from the second round of testing shortly (i.e. ISPs are reviewing the results now, and have to decide what they're comfortable releasing). The goal of the tests so far wasn't particularly to generate the perfect protocol and implementation, but to perform real-world testing across multiple ISPs to quantify the impact of localizing traffic on various kinds of ISPs (retail, wholesale, DSL, cable, fiber), and to experiment with a variety of optimization strategies. Our assumption has been that the actual protocol used to enable that optimization will change. The field tests have triggered significant evolutions in the protocol, and will probably continue to do so. And assuming that the ALTO WG is formed, I'm sure that what it comes up with will not be simply an adoption of the P4P work so far. To elaborate on Richard's answer, the P4P protocol is currently only published within the P4P Working Group, which is open to interested parties (with no cost). The idea of limiting access is to allow for rapid evolution early in the process - the intention is that as we work through field tests the protocol and code will mature to the point where they will be suitable to be shared to the public. I think that we're getting pretty close - Yale is working on approvals, etc. Until then, there's no cost to participating in the P4P WG, so I'd encourage that. I should clarify that I don't view P4P as a "protocol candidate" at this point, just an example of the kind of optimization that can be provided by ALTO.. - Laird Popkin, CTO, Pando Networks mobile: 646/465-0570 ----- Original Message ----- From: "Reinaldo Penno" To: p2pi@ietf.org, "Laird Popkin" Sent: Saturday, August 2, 2008 6:10:52 PM (GMT-0500) America/New_York Subject: Is P4P protocol public domain so its functionality can be reviewed? Is the P4P protocol public domain? I'm saying this because every time somebody suggests a different approach the answer is invariably "P4P can do this" or "we in P4P were _just_ thinking about this". Any protocol candidate to IETF standardization needs to be public documented in a RFC or some public domain site. We (as in the wide public) need to understand in-depth how P4P works, so it can be peer reviewed, everybody can have a opinion about it and not just drink from the cool-aid. Thanks, Reinaldo _______________________________________________ p2pi mailing list p2pi@ietf.org https://www.ietf.org/mailman/listinfo/p2pi From p2pi-bounces@ietf.org Sat Aug 2 19:11: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 92E123A6911; Sat, 2 Aug 2008 19:11: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 A660D3A6911 for ; Sat, 2 Aug 2008 19:11:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.254 X-Spam-Level: X-Spam-Status: No, score=-6.254 tagged_above=-999 required=5 tests=[AWL=0.345, 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 S9dTm4l8LYRV for ; Sat, 2 Aug 2008 19:11:08 -0700 (PDT) Received: from exprod7og112.obsmtp.com (exprod7og112.obsmtp.com [64.18.2.177]) by core3.amsl.com (Postfix) with ESMTP id 1772E3A688B for ; Sat, 2 Aug 2008 19:11:07 -0700 (PDT) Received: from source ([66.129.228.6]) by exprod7ob112.postini.com ([64.18.6.12]) with SMTP; Sat, 02 Aug 2008 19:10:51 PDT Received: from p-emlb02-sac.jnpr.net ([66.129.254.47]) by p-emsmtp02.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Sat, 2 Aug 2008 19:10:17 -0700 Received: from antipi.jnpr.net ([10.10.2.34]) by p-emlb02-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Sat, 2 Aug 2008 19:10:16 -0700 Received: from proton.jnpr.net ([10.10.2.37]) by antipi.jnpr.net with Microsoft SMTPSVC(6.0.3790.1830); Sat, 2 Aug 2008 22:10:15 -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 ; Sun, 3 Aug 2008 02:10:14 +0000 User-Agent: Microsoft-Entourage/12.11.0.080522 Date: Sat, 02 Aug 2008 19:10:11 -0700 From: Reinaldo Penno To: Richard Alimi Message-ID: Thread-Topic: [p2pi] ALTO service privacy, performance, and architecture Thread-Index: Acj1Dg7/4nMt8k0pLk+s9LXRPmR7gA== In-Reply-To: <200808022111.48738.richard.alimi@yale.edu> Mime-version: 1.0 X-OriginalArrivalTime: 03 Aug 2008 02:10:15.0343 (UTC) FILETIME=[1195B3F0:01C8F50E] Cc: p2pi@ietf.org Subject: Re: [p2pi] ALTO service privacy, performance, and architecture X-BeenThere: p2pi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: P2P Infrastructure Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: 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, Thanks for your answers. Comments inline. On 8/2/08 6:11 PM, "Richard Alimi" wrote: >> I just want to remind that we are here because of file-sharing and not >> really closed P2P networks where itrackers, apptrackers and others >> cooperate nicely. This is the easy case and today does not cause problems >> to ISPs. And maybe never will. > > Let me make one clarification to your statement above. The itracker in P4P is > not application specific, and thus is not part of any closed system. It can > be queried by many P2P applications, and does not keep any swarm state. The > field tests have been done with Pando, but nothing restricts it from being > used for "public" P2P networks. > > Or did I misinterpret your meaning of "closed"? Closed as in the sense that it assumes cooperation from the AppTracker. Otherwise how can it not keep any swarm state? This is is based on the functionality from your paper. Anyway, the two statements seem contradictory. The corollary is that the content that such clients access are those of the P2P CDN and not pirated content. The P4P trials that I have heard/read are based on legal content. Please correct me if I'm wrong. > >> So, when you say "tracker-less" systems you mean a P2P network without a >> tracker (Gnutella) or a P2P network where the tracker is something like >> thepiratebay? The two 'systems' (as you put it) are quite different. > > By "tracker-less," I was referring to a P2P network without a tracker. We > consider thepiratebay a tracker-based system. > >> In the case where there is a tracker on the Internet that does not >> cooperate (which is 99.99% of P2P traffic today) I'm not sure how ALTO >> would work without the ISP tracker pushing information to the clients >> (since the clients might not send info to the tracker). > > I agree that to cover the majority of the P2P traffic, it may be mostly be > client-dependent in the beginning. > > The idea, however, is that as time goes on P2P developers and ISPs will each > realize the benefits (better performance for P2P apps, and achieve particular > network goals for ISPs) and begin support. Integration should be simple > enough that P2P developers understand and use it. It is not P2P developers that need to be convinced. It is the users, the human factor. And if ALTO does not "get it" that it is not just about having a client-server protocol, I'm not sure of the benefits. Yeah, Pando or Joost users can be convinced of using it, but how about the other users that are responsible for 99.9% of traffic? And if they cannot be convinced, can ALTO still do some form of optimization? This goes back to security and privacy. > >> For private trackers (which have the really hardcore users) it is not clear >> how ALTO can influence their behavior since the whole point is to stay >> within the private tracker's given peers. If we cannot tackle these two >> scenarios, ISPs continue to suffer. > > Interesting point. If there are limited peers in a swarm, then there are > limited opportunities for optimization (both for the P2P and ISP side). Is > this a fundamental limit, though? Aside, of course, from "telling" them that > their swarms should be larger :) Well, peers driven by private trackers are the elite. They do not really need a big swarm since these are folks that have their computers on 24x7 and have Seedboxes. Most of the time they have co-location boxes and/or pay enterprise fees to have tons of bandwidth. > > Getting adoption in major public P2P clients/trackers is certainly important > in order for this to make a large difference for ISP networks. I believe, as I said before, that we need to convince users. The only way to convince such users is if we have a tight (very tight) security, privacy model. Otherwise the ALTO protocol might not see use in the wild. As far as convincing public trackers also means convincing the ISP to have a relationship with such trackers as thepiratebay. Does Comcast or BT want to have such relationship? I have no idea. I guess my point is that the business/realities of P2P networks should drive the requirements so we can work with (or around them). Thanks, Reinaldo _______________________________________________ p2pi mailing list p2pi@ietf.org https://www.ietf.org/mailman/listinfo/p2pi From p2pi-bounces@ietf.org Sat Aug 2 19:27: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 45F173A6804; Sat, 2 Aug 2008 19:27: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 6334F3A6804 for ; Sat, 2 Aug 2008 19:27:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.209 X-Spam-Level: X-Spam-Status: No, score=-10.209 tagged_above=-999 required=5 tests=[AWL=0.056, 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 Ao6d8znNMX-c for ; Sat, 2 Aug 2008 19:27:17 -0700 (PDT) Received: from dkny.pando.com (dkny.pando.com [67.99.55.163]) by core3.amsl.com (Postfix) with ESMTP id 3C0A83A67DA for ; Sat, 2 Aug 2008 19:27:17 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by dkny.pando.com (Postfix) with ESMTP id 5B942E10B6C; Sat, 2 Aug 2008 22:27:41 -0400 (EDT) X-Virus-Scanned: amavisd-new at Received: from dkny.pando.com ([127.0.0.1]) by localhost (dkny.pando.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZtSDvnlIHfkK; Sat, 2 Aug 2008 22:27:31 -0400 (EDT) Received: from dkny.pando.com (dkny.pando.com [10.10.60.11]) by dkny.pando.com (Postfix) with ESMTP id 0FC93E10B94; Sat, 2 Aug 2008 22:27:31 -0400 (EDT) Date: Sat, 2 Aug 2008 22:27:31 -0400 (EDT) From: Laird Popkin To: Richard Alimi Message-ID: <920066937.98581217730451031.JavaMail.root@dkny.pando.com> In-Reply-To: <912815859.98561217730083143.JavaMail.root@dkny.pando.com> MIME-Version: 1.0 X-Originating-IP: [71.187.207.81] Cc: p2pi@ietf.org Subject: Re: [p2pi] ALTO service privacy, performance, and architecture X-BeenThere: p2pi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: P2P Infrastructure Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: p2pi-bounces@ietf.org Errors-To: p2pi-bounces@ietf.org I'm a little confused about closed/open distinction, and the statement that "the whole point is to stay within the private tracker's given peers". All swarm delivery networks that I'm familiar with perform data exchanges only between peers that have the same content, which are coordinated by the same Tracker (or DHT, etc.), so all swarms contain only "the private tracker's given peers". Neither P4P nor ALTO change this. Or am I missing something? Localizing traffic only has an impact if the swarm is large enough that there are likely to be "nearby peers", and if the time that it would take a peer to explore the entire swarm is worth saving. If a swarm only has ten peers globally, there's no benefit in attempting to localize traffic, because the p2p network will connect to and use all ten peers quite rapidly no matter what P4P/ALTO says. But if there is a large swarm and there are even a few peers near a new downloader (e.g. same or nearby ISP), there's good opportunity to optimize transit. For example, we found that if a FTTH user finds even one FTTH peer, their download speeds were much, much better than if they downloaded only from random users on the internet, so the value of optimizing connections between even a few FTTH users was quite high. - Laird Popkin, CTO, Pando Networks mobile: 646/465-0570 ----- Original Message ----- From: "Richard Alimi" To: "Reinaldo Penno" Cc: p2pi@ietf.org Sent: Saturday, August 2, 2008 9:11:48 PM (GMT-0500) America/New_York Subject: Re: [p2pi] ALTO service privacy, performance, and architecture > I just want to remind that we are here because of file-sharing and not > really closed P2P networks where itrackers, apptrackers and others > cooperate nicely. This is the easy case and today does not cause problems > to ISPs. And maybe never will. Let me make one clarification to your statement above. The itracker in P4P is not application specific, and thus is not part of any closed system. It can be queried by many P2P applications, and does not keep any swarm state. The field tests have been done with Pando, but nothing restricts it from being used for "public" P2P networks. Or did I misinterpret your meaning of "closed"? > So, when you say "tracker-less" systems you mean a P2P network without a > tracker (Gnutella) or a P2P network where the tracker is something like > thepiratebay? The two 'systems' (as you put it) are quite different. By "tracker-less," I was referring to a P2P network without a tracker. We consider thepiratebay a tracker-based system. > In the case where there is a tracker on the Internet that does not > cooperate (which is 99.99% of P2P traffic today) I'm not sure how ALTO > would work without the ISP tracker pushing information to the clients > (since the clients might not send info to the tracker). I agree that to cover the majority of the P2P traffic, it may be mostly be client-dependent in the beginning. The idea, however, is that as time goes on P2P developers and ISPs will each realize the benefits (better performance for P2P apps, and achieve particular network goals for ISPs) and begin support. Integration should be simple enough that P2P developers understand and use it. > For private trackers (which have the really hardcore users) it is not clear > how ALTO can influence their behavior since the whole point is to stay > within the private tracker's given peers. If we cannot tackle these two > scenarios, ISPs continue to suffer. Interesting point. If there are limited peers in a swarm, then there are limited opportunities for optimization (both for the P2P and ISP side). Is this a fundamental limit, though? Aside, of course, from "telling" them that their swarms should be larger :) Getting adoption in major public P2P clients/trackers is certainly important in order for this to make a large difference for ISP networks. -- Richard Alimi Department of Computer Science Yale University _______________________________________________ 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 Aug 2 19:29: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 98C473A68C6; Sat, 2 Aug 2008 19:29: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 BBF383A68C5 for ; Sat, 2 Aug 2008 19:29:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QfjQX-+FOQRy for ; Sat, 2 Aug 2008 19:29:07 -0700 (PDT) Received: from netra.cs.yale.edu (netra.cs.yale.edu [128.36.229.21]) by core3.amsl.com (Postfix) with ESMTP id 96C553A6804 for ; Sat, 2 Aug 2008 19:29:07 -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 B5DCA4094C0; Sat, 2 Aug 2008 22:29:28 -0400 (EDT) Date: Sat, 2 Aug 2008 22:29:28 -0400 (EDT) From: "Y. R. Yang" To: Laird Popkin In-Reply-To: <823639194.98531217728949588.JavaMail.root@dkny.pando.com> Message-ID: References: <823639194.98531217728949588.JavaMail.root@dkny.pando.com> MIME-Version: 1.0 Cc: p2pi@ietf.org Subject: Re: [p2pi] Is P4P protocol public domain so its functionality can be reviewed? X-BeenThere: p2pi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: P2P Infrastructure Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: p2pi-bounces@ietf.org Errors-To: p2pi-bounces@ietf.org To add on to Laird's email, let me also first personally apologize for keeping on referring to the P4P features. The intention certainly was not to claim others' suggestions or to exlcude anyone. The intention was more to compare with what we are doing. I will be more careful. The P4P WG is an open group to promote collaboration on an important subject. Its membership has no cost. Yale has intentionally tried to not file any IP claim on any part of P4P. To clarify, we are working on to release the system to the public domain. I am coordinating the research subgroup of P4P WG (or call it ISP/P2P cooperation WG for those thinking P4P as a single protocol) and will definitely appreciate more participants. The P4P WG meeting next Tuesday (August 5) will be a good chance for people who are interested to call in, and to know more. I agree with Laird that P4P is not intended to be a protocol candidate. The Yale team is from academia and thus focuses more on the research side. We have no man power to specify protocols, but will be more than happy to contribute and share our experiences. Cheers, Richard On Sat, 2 Aug 2008, 10:02pm -0400, Laird Popkin wrote: > I'm sorry that it's frustrating that the P4P Working Group participants > keep answering in that way, but IMO it's a natural outcome of the > situation; the P4P Working Group has been working in this area for a > year, so anyone coming into the topic is likely to suggest things or > raise issues that have already been thought of within the group. The > responses aren't meant to make anyone feel excluded, though I can see > how it might come across that way. > > I agree that publishing more information on the P4P work would help. In > addition to Yale's publications, there have been writeups (e.g. > http://www.openp4p.net/ that provides an overview, > http://www.pandoblog.com/?p=261 that talks about Pando's experiences > implementing P4P). I believe that there have been other papers > submitted, but which aren't yet published. We should have results from > the second round of testing shortly (i.e. ISPs are reviewing the results > now, and have to decide what they're comfortable releasing). > > The goal of the tests so far wasn't particularly to generate the perfect > protocol and implementation, but to perform real-world testing across > multiple ISPs to quantify the impact of localizing traffic on various > kinds of ISPs (retail, wholesale, DSL, cable, fiber), and to experiment > with a variety of optimization strategies. Our assumption has been that > the actual protocol used to enable that optimization will change. The > field tests have triggered significant evolutions in the protocol, and > will probably continue to do so. And assuming that the ALTO WG is > formed, I'm sure that what it comes up with will not be simply an > adoption of the P4P work so far. > > To elaborate on Richard's answer, the P4P protocol is currently only > published within the P4P Working Group, which is open to interested > parties (with no cost). The idea of limiting access is to allow for > rapid evolution early in the process - the intention is that as we work > through field tests the protocol and code will mature to the point where > they will be suitable to be shared to the public. I think that we're > getting pretty close - Yale is working on approvals, etc. Until then, > there's no cost to participating in the P4P WG, so I'd encourage that. > > I should clarify that I don't view P4P as a "protocol candidate" at this > point, just an example of the kind of optimization that can be provided > by ALTO.. > > - Laird Popkin, CTO, Pando Networks > mobile: 646/465-0570 > > ----- Original Message ----- > From: "Reinaldo Penno" > To: p2pi@ietf.org, "Laird Popkin" > Sent: Saturday, August 2, 2008 6:10:52 PM (GMT-0500) America/New_York > Subject: Is P4P protocol public domain so its functionality can be reviewed? > > Is the P4P protocol public domain? I'm saying this because every time > somebody suggests a different approach the answer is invariably > > "P4P can do this" or "we in P4P were _just_ thinking about this". > > Any protocol candidate to IETF standardization needs to be public documented > in a RFC or some public domain site. We (as in the wide public) need to > understand in-depth how P4P works, so it can be peer reviewed, everybody can > have a opinion about it and not just drink from the cool-aid. > > Thanks, > > Reinaldo > > > > > > _______________________________________________ > 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 Aug 2 19:35: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 1BA4E3A6896; Sat, 2 Aug 2008 19:35: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 1B21B3A6911 for ; Sat, 2 Aug 2008 19:35:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.215 X-Spam-Level: X-Spam-Status: No, score=-10.215 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, HABEAS_ACCREDITED_COI=-8, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YAdK-jrvrjoM for ; Sat, 2 Aug 2008 19:35:35 -0700 (PDT) Received: from dkny.pando.com (dkny.pando.com [67.99.55.163]) by core3.amsl.com (Postfix) with ESMTP id D61A63A67F4 for ; Sat, 2 Aug 2008 19:35:34 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by dkny.pando.com (Postfix) with ESMTP id E3B4AE10B8D; Sat, 2 Aug 2008 22:35:58 -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 4+WYUTJShc+k; Sat, 2 Aug 2008 22:35:47 -0400 (EDT) Received: from dkny.pando.com (dkny.pando.com [10.10.60.11]) by dkny.pando.com (Postfix) with ESMTP id 87993E10B6C; Sat, 2 Aug 2008 22:35:47 -0400 (EDT) Date: Sat, 2 Aug 2008 22:35:47 -0400 (EDT) From: Laird Popkin To: Reinaldo Penno Message-ID: <53674106.98611217730947529.JavaMail.root@dkny.pando.com> In-Reply-To: MIME-Version: 1.0 X-Originating-IP: [71.187.207.81] Cc: p2pi@ietf.org Subject: Re: [p2pi] ALTO service privacy, performance, and architecture X-BeenThere: p2pi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: P2P Infrastructure Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: 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 P4P tests that were performed so far were performed with legal content so that we could focus on technical issues (e.g. implementing and running the tests) and not get caught in potentially lengthy policy discussions that (IMO) are only worth having once the technology demonstrates its value. The test results have been very good, so I suspect that the policy discussions will start taking place. There's no technical issue limiting who uses P4P (and, I hope, ALTO). Given this, I believe that each ISP can decide its own policies regarding who it wants to share what information with. Keep in mind that ALTO servers can be run by entities other than ISPs. So if ISPs don't want to work with pirate trackers, the pirate trackers might join together to set up an ALTO server populated using whatever network information they can collect or determine (e.g. ASN adjacency maps) to improve performance for their users. Finally, ALTO servers should be accessible by either clients or servers, so it may be the case that even if ISPs don't want to work with pirate trackers, they might approve working with user p2p clients, which would achieve a similar result. - Laird Popkin, CTO, Pando Networks mobile: 646/465-0570 ----- Original Message ----- From: "Reinaldo Penno" To: "Richard Alimi" Cc: p2pi@ietf.org Sent: Saturday, August 2, 2008 10:10:11 PM (GMT-0500) America/New_York Subject: Re: [p2pi] ALTO service privacy, performance, and architecture Hi, Thanks for your answers. Comments inline. On 8/2/08 6:11 PM, "Richard Alimi" wrote: >> I just want to remind that we are here because of file-sharing and not >> really closed P2P networks where itrackers, apptrackers and others >> cooperate nicely. This is the easy case and today does not cause problems >> to ISPs. And maybe never will. > > Let me make one clarification to your statement above. The itracker in P4P is > not application specific, and thus is not part of any closed system. It can > be queried by many P2P applications, and does not keep any swarm state. The > field tests have been done with Pando, but nothing restricts it from being > used for "public" P2P networks. > > Or did I misinterpret your meaning of "closed"? Closed as in the sense that it assumes cooperation from the AppTracker. Otherwise how can it not keep any swarm state? This is is based on the functionality from your paper. Anyway, the two statements seem contradictory. The corollary is that the content that such clients access are those of the P2P CDN and not pirated content. The P4P trials that I have heard/read are based on legal content. Please correct me if I'm wrong. > >> So, when you say "tracker-less" systems you mean a P2P network without a >> tracker (Gnutella) or a P2P network where the tracker is something like >> thepiratebay? The two 'systems' (as you put it) are quite different. > > By "tracker-less," I was referring to a P2P network without a tracker. We > consider thepiratebay a tracker-based system. > >> In the case where there is a tracker on the Internet that does not >> cooperate (which is 99.99% of P2P traffic today) I'm not sure how ALTO >> would work without the ISP tracker pushing information to the clients >> (since the clients might not send info to the tracker). > > I agree that to cover the majority of the P2P traffic, it may be mostly be > client-dependent in the beginning. > > The idea, however, is that as time goes on P2P developers and ISPs will each > realize the benefits (better performance for P2P apps, and achieve particular > network goals for ISPs) and begin support. Integration should be simple > enough that P2P developers understand and use it. It is not P2P developers that need to be convinced. It is the users, the human factor. And if ALTO does not "get it" that it is not just about having a client-server protocol, I'm not sure of the benefits. Yeah, Pando or Joost users can be convinced of using it, but how about the other users that are responsible for 99.9% of traffic? And if they cannot be convinced, can ALTO still do some form of optimization? This goes back to security and privacy. > >> For private trackers (which have the really hardcore users) it is not clear >> how ALTO can influence their behavior since the whole point is to stay >> within the private tracker's given peers. If we cannot tackle these two >> scenarios, ISPs continue to suffer. > > Interesting point. If there are limited peers in a swarm, then there are > limited opportunities for optimization (both for the P2P and ISP side). Is > this a fundamental limit, though? Aside, of course, from "telling" them that > their swarms should be larger :) Well, peers driven by private trackers are the elite. They do not really need a big swarm since these are folks that have their computers on 24x7 and have Seedboxes. Most of the time they have co-location boxes and/or pay enterprise fees to have tons of bandwidth. > > Getting adoption in major public P2P clients/trackers is certainly important > in order for this to make a large difference for ISP networks. I believe, as I said before, that we need to convince users. The only way to convince such users is if we have a tight (very tight) security, privacy model. Otherwise the ALTO protocol might not see use in the wild. As far as convincing public trackers also means convincing the ISP to have a relationship with such trackers as thepiratebay. Does Comcast or BT want to have such relationship? I have no idea. I guess my point is that the business/realities of P2P networks should drive the requirements so we can work with (or around them). Thanks, Reinaldo _______________________________________________ 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 Aug 2 19:41: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 18A713A685B; Sat, 2 Aug 2008 19:41: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 6EDE63A6869 for ; Sat, 2 Aug 2008 19:41:36 -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 PsOvEoRIthnV for ; Sat, 2 Aug 2008 19:41:31 -0700 (PDT) Received: from QMTA01.westchester.pa.mail.comcast.net (qmta01.westchester.pa.mail.comcast.net [76.96.62.16]) by core3.amsl.com (Postfix) with ESMTP id 854063A6886 for ; Sat, 2 Aug 2008 19:40:33 -0700 (PDT) Received: from OMTA05.westchester.pa.mail.comcast.net ([76.96.62.43]) by QMTA01.westchester.pa.mail.comcast.net with comcast id xPAT1Z00B0vyq2s51egh7o; Sun, 03 Aug 2008 02:40:41 +0000 Received: from poweredge.velvetsea.net ([76.182.22.132]) by OMTA05.westchester.pa.mail.comcast.net with comcast id xegP1Z00G2qze2s3RegXsr; Sun, 03 Aug 2008 02:40:52 +0000 X-Authority-Analysis: v=1.0 c=1 a=HQ6x2VH6PSwA:10 a=Mr5i1LQ58koA:10 a=7uQqsCkx1bkv4dNIIZoA:9 a=cFlncvZD4XY1j8o6MRUA:7 a=kLtAL01_kz8eYJ47gIkZlNwBLI0A:4 a=MxZ3bB5I4kYA:10 Received: from desktop.velvetsea.net (desktop.velvetsea.net [192.168.1.4]) by poweredge.velvetsea.net (Postfix) with ESMTP id 95B37424001; Sat, 2 Aug 2008 22:40:23 -0400 (EDT) From: Richard Alimi To: Reinaldo Penno Date: Sat, 2 Aug 2008 22:40:23 -0400 User-Agent: KMail/1.10.0 (Linux/2.6.24.4; KDE/4.1.1; i686; ; ) References: In-Reply-To: MIME-Version: 1.0 Content-Disposition: inline Message-Id: <200808022240.23300.richard.alimi@yale.edu> Cc: p2pi@ietf.org Subject: Re: [p2pi] ALTO service privacy, performance, and architecture X-BeenThere: p2pi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: P2P Infrastructure Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: p2pi-bounces@ietf.org Errors-To: p2pi-bounces@ietf.org > > Let me make one clarification to your statement above. The itracker in > > P4P is not application specific, and thus is not part of any closed > > system. It can be queried by many P2P applications, and does not keep > > any swarm state. The field tests have been done with Pando, but nothing > > restricts it from being used for "public" P2P networks. > > > > Or did I misinterpret your meaning of "closed"? > > Closed as in the sense that it assumes cooperation from the AppTracker. > Otherwise how can it not keep any swarm state? This is is based on the > functionality from your paper. In the paper, you're right that the primal-dual decomposition and the supergradient tending towards the optimal network state depends on both code implemented in the iTracker and the application tracker. However, as we've pointed out, this is not the only way the costs distributed by the tracker need to be used - it is just one example. Other algorithms implemented at either side may not relate to a particular problem formulation, but nonetheless the ISP preferences can still be conveyed and followed. > Anyway, the two statements seem contradictory. The corollary is that the > content that such clients access are those of the P2P CDN and not pirated > content. The P4P trials that I have heard/read are based on legal content. > Please correct me if I'm wrong. You are right - the trials have used legal content, but there is nothing in the system that prevents it being used by other trackers. > > I agree that to cover the majority of the P2P traffic, it may be mostly > > be client-dependent in the beginning. > > > > The idea, however, is that as time goes on P2P developers and ISPs will > > each realize the benefits (better performance for P2P apps, and achieve > > particular network goals for ISPs) and begin support. Integration should > > be simple enough that P2P developers understand and use it. > > It is not P2P developers that need to be convinced. It is the users, the > human factor. > > And if ALTO does not "get it" that it is not just about having a > client-server protocol, I'm not sure of the benefits. Yeah, Pando or Joost > users can be convinced of using it, but how about the other users that are > responsible for 99.9% of traffic? And if they cannot be convinced, can ALTO > still do some form of optimization? This goes back to security and privacy. In the end, the users are not the ones using the provided information, it is the P2P software on their desktops/laptops. As a P2P user, is there any more involvement I have beyond downloading an ALTO-enabled client or connecting to an ALTO-enabled tracker, and possibly changing a few configuration options to enable/disable ALTO or tune how my client uses the recommendations? Yes, users may ask the P2P developer for support, but for word to spread amongst users they'll have to see their friends using ALTO-enabled P2P clients/trackers. If integration is particularly hard, it seems that this adoption will be very difficult to bootstrap and eventually integrate into the large number of P2P client/tracker implementations out there. > > Getting adoption in major public P2P clients/trackers is certainly > > important in order for this to make a large difference for ISP networks. > > I believe, as I said before, that we need to convince users. The only way > to convince such users is if we have a tight (very tight) security, privacy > model. Otherwise the ALTO protocol might not see use in the wild. See above - you're right that security/privacy is an important issue for the P2P users and is important for adoption. > As far as convincing public trackers also means convincing the ISP to have > a relationship with such trackers as thepiratebay. Does Comcast or BT want > to have such relationship? I have no idea. I guess my point is that the > business/realities of P2P networks should drive the requirements so we can > work with (or around them). Are you referring to a business relationship, or a "I won't prevent you from connecting to me" relationship? I don't think any business relationship is required, but I can't comment on the second interpretation. -- Richard Alimi Department of Computer Science Yale University _______________________________________________ p2pi mailing list p2pi@ietf.org https://www.ietf.org/mailman/listinfo/p2pi From p2pi-bounces@ietf.org Sat Aug 2 19:42: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 CC4243A6853; Sat, 2 Aug 2008 19:42: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 0D2883A6869 for ; Sat, 2 Aug 2008 19:42:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.444 X-Spam-Level: X-Spam-Status: No, score=-2.444 tagged_above=-999 required=5 tests=[AWL=0.155, 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 TLFPefrsk2Yj for ; Sat, 2 Aug 2008 19:42:53 -0700 (PDT) Received: from wf-out-1314.google.com (wf-out-1314.google.com [209.85.200.169]) by core3.amsl.com (Postfix) with ESMTP id 574273A6853 for ; Sat, 2 Aug 2008 19:42:53 -0700 (PDT) Received: by wf-out-1314.google.com with SMTP id 27so1497216wfd.31 for ; Sat, 02 Aug 2008 19:43:17 -0700 (PDT) Received: by 10.142.154.20 with SMTP id b20mr4379145wfe.99.1217731397689; Sat, 02 Aug 2008 19:43:17 -0700 (PDT) Received: from ?192.168.1.103? ( [67.188.243.194]) by mx.google.com with ESMTPS id 30sm4778882wfa.10.2008.08.02.19.43.16 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sat, 02 Aug 2008 19:43:17 -0700 (PDT) Message-Id: From: Stanislav Shalunov To: Laird Popkin In-Reply-To: <823639194.98531217728949588.JavaMail.root@dkny.pando.com> Mime-Version: 1.0 (Apple Message framework v926) Date: Sat, 2 Aug 2008 19:43:14 -0700 References: <823639194.98531217728949588.JavaMail.root@dkny.pando.com> X-Mailer: Apple Mail (2.926) Cc: p2pi@ietf.org Subject: Re: [p2pi] Is P4P protocol public domain so its functionality can be reviewed? X-BeenThere: p2pi@ietf.org 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 Aug 2, 2008, at 7:02 PM, Laird Popkin wrote: > I should clarify that I don't view P4P as a "protocol candidate" at > this point, just an example of the kind of optimization that can be > provided by ALTO.. This is a useful and productive approach. -- Stanislav Shalunov _______________________________________________ p2pi mailing list p2pi@ietf.org https://www.ietf.org/mailman/listinfo/p2pi From p2pi-bounces@ietf.org Sat Aug 2 19:59: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 A88993A6891; Sat, 2 Aug 2008 19:59: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 0DBF03A6891 for ; Sat, 2 Aug 2008 19:59:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.292 X-Spam-Level: X-Spam-Status: No, score=-6.292 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 FiITzwj7egED for ; Sat, 2 Aug 2008 19:59:12 -0700 (PDT) Received: from exprod7og103.obsmtp.com (exprod7og103.obsmtp.com [64.18.2.159]) by core3.amsl.com (Postfix) with ESMTP id 35E8F3A6886 for ; Sat, 2 Aug 2008 19:59:11 -0700 (PDT) Received: from source ([66.129.228.6]) by exprod7ob103.postini.com ([64.18.6.12]) with SMTP; Sat, 02 Aug 2008 19:59:33 PDT Received: from p-emlb02-sac.jnpr.net ([66.129.254.47]) by p-emsmtp01.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Sat, 2 Aug 2008 19:58:50 -0700 Received: from emailwf1.jnpr.net ([10.10.2.33]) by p-emlb02-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Sat, 2 Aug 2008 19:58:50 -0700 Received: from proton.jnpr.net ([10.10.2.37]) by emailwf1.jnpr.net with Microsoft SMTPSVC(6.0.3790.1830); Sat, 2 Aug 2008 22:58:49 -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 ; Sun, 3 Aug 2008 02:58:48 +0000 User-Agent: Microsoft-Entourage/12.11.0.080522 Date: Sat, 02 Aug 2008 19:58:44 -0700 From: Reinaldo Penno To: Laird Popkin Message-ID: Thread-Topic: [p2pi] ALTO service privacy, performance, and architecture Thread-Index: Acj1FNdHstgfItlftkCyIrzt+feoGg== In-Reply-To: <53674106.98611217730947529.JavaMail.root@dkny.pando.com> Mime-version: 1.0 X-OriginalArrivalTime: 03 Aug 2008 02:58:49.0044 (UTC) FILETIME=[DA493140:01C8F514] Cc: p2pi@ietf.org Subject: Re: [p2pi] ALTO service privacy, performance, and architecture X-BeenThere: p2pi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: P2P Infrastructure Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: 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 8/2/08 7:35 PM, "Laird Popkin" wrote: > The P4P tests that were performed so far were performed with legal content so > that we could focus on technical issues (e.g. implementing and running the > tests) and not get caught in potentially lengthy policy discussions that (IMO) > are only worth having once the technology demonstrates its value. The test > results have been very good, so I suspect that the policy discussions will > start taking place. There's no technical issue limiting who uses P4P (and, I > hope, ALTO). Given this, I believe that each ISP can decide its own policies > regarding who it wants to share what information with. Understood. > > Keep in mind that ALTO servers can be run by entities other than ISPs. So if > ISPs don't want to work with pirate trackers, the pirate trackers might join > together to set up an ALTO server populated using whatever network information > they can collect or determine (e.g. ASN adjacency maps) to improve performance > for their users. And the motivation for pirate trackers would be? There is no business relationship between P2P clients and their public trackers. Improve performance seems slim. Clients can potentially improve their own performance by choosing closer peers based on IP addresses. > > Finally, ALTO servers should be accessible by either clients or servers, so it > may be the case that even if ISPs don't want to work with pirate trackers, > they might approve working with user p2p clients, which would achieve a > similar result. The latter requires a leap of faith. That's where I think we have different opinions. I think we need to make sure P2P users are on-board. BTW, by P2P clients you mean the P2P software or P2P users? Thanks, Reinaldo > > - Laird Popkin, CTO, Pando Networks > mobile: 646/465-0570 > > ----- Original Message ----- > From: "Reinaldo Penno" > To: "Richard Alimi" > Cc: p2pi@ietf.org > Sent: Saturday, August 2, 2008 10:10:11 PM (GMT-0500) America/New_York > Subject: Re: [p2pi] ALTO service privacy, performance, and architecture > > Hi, > > Thanks for your answers. Comments inline. > > On 8/2/08 6:11 PM, "Richard Alimi" wrote: > >>> I just want to remind that we are here because of file-sharing and not >>> really closed P2P networks where itrackers, apptrackers and others >>> cooperate nicely. This is the easy case and today does not cause problems >>> to ISPs. And maybe never will. >> >> Let me make one clarification to your statement above. The itracker in P4P >> is >> not application specific, and thus is not part of any closed system. It can >> be queried by many P2P applications, and does not keep any swarm state. The >> field tests have been done with Pando, but nothing restricts it from being >> used for "public" P2P networks. >> >> Or did I misinterpret your meaning of "closed"? > > Closed as in the sense that it assumes cooperation from the AppTracker. > Otherwise how can it not keep any swarm state? This is is based on the > functionality from your paper. > > Anyway, the two statements seem contradictory. The corollary is that the > content that such clients access are those of the P2P CDN and not pirated > content. The P4P trials that I have heard/read are based on legal content. > Please correct me if I'm wrong. > >> >>> So, when you say "tracker-less" systems you mean a P2P network without a >>> tracker (Gnutella) or a P2P network where the tracker is something like >>> thepiratebay? The two 'systems' (as you put it) are quite different. >> >> By "tracker-less," I was referring to a P2P network without a tracker. We >> consider thepiratebay a tracker-based system. >> >>> In the case where there is a tracker on the Internet that does not >>> cooperate (which is 99.99% of P2P traffic today) I'm not sure how ALTO >>> would work without the ISP tracker pushing information to the clients >>> (since the clients might not send info to the tracker). >> >> I agree that to cover the majority of the P2P traffic, it may be mostly be >> client-dependent in the beginning. >> >> The idea, however, is that as time goes on P2P developers and ISPs will each >> realize the benefits (better performance for P2P apps, and achieve particular >> network goals for ISPs) and begin support. Integration should be simple >> enough that P2P developers understand and use it. > > It is not P2P developers that need to be convinced. It is the users, the > human factor. > > And if ALTO does not "get it" that it is not just about having a > client-server protocol, I'm not sure of the benefits. Yeah, Pando or Joost > users can be convinced of using it, but how about the other users that are > responsible for 99.9% of traffic? And if they cannot be convinced, can ALTO > still do some form of optimization? This goes back to security and privacy. > >> >>> For private trackers (which have the really hardcore users) it is not clear >>> how ALTO can influence their behavior since the whole point is to stay >>> within the private tracker's given peers. If we cannot tackle these two >>> scenarios, ISPs continue to suffer. >> >> Interesting point. If there are limited peers in a swarm, then there are >> limited opportunities for optimization (both for the P2P and ISP side). Is >> this a fundamental limit, though? Aside, of course, from "telling" them that >> their swarms should be larger :) > > Well, peers driven by private trackers are the elite. They do not really > need a big swarm since these are folks that have their computers on 24x7 and > have Seedboxes. Most of the time they have co-location boxes and/or pay > enterprise fees to have tons of bandwidth. > >> >> Getting adoption in major public P2P clients/trackers is certainly important >> in order for this to make a large difference for ISP networks. > > I believe, as I said before, that we need to convince users. The only way to > convince such users is if we have a tight (very tight) security, privacy > model. Otherwise the ALTO protocol might not see use in the wild. > > As far as convincing public trackers also means convincing the ISP to have a > relationship with such trackers as thepiratebay. Does Comcast or BT want to > have such relationship? I have no idea. I guess my point is that the > business/realities of P2P networks should drive the requirements so we can > work with (or around them). > > Thanks, > > Reinaldo > > > _______________________________________________ > 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 Aug 2 20:03: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 11EB93A68AB; Sat, 2 Aug 2008 20:03: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 B77EF3A68AB for ; Sat, 2 Aug 2008 20:03:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.323 X-Spam-Level: X-Spam-Status: No, score=-6.323 tagged_above=-999 required=5 tests=[AWL=0.276, 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 ezrUuviAdEBx for ; Sat, 2 Aug 2008 20:03:55 -0700 (PDT) Received: from exprod7og107.obsmtp.com (exprod7og107.obsmtp.com [64.18.2.167]) by core3.amsl.com (Postfix) with ESMTP id B97983A6891 for ; Sat, 2 Aug 2008 20:03:54 -0700 (PDT) Received: from source ([66.129.228.6]) by exprod7ob107.postini.com ([64.18.6.12]) with SMTP; Sat, 02 Aug 2008 20:04:16 PDT Received: from p-emlb02-sac.jnpr.net ([66.129.254.47]) by p-emsmtp02.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Sat, 2 Aug 2008 20:04:16 -0700 Received: from emailwf1.jnpr.net ([10.10.2.33]) by p-emlb02-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Sat, 2 Aug 2008 20:04:16 -0700 Received: from proton.jnpr.net ([10.10.2.37]) by emailwf1.jnpr.net with Microsoft SMTPSVC(6.0.3790.1830); Sat, 2 Aug 2008 23:04:14 -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 ; Sun, 3 Aug 2008 03:04:14 +0000 User-Agent: Microsoft-Entourage/12.11.0.080522 Date: Sat, 02 Aug 2008 20:04:10 -0700 From: Reinaldo Penno To: "Y. R. Yang" , Laird Popkin Message-ID: Thread-Topic: [p2pi] Is P4P protocol public domain so its functionality can be reviewed? Thread-Index: Acj1FZmXJnr+ovClD0Wh5xzSgdXZ7Q== In-Reply-To: Mime-version: 1.0 X-OriginalArrivalTime: 03 Aug 2008 03:04:14.0880 (UTC) FILETIME=[9C7FD200:01C8F515] Cc: p2pi@ietf.org Subject: Re: [p2pi] Is P4P protocol public domain so its functionality can be reviewed? X-BeenThere: p2pi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: P2P Infrastructure Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: p2pi-bounces@ietf.org Errors-To: p2pi-bounces@ietf.org Thanks for the candid email. I appreciate the explanation. In the IETF I can only speak on my behalf and I'm not sure P4P accepts individuals (as the IETF does). Thanks, Reinaldo On 8/2/08 7:29 PM, "Y. R. Yang" wrote: > > To add on to Laird's email, let me also first personally apologize for > keeping on referring to the P4P features. The intention certainly was not > to claim others' suggestions or to exlcude anyone. The intention was more > to compare with what we are doing. I will be more careful. > > The P4P WG is an open group to promote collaboration on an important > subject. Its membership has no cost. Yale has intentionally tried to not > file any IP claim on any part of P4P. To clarify, we are working on to > release the system to the public domain. > > I am coordinating the research subgroup of P4P WG (or call it ISP/P2P > cooperation WG for those thinking P4P as a single protocol) and will > definitely appreciate more participants. The P4P WG meeting next Tuesday > (August 5) will be a good chance for people who are interested to call in, > and to know more. > > I agree with Laird that P4P is not intended to be a protocol candidate. > The Yale team is from academia and thus focuses more on the research side. > We have no man power to specify protocols, but will be more than happy to > contribute and share our experiences. > > Cheers, > > Richard > > On Sat, 2 Aug 2008, 10:02pm -0400, Laird Popkin wrote: > >> I'm sorry that it's frustrating that the P4P Working Group participants >> keep answering in that way, but IMO it's a natural outcome of the >> situation; the P4P Working Group has been working in this area for a >> year, so anyone coming into the topic is likely to suggest things or >> raise issues that have already been thought of within the group. The >> responses aren't meant to make anyone feel excluded, though I can see >> how it might come across that way. >> >> I agree that publishing more information on the P4P work would help. In >> addition to Yale's publications, there have been writeups (e.g. >> http://www.openp4p.net/ that provides an overview, >> http://www.pandoblog.com/?p=261 that talks about Pando's experiences >> implementing P4P). I believe that there have been other papers >> submitted, but which aren't yet published. We should have results from >> the second round of testing shortly (i.e. ISPs are reviewing the results >> now, and have to decide what they're comfortable releasing). >> >> The goal of the tests so far wasn't particularly to generate the perfect >> protocol and implementation, but to perform real-world testing across >> multiple ISPs to quantify the impact of localizing traffic on various >> kinds of ISPs (retail, wholesale, DSL, cable, fiber), and to experiment >> with a variety of optimization strategies. Our assumption has been that >> the actual protocol used to enable that optimization will change. The >> field tests have triggered significant evolutions in the protocol, and >> will probably continue to do so. And assuming that the ALTO WG is >> formed, I'm sure that what it comes up with will not be simply an >> adoption of the P4P work so far. >> >> To elaborate on Richard's answer, the P4P protocol is currently only >> published within the P4P Working Group, which is open to interested >> parties (with no cost). The idea of limiting access is to allow for >> rapid evolution early in the process - the intention is that as we work >> through field tests the protocol and code will mature to the point where >> they will be suitable to be shared to the public. I think that we're >> getting pretty close - Yale is working on approvals, etc. Until then, >> there's no cost to participating in the P4P WG, so I'd encourage that. >> >> I should clarify that I don't view P4P as a "protocol candidate" at this >> point, just an example of the kind of optimization that can be provided >> by ALTO.. >> >> - Laird Popkin, CTO, Pando Networks >> mobile: 646/465-0570 >> >> ----- Original Message ----- >> From: "Reinaldo Penno" >> To: p2pi@ietf.org, "Laird Popkin" >> Sent: Saturday, August 2, 2008 6:10:52 PM (GMT-0500) America/New_York >> Subject: Is P4P protocol public domain so its functionality can be reviewed? >> >> Is the P4P protocol public domain? I'm saying this because every time >> somebody suggests a different approach the answer is invariably >> >> "P4P can do this" or "we in P4P were _just_ thinking about this". >> >> Any protocol candidate to IETF standardization needs to be public documented >> in a RFC or some public domain site. We (as in the wide public) need to >> understand in-depth how P4P works, so it can be peer reviewed, everybody can >> have a opinion about it and not just drink from the cool-aid. >> >> Thanks, >> >> Reinaldo >> >> >> >> >> >> _______________________________________________ >> 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 Aug 2 20:09:21 2008 Return-Path: X-Original-To: p2pi-archive@ietf.org Delivered-To: ietfarch-p2pi-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BE6493A696F; Sat, 2 Aug 2008 20:09:21 -0700 (PDT) X-Original-To: p2pi@core3.amsl.com Delivered-To: p2pi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2CCDB3A697B for ; Sat, 2 Aug 2008 20:09:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.459 X-Spam-Level: X-Spam-Status: No, score=-2.459 tagged_above=-999 required=5 tests=[AWL=0.140, 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 i+3CSRsd5bnJ for ; Sat, 2 Aug 2008 20:09:20 -0700 (PDT) Received: from wf-out-1314.google.com (wf-out-1314.google.com [209.85.200.169]) by core3.amsl.com (Postfix) with ESMTP id 7162D3A696F for ; Sat, 2 Aug 2008 20:09:20 -0700 (PDT) Received: by wf-out-1314.google.com with SMTP id 27so1501656wfd.31 for ; Sat, 02 Aug 2008 20:09:44 -0700 (PDT) Received: by 10.143.42.6 with SMTP id u6mr4385391wfj.140.1217732984117; Sat, 02 Aug 2008 20:09:44 -0700 (PDT) Received: from ?192.168.1.103? ( [67.188.243.194]) by mx.google.com with ESMTPS id 30sm5711151wfc.5.2008.08.02.20.09.43 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sat, 02 Aug 2008 20:09:43 -0700 (PDT) Message-Id: <2549C209-67E8-4363-998F-F82807F916CE@shlang.com> From: Stanislav Shalunov To: Richard Alimi In-Reply-To: <200808022240.23300.richard.alimi@yale.edu> Mime-Version: 1.0 (Apple Message framework v926) Date: Sat, 2 Aug 2008 20:09:42 -0700 References: <200808022240.23300.richard.alimi@yale.edu> X-Mailer: Apple Mail (2.926) Cc: p2pi@ietf.org Subject: Re: [p2pi] ALTO service privacy, performance, and architecture X-BeenThere: p2pi@ietf.org 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 Aug 2, 2008, at 7:40 PM, Richard Alimi wrote: > In the end, the users are not the ones using the provided > information, it is > the P2P software on their desktops/laptops. As a P2P user, is there > any more > involvement I have beyond downloading an ALTO-enabled client or > connecting to > an ALTO-enabled tracker, and possibly changing a few configuration > options to > enable/disable ALTO or tune how my client uses the recommendations? Most trackers will probably not support ALTO in any near future. There are about three very popular clients that really matter. I am familiar with how decisions work for the first of these clients, but I expect that any other popular client will have similar considerations, and will need to make similar changes to stay popular. Whether clients will support ALTO mainly depends on whether (1) downloads will go as fast (2) no party, particularly not the ISP, will learn more about what's going on than it does today I'm somewhat skeptical of possibility of great improvements in average download speeds. Such possibility would imply that there are vast amount of upload capacity that sit unused in a regular unwashed swarm. While there can be substantial local improvements to be made every now and then, the system clearly gives very high average uplink use fraction when comprised of decent clients. Given how thin the uplink is, it's not too hard to use it all regardless of RTT, particularly with several active connections. -- Stanislav Shalunov _______________________________________________ p2pi mailing list p2pi@ietf.org https://www.ietf.org/mailman/listinfo/p2pi From p2pi-bounces@ietf.org Sat Aug 2 20:31: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 854D33A6891; Sat, 2 Aug 2008 20:31: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 B74A83A6891 for ; Sat, 2 Aug 2008 20:31:21 -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 iH0Jfzv1NWch for ; Sat, 2 Aug 2008 20:31:20 -0700 (PDT) Received: from netra.cs.yale.edu (netra.cs.yale.edu [128.36.229.21]) by core3.amsl.com (Postfix) with ESMTP id BCE0F3A6830 for ; Sat, 2 Aug 2008 20:31:20 -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 F300D4094C0; Sat, 2 Aug 2008 23:31:37 -0400 (EDT) Date: Sat, 2 Aug 2008 23:31:37 -0400 (EDT) From: "Y. R. Yang" To: Stanislav Shalunov In-Reply-To: <2549C209-67E8-4363-998F-F82807F916CE@shlang.com> Message-ID: References: <200808022240.23300.richard.alimi@yale.edu> <2549C209-67E8-4363-998F-F82807F916CE@shlang.com> MIME-Version: 1.0 Cc: p2pi@ietf.org Subject: Re: [p2pi] ALTO service privacy, performance, and architecture X-BeenThere: p2pi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: P2P Infrastructure Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: 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 Sat, 2 Aug 2008, 8:09pm -0700, Stanislav Shalunov wrote: > On Aug 2, 2008, at 7:40 PM, Richard Alimi wrote: > >In the end, the users are not the ones using the provided information, it is > >the P2P software on their desktops/laptops. As a P2P user, is there any more > >involvement I have beyond downloading an ALTO-enabled client or connecting to > >an ALTO-enabled tracker, and possibly changing a few configuration options to > >enable/disable ALTO or tune how my client uses the recommendations? > > Most trackers will probably not support ALTO in any near future. > > There are about three very popular clients that really matter. I am > familiar with how decisions work for the first of these clients, but I > expect that any other popular client will have similar considerations, > and will need to make similar changes to stay popular. > > Whether clients will support ALTO mainly depends on whether > > (1) downloads will go as fast > (2) no party, particularly not the ISP, will learn more about what's going on > than it does today Agree. > I'm somewhat skeptical of possibility of great improvements in average > download speeds. Such possibility would imply that there are vast amount of > upload capacity that sit unused in a regular unwashed swarm. While there can > be substantial local improvements to be made every now and then, the system > clearly gives very high average uplink use fraction when comprised of decent > clients. Given how thin the uplink is, it's not too hard to use it all > regardless of RTT, particularly with several active connections. I do not know if I can release the results from the current experiment we are running. So I cannot give exact numbers. We do see improvement on download speed averaged across all ISPs. The improvement for some participating ISPs can be much larger than the global average, supporting your aforementioned that there can be substantial local improvement. The implication on ISP incentive will be an interesting issue. The key, as you pointed out, is to "download go as fast." I think this is more likely to be achievable. Richard > -- > Stanislav Shalunov > > > > _______________________________________________ > p2pi mailing list > p2pi@ietf.org > https://www.ietf.org/mailman/listinfo/p2pi > _______________________________________________ p2pi mailing list p2pi@ietf.org https://www.ietf.org/mailman/listinfo/p2pi From p2pi-bounces@ietf.org Sat Aug 2 20:42: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 1CCDE3A67DA; Sat, 2 Aug 2008 20:42: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 0EF623A6804 for ; Sat, 2 Aug 2008 20:42:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.22 X-Spam-Level: X-Spam-Status: No, score=-10.22 tagged_above=-999 required=5 tests=[AWL=0.045, 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 uXTgqbUs5kt5 for ; Sat, 2 Aug 2008 20:42:51 -0700 (PDT) Received: from dkny.pando.com (dkny.pando.com [67.99.55.163]) by core3.amsl.com (Postfix) with ESMTP id 9AC1A3A67DA for ; Sat, 2 Aug 2008 20:42:51 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by dkny.pando.com (Postfix) with ESMTP id 8003AE10B8D; Sat, 2 Aug 2008 23:43:13 -0400 (EDT) X-Virus-Scanned: amavisd-new at Received: from dkny.pando.com ([127.0.0.1]) by localhost (dkny.pando.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eiNozA87mw0i; Sat, 2 Aug 2008 23:43:05 -0400 (EDT) Received: from dkny.pando.com (dkny.pando.com [10.10.60.11]) by dkny.pando.com (Postfix) with ESMTP id 3F148E10B6C; Sat, 2 Aug 2008 23:43:05 -0400 (EDT) Date: Sat, 2 Aug 2008 23:43:05 -0400 (EDT) From: Laird Popkin To: Reinaldo Penno Message-ID: <1062841070.98701217734985233.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] Is P4P protocol public domain so its functionality can be reviewed? X-BeenThere: p2pi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: P2P Infrastructure Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: p2pi-bounces@ietf.org Errors-To: p2pi-bounces@ietf.org Individuals can join the P4P Working Group. You can contact marty@dcia.info if you're interested. - Laird Popkin, CTO, Pando Networks mobile: 646/465-0570 ----- Original Message ----- From: "Reinaldo Penno" To: "Y. R. Yang" , "Laird Popkin" Cc: p2pi@ietf.org Sent: Saturday, August 2, 2008 11:04:10 PM (GMT-0500) America/New_York Subject: Re: [p2pi] Is P4P protocol public domain so its functionality can be reviewed? Thanks for the candid email. I appreciate the explanation. In the IETF I can only speak on my behalf and I'm not sure P4P accepts individuals (as the IETF does). Thanks, Reinaldo On 8/2/08 7:29 PM, "Y. R. Yang" wrote: > > To add on to Laird's email, let me also first personally apologize for > keeping on referring to the P4P features. The intention certainly was not > to claim others' suggestions or to exlcude anyone. The intention was more > to compare with what we are doing. I will be more careful. > > The P4P WG is an open group to promote collaboration on an important > subject. Its membership has no cost. Yale has intentionally tried to not > file any IP claim on any part of P4P. To clarify, we are working on to > release the system to the public domain. > > I am coordinating the research subgroup of P4P WG (or call it ISP/P2P > cooperation WG for those thinking P4P as a single protocol) and will > definitely appreciate more participants. The P4P WG meeting next Tuesday > (August 5) will be a good chance for people who are interested to call in, > and to know more. > > I agree with Laird that P4P is not intended to be a protocol candidate. > The Yale team is from academia and thus focuses more on the research side. > We have no man power to specify protocols, but will be more than happy to > contribute and share our experiences. > > Cheers, > > Richard > > On Sat, 2 Aug 2008, 10:02pm -0400, Laird Popkin wrote: > >> I'm sorry that it's frustrating that the P4P Working Group participants >> keep answering in that way, but IMO it's a natural outcome of the >> situation; the P4P Working Group has been working in this area for a >> year, so anyone coming into the topic is likely to suggest things or >> raise issues that have already been thought of within the group. The >> responses aren't meant to make anyone feel excluded, though I can see >> how it might come across that way. >> >> I agree that publishing more information on the P4P work would help. In >> addition to Yale's publications, there have been writeups (e.g. >> http://www.openp4p.net/ that provides an overview, >> http://www.pandoblog.com/?p=261 that talks about Pando's experiences >> implementing P4P). I believe that there have been other papers >> submitted, but which aren't yet published. We should have results from >> the second round of testing shortly (i.e. ISPs are reviewing the results >> now, and have to decide what they're comfortable releasing). >> >> The goal of the tests so far wasn't particularly to generate the perfect >> protocol and implementation, but to perform real-world testing across >> multiple ISPs to quantify the impact of localizing traffic on various >> kinds of ISPs (retail, wholesale, DSL, cable, fiber), and to experiment >> with a variety of optimization strategies. Our assumption has been that >> the actual protocol used to enable that optimization will change. The >> field tests have triggered significant evolutions in the protocol, and >> will probably continue to do so. And assuming that the ALTO WG is >> formed, I'm sure that what it comes up with will not be simply an >> adoption of the P4P work so far. >> >> To elaborate on Richard's answer, the P4P protocol is currently only >> published within the P4P Working Group, which is open to interested >> parties (with no cost). The idea of limiting access is to allow for >> rapid evolution early in the process - the intention is that as we work >> through field tests the protocol and code will mature to the point where >> they will be suitable to be shared to the public. I think that we're >> getting pretty close - Yale is working on approvals, etc. Until then, >> there's no cost to participating in the P4P WG, so I'd encourage that. >> >> I should clarify that I don't view P4P as a "protocol candidate" at this >> point, just an example of the kind of optimization that can be provided >> by ALTO.. >> >> - Laird Popkin, CTO, Pando Networks >> mobile: 646/465-0570 >> >> ----- Original Message ----- >> From: "Reinaldo Penno" >> To: p2pi@ietf.org, "Laird Popkin" >> Sent: Saturday, August 2, 2008 6:10:52 PM (GMT-0500) America/New_York >> Subject: Is P4P protocol public domain so its functionality can be reviewed? >> >> Is the P4P protocol public domain? I'm saying this because every time >> somebody suggests a different approach the answer is invariably >> >> "P4P can do this" or "we in P4P were _just_ thinking about this". >> >> Any protocol candidate to IETF standardization needs to be public documented >> in a RFC or some public domain site. We (as in the wide public) need to >> understand in-depth how P4P works, so it can be peer reviewed, everybody can >> have a opinion about it and not just drink from the cool-aid. >> >> Thanks, >> >> Reinaldo >> >> >> >> >> >> _______________________________________________ >> 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 Aug 2 21:08: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 CEC5B3A6A6C; Sat, 2 Aug 2008 21:08: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 1EB273A699C for ; Sat, 2 Aug 2008 21:08:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.224 X-Spam-Level: X-Spam-Status: No, score=-10.224 tagged_above=-999 required=5 tests=[AWL=0.041, 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 wLa0crQYRatm for ; Sat, 2 Aug 2008 21:08:53 -0700 (PDT) Received: from dkny.pando.com (dkny.pando.com [67.99.55.163]) by core3.amsl.com (Postfix) with ESMTP id 972903A6A6C for ; Sat, 2 Aug 2008 21:08:53 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by dkny.pando.com (Postfix) with ESMTP id E16A2E10BA4; Sun, 3 Aug 2008 00:09: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 Mep8BkyGCd1b; Sun, 3 Aug 2008 00:09:06 -0400 (EDT) Received: from dkny.pando.com (dkny.pando.com [10.10.60.11]) by dkny.pando.com (Postfix) with ESMTP id 8A1C6E10B94; Sun, 3 Aug 2008 00:09:06 -0400 (EDT) Date: Sun, 3 Aug 2008 00:09:06 -0400 (EDT) From: Laird Popkin To: Reinaldo Penno Message-ID: <2087988022.98841217736546525.JavaMail.root@dkny.pando.com> In-Reply-To: <363298339.98791217735782199.JavaMail.root@dkny.pando.com> MIME-Version: 1.0 X-Originating-IP: [71.187.207.81] Cc: p2pi@ietf.org Subject: Re: [p2pi] ALTO service privacy, performance, and architecture X-BeenThere: p2pi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: P2P Infrastructure Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: p2pi-bounces@ietf.org Errors-To: p2pi-bounces@ietf.org I don't think that p2p users will know or care about ALTO, any more than they know or care about BGP, or HTTP proxies - things just work. ALTO will need to be known about and implemented either by the p2p trackers or clients. At most some applications might provide an ALTO check box as a preference setting, just as they might allow for manual proxy configuration. Answering the question "And the motivation for pirate trackers would be? ... Improve performance seems slim.", I believe that there are two benefits, one direct and one indirect. The direct benefit is that localizing data transfers improves download performance for users significantly on average, which makes users happier. While theoretically it shouldn't matter whether data is pulled from nearby sources or far, in practice localizing data sources appears to improve performance quite a bit. I can only guess what the cause of the improved performance is (perhaps shorter RTT's improve TCP throughput, perhaps avoiding congested internet gateways). In any case, we're seeing real world download speeds double and triple for users on fast broadband connections (nothing will speed up a slow broadband connection...). The indirect benefit is that by reducing the transit costs created by p2p traffic, it reduces the incentives for ISPs to degrade p2p traffic. "Clients can potentially improve their own performance by choosing closer peers based on IP addresses." How would they know which IP addresses are closer? ALTO? - Laird Popkin, CTO, Pando Networks mobile: 646/465-0570 ----- Original Message ----- From: "Reinaldo Penno" To: "Laird Popkin" Cc: p2pi@ietf.org, "Richard Alimi" Sent: Saturday, August 2, 2008 10:58:44 PM (GMT-0500) America/New_York Subject: Re: [p2pi] ALTO service privacy, performance, and architecture On 8/2/08 7:35 PM, "Laird Popkin" wrote: > The P4P tests that were performed so far were performed with legal content so > that we could focus on technical issues (e.g. implementing and running the > tests) and not get caught in potentially lengthy policy discussions that (IMO) > are only worth having once the technology demonstrates its value. The test > results have been very good, so I suspect that the policy discussions will > start taking place. There's no technical issue limiting who uses P4P (and, I > hope, ALTO). Given this, I believe that each ISP can decide its own policies > regarding who it wants to share what information with. Understood. > > Keep in mind that ALTO servers can be run by entities other than ISPs. So if > ISPs don't want to work with pirate trackers, the pirate trackers might join > together to set up an ALTO server populated using whatever network information > they can collect or determine (e.g. ASN adjacency maps) to improve performance > for their users. And the motivation for pirate trackers would be? There is no business relationship between P2P clients and their public trackers. Improve performance seems slim. Clients can potentially improve their own performance by choosing closer peers based on IP addresses. > > Finally, ALTO servers should be accessible by either clients or servers, so it > may be the case that even if ISPs don't want to work with pirate trackers, > they might approve working with user p2p clients, which would achieve a > similar result. The latter requires a leap of faith. That's where I think we have different opinions. I think we need to make sure P2P users are on-board. BTW, by P2P clients you mean the P2P software or P2P users? Thanks, Reinaldo > > - Laird Popkin, CTO, Pando Networks > mobile: 646/465-0570 > > ----- Original Message ----- > From: "Reinaldo Penno" > To: "Richard Alimi" > Cc: p2pi@ietf.org > Sent: Saturday, August 2, 2008 10:10:11 PM (GMT-0500) America/New_York > Subject: Re: [p2pi] ALTO service privacy, performance, and architecture > > Hi, > > Thanks for your answers. Comments inline. > > On 8/2/08 6:11 PM, "Richard Alimi" wrote: > >>> I just want to remind that we are here because of file-sharing and not >>> really closed P2P networks where itrackers, apptrackers and others >>> cooperate nicely. This is the easy case and today does not cause problems >>> to ISPs. And maybe never will. >> >> Let me make one clarification to your statement above. The itracker in P4P >> is >> not application specific, and thus is not part of any closed system. It can >> be queried by many P2P applications, and does not keep any swarm state. The >> field tests have been done with Pando, but nothing restricts it from being >> used for "public" P2P networks. >> >> Or did I misinterpret your meaning of "closed"? > > Closed as in the sense that it assumes cooperation from the AppTracker. > Otherwise how can it not keep any swarm state? This is is based on the > functionality from your paper. > > Anyway, the two statements seem contradictory. The corollary is that the > content that such clients access are those of the P2P CDN and not pirated > content. The P4P trials that I have heard/read are based on legal content. > Please correct me if I'm wrong. > >> >>> So, when you say "tracker-less" systems you mean a P2P network without a >>> tracker (Gnutella) or a P2P network where the tracker is something like >>> thepiratebay? The two 'systems' (as you put it) are quite different. >> >> By "tracker-less," I was referring to a P2P network without a tracker. We >> consider thepiratebay a tracker-based system. >> >>> In the case where there is a tracker on the Internet that does not >>> cooperate (which is 99.99% of P2P traffic today) I'm not sure how ALTO >>> would work without the ISP tracker pushing information to the clients >>> (since the clients might not send info to the tracker). >> >> I agree that to cover the majority of the P2P traffic, it may be mostly be >> client-dependent in the beginning. >> >> The idea, however, is that as time goes on P2P developers and ISPs will each >> realize the benefits (better performance for P2P apps, and achieve particular >> network goals for ISPs) and begin support. Integration should be simple >> enough that P2P developers understand and use it. > > It is not P2P developers that need to be convinced. It is the users, the > human factor. > > And if ALTO does not "get it" that it is not just about having a > client-server protocol, I'm not sure of the benefits. Yeah, Pando or Joost > users can be convinced of using it, but how about the other users that are > responsible for 99.9% of traffic? And if they cannot be convinced, can ALTO > still do some form of optimization? This goes back to security and privacy. > >> >>> For private trackers (which have the really hardcore users) it is not clear >>> how ALTO can influence their behavior since the whole point is to stay >>> within the private tracker's given peers. If we cannot tackle these two >>> scenarios, ISPs continue to suffer. >> >> Interesting point. If there are limited peers in a swarm, then there are >> limited opportunities for optimization (both for the P2P and ISP side). Is >> this a fundamental limit, though? Aside, of course, from "telling" them that >> their swarms should be larger :) > > Well, peers driven by private trackers are the elite. They do not really > need a big swarm since these are folks that have their computers on 24x7 and > have Seedboxes. Most of the time they have co-location boxes and/or pay > enterprise fees to have tons of bandwidth. > >> >> Getting adoption in major public P2P clients/trackers is certainly important >> in order for this to make a large difference for ISP networks. > > I believe, as I said before, that we need to convince users. The only way to > convince such users is if we have a tight (very tight) security, privacy > model. Otherwise the ALTO protocol might not see use in the wild. > > As far as convincing public trackers also means convincing the ISP to have a > relationship with such trackers as thepiratebay. Does Comcast or BT want to > have such relationship? I have no idea. I guess my point is that the > business/realities of P2P networks should drive the requirements so we can > work with (or around them). > > Thanks, > > Reinaldo > > > _______________________________________________ > 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 Aug 2 21:11: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 161693A6AA3; Sat, 2 Aug 2008 21:11: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 49E533A6AA3 for ; Sat, 2 Aug 2008 21:11:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.472 X-Spam-Level: X-Spam-Status: No, score=-2.472 tagged_above=-999 required=5 tests=[AWL=0.127, 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 S2lxtA9mkSoW for ; Sat, 2 Aug 2008 21:11:13 -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 872743A6A6C for ; Sat, 2 Aug 2008 21:11:13 -0700 (PDT) Received: by rv-out-0506.google.com with SMTP id b25so1380235rvf.49 for ; Sat, 02 Aug 2008 21:11:37 -0700 (PDT) Received: by 10.114.235.8 with SMTP id i8mr13299266wah.194.1217736697544; Sat, 02 Aug 2008 21:11:37 -0700 (PDT) Received: from ?192.168.1.103? ( [67.188.243.194]) by mx.google.com with ESMTPS id j39sm4501936waf.34.2008.08.02.21.11.36 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sat, 02 Aug 2008 21:11:36 -0700 (PDT) Message-Id: <3054D171-EBE8-44FA-BEA0-37A06EE7DD08@shlang.com> From: Stanislav Shalunov To: "Y. R. Yang" In-Reply-To: Mime-Version: 1.0 (Apple Message framework v926) Date: Sat, 2 Aug 2008 21:11:35 -0700 References: <200808022240.23300.richard.alimi@yale.edu> <2549C209-67E8-4363-998F-F82807F916CE@shlang.com> X-Mailer: Apple Mail (2.926) Cc: p2pi@ietf.org Subject: Re: [p2pi] ALTO service privacy, performance, and architecture X-BeenThere: p2pi@ietf.org 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 Aug 2, 2008, at 8:31 PM, Y. R. Yang wrote: > We do see improvement on > download speed averaged across all ISPs. If the average download speed across all users increases, then the total upload speed increases. This means there was room for it to increase. With good use of transport, there should not be much room. How many upload slots do you use? Is there an upload rate limit? > The improvement for some > participating ISPs can be much larger than the global average, > supporting > your aforementioned that there can be substantial local improvement. Sure. Some ISPs have faster uplinks than average, and localizing will concentrate these on other users at the same ISP. This means, though, that ISPs with slower uplinks will suffer. > The implication on ISP incentive will be an interesting issue. I'm not sure I get the connection. The ISP incentive with flat rate is lower expenses. With per-bit charges to the end-user means fewer irate users who got a huge surprise bill. Right? -- Stanislav Shalunov _______________________________________________ p2pi mailing list p2pi@ietf.org https://www.ietf.org/mailman/listinfo/p2pi From p2pi-bounces@ietf.org Sat Aug 2 21: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 610E93A6A2A; Sat, 2 Aug 2008 21: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 9F93F3A6A2A for ; Sat, 2 Aug 2008 21:15:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.977 X-Spam-Level: X-Spam-Status: No, score=-101.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id blowH6VeWgrv for ; Sat, 2 Aug 2008 21:15:02 -0700 (PDT) Received: from mu-out-0910.google.com (mu-out-0910.google.com [209.85.134.191]) by core3.amsl.com (Postfix) with ESMTP id 916DE3A6804 for ; Sat, 2 Aug 2008 21:15:02 -0700 (PDT) Received: by mu-out-0910.google.com with SMTP id g7so1405775muf.9 for ; Sat, 02 Aug 2008 21:15:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:sender :to:subject:mime-version:content-type:content-transfer-encoding :content-disposition:x-google-sender-auth; bh=grmOp5MrX8fwQbOCOElCvX3E9rBs1J9Utxq4HJ13st4=; b=AjMaCwEWllmU1wKY2+z3J/t6O/KUs2afuRGuApkusqM6E/gyVQV+AK1uyIBXw/OmNP n7915qzkxCxbr8VssqZ400pR+n56jWNIjE7GXjWiPaeTrVpht1mBKPtZNHDGqVdD2RsZ CrWQYu3AxtzpMRPxIbqzse965F3IpxfyxghpI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:sender:to:subject:mime-version:content-type :content-transfer-encoding:content-disposition:x-google-sender-auth; b=HfCdejRJJIZVQinEZVzTwLY4QU9L6fnfbp6JgAMCjWqZzi3+kzdhkTf2zLriscV5wg TJ+x91IsgBp2N+AC7Leg63/i3VQwYJAE9bpDo7Gw14/+DfDc9r5ZIOqOI17kvQ0zIKlf mLgSiiHkBehYK0+40O5cX1S9U6MpFrvRy6CMM= Received: by 10.103.119.19 with SMTP id w19mr4884617mum.129.1217736925885; Sat, 02 Aug 2008 21:15:25 -0700 (PDT) Received: by 10.103.198.5 with HTTP; Sat, 2 Aug 2008 21:15:25 -0700 (PDT) Message-ID: <2378673b0808022115h49ee3aedjb7f460122fbb4674@mail.gmail.com> Date: Sat, 2 Aug 2008 21:15:25 -0700 From: "Satish Raghunath" To: p2pi@ietf.org MIME-Version: 1.0 Content-Disposition: inline X-Google-Sender-Auth: 61d1ad39d59cf8bb Subject: Re: [p2pi] ALTO service privacy, performance, and architecture X-BeenThere: p2pi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: P2P Infrastructure Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: p2pi-bounces@ietf.org Errors-To: p2pi-bounces@ietf.org Stas, If any peer is able to discover most of the participants of a particular swarm, would you still consider it to be a privacy issue to send a list of IP addresses/prefixes to the Oracle? The reason I ask is that I see benefits to having this option. I can see a default mode of operation where the client just downloads a policy and then a more intelligent query that involves a set of IPs. That will allow for an improvement in relevance and timeliness of the information. > A literal sorting oracle operated by the ISP will, however, *not* be > queried by P2P apps and is, therefore, not relevant. > > Passing just a few IP numbers to such an oracle is not enough because > it won't solve the localization problem: chances are none of the few > are nearby. Say a client has downloaded the routing policy. It can still choose to send a list of IPs (or more specific prefixes) that are in the preferred set (as indicated in the downloaded policy) to have the Oracle order it. Do you consider that worthwhile? Satish _______________________________________________ p2pi mailing list p2pi@ietf.org https://www.ietf.org/mailman/listinfo/p2pi From p2pi-bounces@ietf.org Sat Aug 2 21:22: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 7B1583A6A73; Sat, 2 Aug 2008 21:22: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 ED2C93A6778 for ; Sat, 2 Aug 2008 21:22:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.482 X-Spam-Level: X-Spam-Status: No, score=-2.482 tagged_above=-999 required=5 tests=[AWL=0.117, 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 zGKT1dYciW4R for ; Sat, 2 Aug 2008 21:22:53 -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 424153A6A9A for ; Sat, 2 Aug 2008 21:22:53 -0700 (PDT) Received: by wf-out-1314.google.com with SMTP id 27so1513514wfd.31 for ; Sat, 02 Aug 2008 21:23:17 -0700 (PDT) Received: by 10.142.199.16 with SMTP id w16mr4404949wff.206.1217737397661; Sat, 02 Aug 2008 21:23:17 -0700 (PDT) Received: from ?192.168.1.103? ( [67.188.243.194]) by mx.google.com with ESMTPS id 32sm4489997wfc.12.2008.08.02.21.23.16 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sat, 02 Aug 2008 21:23:17 -0700 (PDT) Message-Id: <98610365-2F83-4F8D-A812-F8447ADB0107@shlang.com> From: Stanislav Shalunov To: "Satish Raghunath" In-Reply-To: <2378673b0808022115h49ee3aedjb7f460122fbb4674@mail.gmail.com> Mime-Version: 1.0 (Apple Message framework v926) Date: Sat, 2 Aug 2008 21:23:16 -0700 References: <2378673b0808022115h49ee3aedjb7f460122fbb4674@mail.gmail.com> X-Mailer: Apple Mail (2.926) Cc: p2pi@ietf.org Subject: Re: [p2pi] ALTO service privacy, performance, and architecture X-BeenThere: p2pi@ietf.org 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 Aug 2, 2008, at 9:15 PM, Satish Raghunath wrote: > If any peer is able to discover most of the participants of a > particular swarm, would you still consider it to be a privacy issue to > send a list of IP addresses/prefixes to the Oracle? Yes. The ISP does not have this information currently. It could, in principle, play Media Defender and try to get it. But it doesn't, because there is no incentive to do this. The log files of a sorting oracle would become subpoena fodder. > Say a client has downloaded the routing policy. It can still choose to > send a list of IPs (or more specific prefixes) that are in the > preferred set (as indicated in the downloaded policy) to have the > Oracle order it. Do you consider that worthwhile? Not to the point of implementing. In any case, why would the ISP provide this oracle, particularly in presence of routing policy export? -- Stanislav Shalunov _______________________________________________ p2pi mailing list p2pi@ietf.org https://www.ietf.org/mailman/listinfo/p2pi From p2pi-bounces@ietf.org Sat Aug 2 21:41: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 8E2F828C0FD; Sat, 2 Aug 2008 21:41: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 4C64328C0FD for ; Sat, 2 Aug 2008 21:41:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c3b8Xd-ajdqJ for ; Sat, 2 Aug 2008 21:41:07 -0700 (PDT) Received: from netra.cs.yale.edu (netra.cs.yale.edu [128.36.229.21]) by core3.amsl.com (Postfix) with ESMTP id 44EB028C0FA for ; Sat, 2 Aug 2008 21:41:07 -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 D333B4094C0; Sun, 3 Aug 2008 00:41:31 -0400 (EDT) Date: Sun, 3 Aug 2008 00:41:31 -0400 (EDT) From: "Y. R. Yang" To: Stanislav Shalunov In-Reply-To: <3054D171-EBE8-44FA-BEA0-37A06EE7DD08@shlang.com> Message-ID: References: <200808022240.23300.richard.alimi@yale.edu> <2549C209-67E8-4363-998F-F82807F916CE@shlang.com> <3054D171-EBE8-44FA-BEA0-37A06EE7DD08@shlang.com> MIME-Version: 1.0 Cc: p2pi@ietf.org Subject: Re: [p2pi] ALTO service privacy, performance, and architecture X-BeenThere: p2pi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: P2P Infrastructure Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: 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 Sat, 2 Aug 2008, 9:11pm -0700, Stanislav Shalunov wrote: > On Aug 2, 2008, at 8:31 PM, Y. R. Yang wrote: > >We do see improvement on > >download speed averaged across all ISPs. > > If the average download speed across all users increases, then the total > upload speed increases. This means there was room for it to increase. With > good use of transport, there should not be much room. How many upload slots > do you use? Is there an upload rate limit? There are scenarios where sum of uplink capacity (assuming full utilization by transport) is not the bottleneck of the aggregated throughput, for example, due to block availability or when you have more seeds. A client may get its content faster from faster seeds (with faster uplinks) than from slower seeds. Does this make sense to you? In terms of upload slots and upload rate limit, it is Pando specific, so I am not sure I can say it here. I will be happy to discuss offline, with Laird, though. > >The improvement for some participating ISPs can be much larger than the > >global average, supporting your aforementioned that there can be > >substantial local improvement. > > Sure. Some ISPs have faster uplinks than average, and localizing will > concentrate these on other users at the same ISP. This means, though, > that ISPs with slower uplinks will suffer. > > >The implication on ISP incentive will be an interesting issue. > > I'm not sure I get the connection. The ISP incentive with flat rate is lower > expenses. With per-bit charges to the end-user means fewer irate users who > got a huge surprise bill. Right? I was referring to ISP guidance to improve not only its network expense but also application performance. As you pointed out, faster ISPs benefits by guiding for localizaing, and slower ISPs may need to balance between transit costs and application performance (by pointing to outside). This is the incentive issue I was referring to. Believe or not, some ISPs do care a lot about giving guidance to improve application as well, as we see in the test :-) Richard > -- > Stanislav Shalunov > > _______________________________________________ p2pi mailing list p2pi@ietf.org https://www.ietf.org/mailman/listinfo/p2pi From p2pi-bounces@ietf.org Sat Aug 2 22:14: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 3A30E28C125; Sat, 2 Aug 2008 22:14: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 792F028C11B for ; Sat, 2 Aug 2008 22:14:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 96-rXLSP28nC for ; Sat, 2 Aug 2008 22:14:49 -0700 (PDT) Received: from netra.cs.yale.edu (netra.cs.yale.edu [128.36.229.21]) by core3.amsl.com (Postfix) with ESMTP id 7CEEF28C125 for ; Sat, 2 Aug 2008 22:14:49 -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 A62C94094C0; Sun, 3 Aug 2008 01:14:57 -0400 (EDT) Date: Sun, 3 Aug 2008 01:14:57 -0400 (EDT) From: "Y. R. Yang" To: Stanislav Shalunov In-Reply-To: Message-ID: References: <200808022240.23300.richard.alimi@yale.edu> <2549C209-67E8-4363-998F-F82807F916CE@shlang.com> <3054D171-EBE8-44FA-BEA0-37A06EE7DD08@shlang.com> MIME-Version: 1.0 Cc: p2pi@ietf.org Subject: Re: [p2pi] ALTO service privacy, performance, and architecture X-BeenThere: p2pi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: P2P Infrastructure Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: 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 implication on ISP incentive will be an interesting issue. > > > > I'm not sure I get the connection. The ISP incentive with flat rate > > is lower expenses. With per-bit charges to the end-user means fewer > > irate users who got a huge surprise bill. Right? > > I was referring to ISP guidance to improve not only its network expense > but also application performance. As you pointed out, faster ISPs > benefits by guiding for localizing, and slower ISPs may need to balance > between transit costs and application performance (by pointing to > outside). This is the incentive issue I was referring to. Believe or > not, some ISPs do care a lot about giving guidance to improve > application as well, as we see in the test :-) An addition. I should not say "some ISPs". All ISPs we worked with cared a lot about not only about usage of network resources but also P2P application performance. I guess they believe ISPs giving good guidance prosper, or they were worried about our scrutiny :-) We were quite surprised at some ISP configurations initially. It turned out that ISPs knew a lot more about their networks than we did, and such configurations appeared to be good tradeoffs between ISP and application objectives. I wish we could release some of such interesting configurations. I am not sure this will be ture in large-scale deployment. But there is some chance there. Richard _______________________________________________ p2pi mailing list p2pi@ietf.org https://www.ietf.org/mailman/listinfo/p2pi From p2pi-bounces@ietf.org Sat Aug 2 23:03: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 16F4A3A68BC; Sat, 2 Aug 2008 23:03: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 816423A67DD for ; Sat, 2 Aug 2008 23:03:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.348 X-Spam-Level: X-Spam-Status: No, score=-6.348 tagged_above=-999 required=5 tests=[AWL=0.251, 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 t0IquOu6H4Z5 for ; Sat, 2 Aug 2008 23:03:14 -0700 (PDT) Received: from exprod7og103.obsmtp.com (exprod7og103.obsmtp.com [64.18.2.159]) by core3.amsl.com (Postfix) with ESMTP id 422123A68BC for ; Sat, 2 Aug 2008 23:03:12 -0700 (PDT) Received: from source ([66.129.228.6]) by exprod7ob103.postini.com ([64.18.6.12]) with SMTP; Sat, 02 Aug 2008 23:03:37 PDT Received: from p-emlb02-sac.jnpr.net ([66.129.254.47]) by p-emsmtp02.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Sat, 2 Aug 2008 23:03:36 -0700 Received: from pi-smtp.jnpr.net ([10.10.2.36]) by p-emlb02-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Sat, 2 Aug 2008 23:03:36 -0700 Received: from proton.jnpr.net ([10.10.2.37]) by pi-smtp.jnpr.net with Microsoft SMTPSVC(5.0.2195.6713); Sun, 3 Aug 2008 02:03:35 -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 ; Sun, 3 Aug 2008 06:03:34 +0000 User-Agent: Microsoft-Entourage/12.11.0.080522 Date: Sat, 02 Aug 2008 23:03:31 -0700 From: Reinaldo Penno To: Laird Popkin Message-ID: Thread-Topic: [p2pi] ALTO service privacy, performance, and architecture Thread-Index: Acj1LqelNJd7HAGeLUudx0XydHMnTg== In-Reply-To: <2087988022.98841217736546525.JavaMail.root@dkny.pando.com> Mime-version: 1.0 X-OriginalArrivalTime: 03 Aug 2008 06:03:35.0390 (UTC) FILETIME=[AA4357E0:01C8F52E] Cc: p2pi@ietf.org Subject: Re: [p2pi] ALTO service privacy, performance, and architecture X-BeenThere: p2pi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: P2P Infrastructure Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: 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 8/2/08 9:09 PM, "Laird Popkin" wrote: > I don't think that p2p users will know or care about ALTO, any more than they > know or care about BGP, or HTTP proxies - things just work. ALTO will need to > be known about and implemented either by the p2p trackers or clients. At most > some applications might provide an ALTO check box as a preference setting, > just as they might allow for manual proxy configuration. At most or always? If you make it mandatory you are deciding on behalf of the users who he/she should connect and you are dealing in the net neutrality realm. I'm not sure MSO and Telcos want to go through FCC battles again. > > Answering the question "And the motivation for pirate trackers would be? ... > Improve performance seems slim.", I believe that there are two benefits, one > direct and one indirect. > > The direct benefit is that localizing data transfers improves download > performance for users significantly on average, which makes users happier. > While theoretically it shouldn't matter whether data is pulled from nearby > sources or far, in practice localizing data sources appears to improve > performance quite a bit. I can only guess what the cause of the improved > performance is (perhaps shorter RTT's improve TCP throughput, perhaps avoiding > congested internet gateways). In any case, we're seeing real world download > speeds double and triple for users on fast broadband connections (nothing will > speed up a slow broadband connection...). > > The indirect benefit is that by reducing the transit costs created by p2p > traffic, it reduces the incentives for ISPs to degrade p2p traffic. I was talking about what were the incentives for public trackers to perform optimizations. Your arguments seem to be ISP centric. Public trackers do not care or are very happy with the current download speeds of their users. Statistics from these trackers show more bandwidth consumed in a month than all itunes music sold to date. > > "Clients can potentially improve their own performance by choosing closer > peers based on IP addresses." How would they know which IP addresses are > closer? ALTO? As Stas suggested, a client can easily get access to a full BGP routing table and perform some optimizations itself. Is this ALTO? > > - Laird Popkin, CTO, Pando Networks > mobile: 646/465-0570 > > ----- Original Message ----- > From: "Reinaldo Penno" > To: "Laird Popkin" > Cc: p2pi@ietf.org, "Richard Alimi" > Sent: Saturday, August 2, 2008 10:58:44 PM (GMT-0500) America/New_York > Subject: Re: [p2pi] ALTO service privacy, performance, and architecture > > > > > On 8/2/08 7:35 PM, "Laird Popkin" wrote: > >> The P4P tests that were performed so far were performed with legal content so >> that we could focus on technical issues (e.g. implementing and running the >> tests) and not get caught in potentially lengthy policy discussions that >> (IMO) >> are only worth having once the technology demonstrates its value. The test >> results have been very good, so I suspect that the policy discussions will >> start taking place. There's no technical issue limiting who uses P4P (and, I >> hope, ALTO). Given this, I believe that each ISP can decide its own policies >> regarding who it wants to share what information with. > > Understood. > >> >> Keep in mind that ALTO servers can be run by entities other than ISPs. So if >> ISPs don't want to work with pirate trackers, the pirate trackers might join >> together to set up an ALTO server populated using whatever network >> information >> they can collect or determine (e.g. ASN adjacency maps) to improve >> performance >> for their users. > > And the motivation for pirate trackers would be? There is no business > relationship between P2P clients and their public trackers. Improve > performance seems slim. Clients can potentially improve their own > performance by choosing closer peers based on IP addresses. > >> >> Finally, ALTO servers should be accessible by either clients or servers, so >> it >> may be the case that even if ISPs don't want to work with pirate trackers, >> they might approve working with user p2p clients, which would achieve a >> similar result. > > The latter requires a leap of faith. That's where I think we have different > opinions. I think we need to make sure P2P users are on-board. BTW, by P2P > clients you mean the P2P software or P2P users? > > Thanks, > > Reinaldo >> >> - Laird Popkin, CTO, Pando Networks >> mobile: 646/465-0570 >> >> ----- Original Message ----- >> From: "Reinaldo Penno" >> To: "Richard Alimi" >> Cc: p2pi@ietf.org >> Sent: Saturday, August 2, 2008 10:10:11 PM (GMT-0500) America/New_York >> Subject: Re: [p2pi] ALTO service privacy, performance, and architecture >> >> Hi, >> >> Thanks for your answers. Comments inline. >> >> On 8/2/08 6:11 PM, "Richard Alimi" wrote: >> >>>> I just want to remind that we are here because of file-sharing and not >>>> really closed P2P networks where itrackers, apptrackers and others >>>> cooperate nicely. This is the easy case and today does not cause problems >>>> to ISPs. And maybe never will. >>> >>> Let me make one clarification to your statement above. The itracker in P4P >>> is >>> not application specific, and thus is not part of any closed system. It can >>> be queried by many P2P applications, and does not keep any swarm state. The >>> field tests have been done with Pando, but nothing restricts it from being >>> used for "public" P2P networks. >>> >>> Or did I misinterpret your meaning of "closed"? >> >> Closed as in the sense that it assumes cooperation from the AppTracker. >> Otherwise how can it not keep any swarm state? This is is based on the >> functionality from your paper. >> >> Anyway, the two statements seem contradictory. The corollary is that the >> content that such clients access are those of the P2P CDN and not pirated >> content. The P4P trials that I have heard/read are based on legal content. >> Please correct me if I'm wrong. >> >>> >>>> So, when you say "tracker-less" systems you mean a P2P network without a >>>> tracker (Gnutella) or a P2P network where the tracker is something like >>>> thepiratebay? The two 'systems' (as you put it) are quite different. >>> >>> By "tracker-less," I was referring to a P2P network without a tracker. We >>> consider thepiratebay a tracker-based system. >>> >>>> In the case where there is a tracker on the Internet that does not >>>> cooperate (which is 99.99% of P2P traffic today) I'm not sure how ALTO >>>> would work without the ISP tracker pushing information to the clients >>>> (since the clients might not send info to the tracker). >>> >>> I agree that to cover the majority of the P2P traffic, it may be mostly be >>> client-dependent in the beginning. >>> >>> The idea, however, is that as time goes on P2P developers and ISPs will each >>> realize the benefits (better performance for P2P apps, and achieve >>> particular >>> network goals for ISPs) and begin support. Integration should be simple >>> enough that P2P developers understand and use it. >> >> It is not P2P developers that need to be convinced. It is the users, the >> human factor. >> >> And if ALTO does not "get it" that it is not just about having a >> client-server protocol, I'm not sure of the benefits. Yeah, Pando or Joost >> users can be convinced of using it, but how about the other users that are >> responsible for 99.9% of traffic? And if they cannot be convinced, can ALTO >> still do some form of optimization? This goes back to security and privacy. >> >>> >>>> For private trackers (which have the really hardcore users) it is not clear >>>> how ALTO can influence their behavior since the whole point is to stay >>>> within the private tracker's given peers. If we cannot tackle these two >>>> scenarios, ISPs continue to suffer. >>> >>> Interesting point. If there are limited peers in a swarm, then there are >>> limited opportunities for optimization (both for the P2P and ISP side). Is >>> this a fundamental limit, though? Aside, of course, from "telling" them that >>> their swarms should be larger :) >> >> Well, peers driven by private trackers are the elite. They do not really >> need a big swarm since these are folks that have their computers on 24x7 and >> have Seedboxes. Most of the time they have co-location boxes and/or pay >> enterprise fees to have tons of bandwidth. >> >>> >>> Getting adoption in major public P2P clients/trackers is certainly important >>> in order for this to make a large difference for ISP networks. >> >> I believe, as I said before, that we need to convince users. The only way to >> convince such users is if we have a tight (very tight) security, privacy >> model. Otherwise the ALTO protocol might not see use in the wild. >> >> As far as convincing public trackers also means convincing the ISP to have a >> relationship with such trackers as thepiratebay. Does Comcast or BT want to >> have such relationship? I have no idea. I guess my point is that the >> business/realities of P2P networks should drive the requirements so we can >> work with (or around them). >> >> Thanks, >> >> Reinaldo >> >> >> _______________________________________________ >> 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 Aug 2 23:48:09 2008 Return-Path: X-Original-To: p2pi-archive@ietf.org Delivered-To: ietfarch-p2pi-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2C2AA3A68F9; Sat, 2 Aug 2008 23:48:09 -0700 (PDT) X-Original-To: p2pi@core3.amsl.com Delivered-To: p2pi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A59253A68F9 for ; Sat, 2 Aug 2008 23:48:07 -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 ANB42ULFBTWe for ; Sat, 2 Aug 2008 23:48:06 -0700 (PDT) Received: from exprod7og102.obsmtp.com (exprod7og102.obsmtp.com [64.18.2.157]) by core3.amsl.com (Postfix) with ESMTP id 85A463A68BC for ; Sat, 2 Aug 2008 23:48:04 -0700 (PDT) Received: from source ([66.129.228.6]) by exprod7ob102.postini.com ([64.18.6.12]) with SMTP; Sat, 02 Aug 2008 23:45:37 PDT Received: from p-emlb02-sac.jnpr.net ([66.129.254.47]) by p-emsmtp02.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Sat, 2 Aug 2008 23:46:28 -0700 Received: from antipi.jnpr.net ([10.10.2.34]) by p-emlb02-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Sat, 2 Aug 2008 23:46:28 -0700 Received: from proton.jnpr.net ([10.10.2.37]) by antipi.jnpr.net with Microsoft SMTPSVC(6.0.3790.1830); Sun, 3 Aug 2008 02:46:21 -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 ; Sun, 3 Aug 2008 06:46:20 +0000 User-Agent: Microsoft-Entourage/12.11.0.080522 Date: Sat, 02 Aug 2008 23:46:17 -0700 From: Reinaldo Penno To: Laird Popkin Message-ID: Thread-Topic: [p2pi] ALTO service privacy, performance, and architecture Thread-Index: Acj1NKEaOdZQNVb6iEGcVRoJtugy/Q== In-Reply-To: <2087988022.98841217736546525.JavaMail.root@dkny.pando.com> Mime-version: 1.0 X-OriginalArrivalTime: 03 Aug 2008 06:46:21.0269 (UTC) FILETIME=[A3A56850:01C8F534] Cc: p2pi@ietf.org Subject: Re: [p2pi] ALTO service privacy, performance, and architecture X-BeenThere: p2pi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: P2P Infrastructure Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: 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, On 8/2/08 9:09 PM, "Laird Popkin" wrote: > I don't think that p2p users will know or care about ALTO, any more than they > know or care about BGP, or HTTP proxies - things just work. I would say they care a lot. You statement that you "don't think p2p users will know" does not seem to reflect the transparency we need. Doing anything under the covers already proved disastrous. Once bitten, twice shy. I would be surprised if users/EFF/consumers groups do not scrutinize what is happening with, within the ALTO protocol and how their information will be used. You have to see it from the users point of view, the people that complained to the FCC, had connections dropped/policed/whatever, go to messages board in droves to complain, etc. Thanks, Reinaldo ALTO will need to > be known about and implemented either by the p2p trackers or clients. At most > some applications might provide an ALTO check box as a preference setting, > just as they might allow for manual proxy configuration. > > Answering the question "And the motivation for pirate trackers would be? ... > Improve performance seems slim.", I believe that there are two benefits, one > direct and one indirect. > > The direct benefit is that localizing data transfers improves download > performance for users significantly on average, which makes users happier. > While theoretically it shouldn't matter whether data is pulled from nearby > sources or far, in practice localizing data sources appears to improve > performance quite a bit. I can only guess what the cause of the improved > performance is (perhaps shorter RTT's improve TCP throughput, perhaps avoiding > congested internet gateways). In any case, we're seeing real world download > speeds double and triple for users on fast broadband connections (nothing will > speed up a slow broadband connection...). > > The indirect benefit is that by reducing the transit costs created by p2p > traffic, it reduces the incentives for ISPs to degrade p2p traffic. > > "Clients can potentially improve their own performance by choosing closer > peers based on IP addresses." How would they know which IP addresses are > closer? ALTO? > > - Laird Popkin, CTO, Pando Networks > mobile: 646/465-0570 > > ----- Original Message ----- > From: "Reinaldo Penno" > To: "Laird Popkin" > Cc: p2pi@ietf.org, "Richard Alimi" > Sent: Saturday, August 2, 2008 10:58:44 PM (GMT-0500) America/New_York > Subject: Re: [p2pi] ALTO service privacy, performance, and architecture > > > > > On 8/2/08 7:35 PM, "Laird Popkin" wrote: > >> The P4P tests that were performed so far were performed with legal content so >> that we could focus on technical issues (e.g. implementing and running the >> tests) and not get caught in potentially lengthy policy discussions that >> (IMO) >> are only worth having once the technology demonstrates its value. The test >> results have been very good, so I suspect that the policy discussions will >> start taking place. There's no technical issue limiting who uses P4P (and, I >> hope, ALTO). Given this, I believe that each ISP can decide its own policies >> regarding who it wants to share what information with. > > Understood. > >> >> Keep in mind that ALTO servers can be run by entities other than ISPs. So if >> ISPs don't want to work with pirate trackers, the pirate trackers might join >> together to set up an ALTO server populated using whatever network >> information >> they can collect or determine (e.g. ASN adjacency maps) to improve >> performance >> for their users. > > And the motivation for pirate trackers would be? There is no business > relationship between P2P clients and their public trackers. Improve > performance seems slim. Clients can potentially improve their own > performance by choosing closer peers based on IP addresses. > >> >> Finally, ALTO servers should be accessible by either clients or servers, so >> it >> may be the case that even if ISPs don't want to work with pirate trackers, >> they might approve working with user p2p clients, which would achieve a >> similar result. > > The latter requires a leap of faith. That's where I think we have different > opinions. I think we need to make sure P2P users are on-board. BTW, by P2P > clients you mean the P2P software or P2P users? > > Thanks, > > Reinaldo >> >> - Laird Popkin, CTO, Pando Networks >> mobile: 646/465-0570 >> >> ----- Original Message ----- >> From: "Reinaldo Penno" >> To: "Richard Alimi" >> Cc: p2pi@ietf.org >> Sent: Saturday, August 2, 2008 10:10:11 PM (GMT-0500) America/New_York >> Subject: Re: [p2pi] ALTO service privacy, performance, and architecture >> >> Hi, >> >> Thanks for your answers. Comments inline. >> >> On 8/2/08 6:11 PM, "Richard Alimi" wrote: >> >>>> I just want to remind that we are here because of file-sharing and not >>>> really closed P2P networks where itrackers, apptrackers and others >>>> cooperate nicely. This is the easy case and today does not cause problems >>>> to ISPs. And maybe never will. >>> >>> Let me make one clarification to your statement above. The itracker in P4P >>> is >>> not application specific, and thus is not part of any closed system. It can >>> be queried by many P2P applications, and does not keep any swarm state. The >>> field tests have been done with Pando, but nothing restricts it from being >>> used for "public" P2P networks. >>> >>> Or did I misinterpret your meaning of "closed"? >> >> Closed as in the sense that it assumes cooperation from the AppTracker. >> Otherwise how can it not keep any swarm state? This is is based on the >> functionality from your paper. >> >> Anyway, the two statements seem contradictory. The corollary is that the >> content that such clients access are those of the P2P CDN and not pirated >> content. The P4P trials that I have heard/read are based on legal content. >> Please correct me if I'm wrong. >> >>> >>>> So, when you say "tracker-less" systems you mean a P2P network without a >>>> tracker (Gnutella) or a P2P network where the tracker is something like >>>> thepiratebay? The two 'systems' (as you put it) are quite different. >>> >>> By "tracker-less," I was referring to a P2P network without a tracker. We >>> consider thepiratebay a tracker-based system. >>> >>>> In the case where there is a tracker on the Internet that does not >>>> cooperate (which is 99.99% of P2P traffic today) I'm not sure how ALTO >>>> would work without the ISP tracker pushing information to the clients >>>> (since the clients might not send info to the tracker). >>> >>> I agree that to cover the majority of the P2P traffic, it may be mostly be >>> client-dependent in the beginning. >>> >>> The idea, however, is that as time goes on P2P developers and ISPs will each >>> realize the benefits (better performance for P2P apps, and achieve >>> particular >>> network goals for ISPs) and begin support. Integration should be simple >>> enough that P2P developers understand and use it. >> >> It is not P2P developers that need to be convinced. It is the users, the >> human factor. >> >> And if ALTO does not "get it" that it is not just about having a >> client-server protocol, I'm not sure of the benefits. Yeah, Pando or Joost >> users can be convinced of using it, but how about the other users that are >> responsible for 99.9% of traffic? And if they cannot be convinced, can ALTO >> still do some form of optimization? This goes back to security and privacy. >> >>> >>>> For private trackers (which have the really hardcore users) it is not clear >>>> how ALTO can influence their behavior since the whole point is to stay >>>> within the private tracker's given peers. If we cannot tackle these two >>>> scenarios, ISPs continue to suffer. >>> >>> Interesting point. If there are limited peers in a swarm, then there are >>> limited opportunities for optimization (both for the P2P and ISP side). Is >>> this a fundamental limit, though? Aside, of course, from "telling" them that >>> their swarms should be larger :) >> >> Well, peers driven by private trackers are the elite. They do not really >> need a big swarm since these are folks that have their computers on 24x7 and >> have Seedboxes. Most of the time they have co-location boxes and/or pay >> enterprise fees to have tons of bandwidth. >> >>> >>> Getting adoption in major public P2P clients/trackers is certainly important >>> in order for this to make a large difference for ISP networks. >> >> I believe, as I said before, that we need to convince users. The only way to >> convince such users is if we have a tight (very tight) security, privacy >> model. Otherwise the ALTO protocol might not see use in the wild. >> >> As far as convincing public trackers also means convincing the ISP to have a >> relationship with such trackers as thepiratebay. Does Comcast or BT want to >> have such relationship? I have no idea. I guess my point is that the >> business/realities of P2P networks should drive the requirements so we can >> work with (or around them). >> >> Thanks, >> >> Reinaldo >> >> >> _______________________________________________ >> p2pi mailing list >> p2pi@ietf.org >> https://www.ietf.org/mailman/listinfo/p2pi > > _______________________________________________ p2pi mailing list p2pi@ietf.org https://www.ietf.org/mailman/listinfo/p2pi From p2pi-bounces@ietf.org Sun Aug 3 00:12: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 4B1633A6B77; Sun, 3 Aug 2008 00:12: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 023EA3A6B77 for ; Sun, 3 Aug 2008 00:12:35 -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 eLfq35kToWJc for ; Sun, 3 Aug 2008 00:12:34 -0700 (PDT) Received: from QMTA03.emeryville.ca.mail.comcast.net (qmta03.emeryville.ca.mail.comcast.net [76.96.30.32]) by core3.amsl.com (Postfix) with ESMTP id 3B6533A6B6B for ; Sun, 3 Aug 2008 00:12:34 -0700 (PDT) Received: from OMTA08.emeryville.ca.mail.comcast.net ([76.96.30.12]) by QMTA03.emeryville.ca.mail.comcast.net with comcast id xj5i1Z00H0FhH24A3jCzsB; Sun, 03 Aug 2008 07:12:59 +0000 Received: from poweredge.velvetsea.net ([76.182.22.132]) by OMTA08.emeryville.ca.mail.comcast.net with comcast id xjCl1Z0062qze2s8UjCoMA; Sun, 03 Aug 2008 07:12:57 +0000 X-Authority-Analysis: v=1.0 c=1 a=HQ6x2VH6PSwA:10 a=Mr5i1LQ58koA:10 a=glLxhiyhS7I4E3nX01UA:9 a=tibj3MovYFO3QbtYTyIA:7 a=iw6Ll9mcARlmmyCr8L_p0FWvPPUA:4 a=GZE22DiOxE8A:10 a=50e4U0PicR4A:10 Received: from desktop.velvetsea.net (desktop.velvetsea.net [192.168.1.4]) by poweredge.velvetsea.net (Postfix) with ESMTP id 6EFE7424001; Sun, 3 Aug 2008 03:12:45 -0400 (EDT) From: Richard Alimi To: Reinaldo Penno Date: Sun, 3 Aug 2008 03:12:44 -0400 User-Agent: KMail/1.10.0 (Linux/2.6.24.4; KDE/4.1.1; i686; ; ) References: In-Reply-To: MIME-Version: 1.0 Content-Disposition: inline Message-Id: <200808030312.45060.richard.alimi@yale.edu> Cc: p2pi@ietf.org Subject: Re: [p2pi] ALTO service privacy, performance, and architecture X-BeenThere: p2pi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: P2P Infrastructure Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: p2pi-bounces@ietf.org Errors-To: p2pi-bounces@ietf.org Hi Reinaldo, > On 8/2/08 9:09 PM, "Laird Popkin" wrote: > > I don't think that p2p users will know or care about ALTO, any more than > > they know or care about BGP, or HTTP proxies - things just work. > > I would say they care a lot. You statement that you "don't think p2p users > will know" does not seem to reflect the transparency we need. Doing > anything under the covers already proved disastrous. Yes I agree that what ALTO is actually doing should be transparent, particularly in how users' information is disseminated. But, users should not _need_ to know about ALTO to use it. If it does not leak any more private information that is done today, then there should be no harm in enabling it by default, in which case many users probably wont even know its there. If interested users want to find out what ALTO is doing, they are free to do so. > Once bitten, twice shy. I would be surprised if users/EFF/consumers groups > do not scrutinize what is happening with, within the ALTO protocol and how > their information will be used. You have to see it from the users point of > view, the people that complained to the FCC, had connections > dropped/policed/whatever, go to messages board in droves to complain, etc. Certainly agree. The point that I was trying to make earlier, is that ALTO should be readily-accessible and implementable by P2P client/developers in order for to eventually be used for the majority of P2P traffic in the internet. In addition to this, I fully agree with you that the incentives for users to actually use ALTO should be there. Without both of these considerations, it seems that getting widespread adoption of ALTO would be difficult. -- Richard Alimi Department of Computer Science Yale University _______________________________________________ p2pi mailing list p2pi@ietf.org https://www.ietf.org/mailman/listinfo/p2pi From p2pi-bounces@ietf.org Sun Aug 3 04:15:33 2008 Return-Path: X-Original-To: p2pi-archive@ietf.org Delivered-To: ietfarch-p2pi-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 886833A690E; Sun, 3 Aug 2008 04:15:33 -0700 (PDT) X-Original-To: p2pi@core3.amsl.com Delivered-To: p2pi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CB5903A690E for ; Sun, 3 Aug 2008 04:15:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.07 X-Spam-Level: X-Spam-Status: No, score=-10.07 tagged_above=-999 required=5 tests=[AWL=-0.120, 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 TC8z0fFP9aNc for ; Sun, 3 Aug 2008 04:15:30 -0700 (PDT) Received: from dkny.pando.com (dkny.pando.com [67.99.55.163]) by core3.amsl.com (Postfix) with ESMTP id 127C63A68E6 for ; Sun, 3 Aug 2008 04:15:29 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by dkny.pando.com (Postfix) with ESMTP id 06D02E10A03; Sun, 3 Aug 2008 07:15:53 -0400 (EDT) X-Virus-Scanned: amavisd-new at Received: from dkny.pando.com ([127.0.0.1]) by localhost (dkny.pando.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JzAElr-m7blp; Sun, 3 Aug 2008 07:15:28 -0400 (EDT) Received: from dkny.pando.com (dkny.pando.com [10.10.60.11]) by dkny.pando.com (Postfix) with ESMTP id 86607E10B53; Sun, 3 Aug 2008 07:15:28 -0400 (EDT) Date: Sun, 3 Aug 2008 07:15:28 -0400 (EDT) From: Laird Popkin To: Reinaldo Penno Message-ID: <1144783309.99011217762128498.JavaMail.root@dkny.pando.com> In-Reply-To: <577360154.98991217761846060.JavaMail.root@dkny.pando.com> MIME-Version: 1.0 X-Originating-IP: [71.187.207.81] Cc: p2pi@ietf.org Subject: Re: [p2pi] ALTO service privacy, performance, and architecture X-BeenThere: p2pi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: P2P Infrastructure Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: p2pi-bounces@ietf.org Errors-To: p2pi-bounces@ietf.org Regarding the question of whether users know about ALTO, I think that you're reading too much into ALTO. P2P networks already control who users connect to and exchange data with, transparently to users. ALTO doesn't change anything other than that the ISPs are providing some assistance. Regarding public tracker's incentives to implement this, I am not sure why you assume that they don't want their users to have fast download speeds. Users care a lot about download speeds, and would be happy to switch to whichever tracker gave them the best performance. And the people that run trackers care a lot about whether people use them. This is probably why, when I've talked to people that run trackers, they'd be very happy to implement a performance optimization that made their downloads faster. Their concerns are more regarding complexity of implementation, and in working with the ISPs to get the guidance. Regarding the statement that "a client can easily get access to a full BGP routing table and perform some optimizations itself", while theoretically a p2p client could retrieve and use full BGP tables, but in practice BGP routing tables are quite large and complex, so I'm not sure that I would call doing this 'easy' to the point where millions of desktop applications should be doing it. It's far more efficient for this kind of work to be done in a centralized server that the clients can query for guidance, IMO. - Laird Popkin, CTO, Pando Networks mobile: 646/465-0570 ----- Original Message ----- From: "Reinaldo Penno" To: "Laird Popkin" Cc: p2pi@ietf.org, "Richard Alimi" Sent: Sunday, August 3, 2008 2:03:31 AM (GMT-0500) America/New_York Subject: Re: [p2pi] ALTO service privacy, performance, and architecture On 8/2/08 9:09 PM, "Laird Popkin" wrote: > I don't think that p2p users will know or care about ALTO, any more than they > know or care about BGP, or HTTP proxies - things just work. ALTO will need to > be known about and implemented either by the p2p trackers or clients. At most > some applications might provide an ALTO check box as a preference setting, > just as they might allow for manual proxy configuration. At most or always? If you make it mandatory you are deciding on behalf of the users who he/she should connect and you are dealing in the net neutrality realm. I'm not sure MSO and Telcos want to go through FCC battles again. > > Answering the question "And the motivation for pirate trackers would be? ... > Improve performance seems slim.", I believe that there are two benefits, one > direct and one indirect. > > The direct benefit is that localizing data transfers improves download > performance for users significantly on average, which makes users happier. > While theoretically it shouldn't matter whether data is pulled from nearby > sources or far, in practice localizing data sources appears to improve > performance quite a bit. I can only guess what the cause of the improved > performance is (perhaps shorter RTT's improve TCP throughput, perhaps avoiding > congested internet gateways). In any case, we're seeing real world download > speeds double and triple for users on fast broadband connections (nothing will > speed up a slow broadband connection...). > > The indirect benefit is that by reducing the transit costs created by p2p > traffic, it reduces the incentives for ISPs to degrade p2p traffic. I was talking about what were the incentives for public trackers to perform optimizations. Your arguments seem to be ISP centric. Public trackers do not care or are very happy with the current download speeds of their users. Statistics from these trackers show more bandwidth consumed in a month than all itunes music sold to date. > > "Clients can potentially improve their own performance by choosing closer > peers based on IP addresses." How would they know which IP addresses are > closer? ALTO? As Stas suggested, a client can easily get access to a full BGP routing table and perform some optimizations itself. Is this ALTO? > > - Laird Popkin, CTO, Pando Networks > mobile: 646/465-0570 > > ----- Original Message ----- > From: "Reinaldo Penno" > To: "Laird Popkin" > Cc: p2pi@ietf.org, "Richard Alimi" > Sent: Saturday, August 2, 2008 10:58:44 PM (GMT-0500) America/New_York > Subject: Re: [p2pi] ALTO service privacy, performance, and architecture > > > > > On 8/2/08 7:35 PM, "Laird Popkin" wrote: > >> The P4P tests that were performed so far were performed with legal content so >> that we could focus on technical issues (e.g. implementing and running the >> tests) and not get caught in potentially lengthy policy discussions that >> (IMO) >> are only worth having once the technology demonstrates its value. The test >> results have been very good, so I suspect that the policy discussions will >> start taking place. There's no technical issue limiting who uses P4P (and, I >> hope, ALTO). Given this, I believe that each ISP can decide its own policies >> regarding who it wants to share what information with. > > Understood. > >> >> Keep in mind that ALTO servers can be run by entities other than ISPs. So if >> ISPs don't want to work with pirate trackers, the pirate trackers might join >> together to set up an ALTO server populated using whatever network >> information >> they can collect or determine (e.g. ASN adjacency maps) to improve >> performance >> for their users. > > And the motivation for pirate trackers would be? There is no business > relationship between P2P clients and their public trackers. Improve > performance seems slim. Clients can potentially improve their own > performance by choosing closer peers based on IP addresses. > >> >> Finally, ALTO servers should be accessible by either clients or servers, so >> it >> may be the case that even if ISPs don't want to work with pirate trackers, >> they might approve working with user p2p clients, which would achieve a >> similar result. > > The latter requires a leap of faith. That's where I think we have different > opinions. I think we need to make sure P2P users are on-board. BTW, by P2P > clients you mean the P2P software or P2P users? > > Thanks, > > Reinaldo >> >> - Laird Popkin, CTO, Pando Networks >> mobile: 646/465-0570 >> >> ----- Original Message ----- >> From: "Reinaldo Penno" >> To: "Richard Alimi" >> Cc: p2pi@ietf.org >> Sent: Saturday, August 2, 2008 10:10:11 PM (GMT-0500) America/New_York >> Subject: Re: [p2pi] ALTO service privacy, performance, and architecture >> >> Hi, >> >> Thanks for your answers. Comments inline. >> >> On 8/2/08 6:11 PM, "Richard Alimi" wrote: >> >>>> I just want to remind that we are here because of file-sharing and not >>>> really closed P2P networks where itrackers, apptrackers and others >>>> cooperate nicely. This is the easy case and today does not cause problems >>>> to ISPs. And maybe never will. >>> >>> Let me make one clarification to your statement above. The itracker in P4P >>> is >>> not application specific, and thus is not part of any closed system. It can >>> be queried by many P2P applications, and does not keep any swarm state. The >>> field tests have been done with Pando, but nothing restricts it from being >>> used for "public" P2P networks. >>> >>> Or did I misinterpret your meaning of "closed"? >> >> Closed as in the sense that it assumes cooperation from the AppTracker. >> Otherwise how can it not keep any swarm state? This is is based on the >> functionality from your paper. >> >> Anyway, the two statements seem contradictory. The corollary is that the >> content that such clients access are those of the P2P CDN and not pirated >> content. The P4P trials that I have heard/read are based on legal content. >> Please correct me if I'm wrong. >> >>> >>>> So, when you say "tracker-less" systems you mean a P2P network without a >>>> tracker (Gnutella) or a P2P network where the tracker is something like >>>> thepiratebay? The two 'systems' (as you put it) are quite different. >>> >>> By "tracker-less," I was referring to a P2P network without a tracker. We >>> consider thepiratebay a tracker-based system. >>> >>>> In the case where there is a tracker on the Internet that does not >>>> cooperate (which is 99.99% of P2P traffic today) I'm not sure how ALTO >>>> would work without the ISP tracker pushing information to the clients >>>> (since the clients might not send info to the tracker). >>> >>> I agree that to cover the majority of the P2P traffic, it may be mostly be >>> client-dependent in the beginning. >>> >>> The idea, however, is that as time goes on P2P developers and ISPs will each >>> realize the benefits (better performance for P2P apps, and achieve >>> particular >>> network goals for ISPs) and begin support. Integration should be simple >>> enough that P2P developers understand and use it. >> >> It is not P2P developers that need to be convinced. It is the users, the >> human factor. >> >> And if ALTO does not "get it" that it is not just about having a >> client-server protocol, I'm not sure of the benefits. Yeah, Pando or Joost >> users can be convinced of using it, but how about the other users that are >> responsible for 99.9% of traffic? And if they cannot be convinced, can ALTO >> still do some form of optimization? This goes back to security and privacy. >> >>> >>>> For private trackers (which have the really hardcore users) it is not clear >>>> how ALTO can influence their behavior since the whole point is to stay >>>> within the private tracker's given peers. If we cannot tackle these two >>>> scenarios, ISPs continue to suffer. >>> >>> Interesting point. If there are limited peers in a swarm, then there are >>> limited opportunities for optimization (both for the P2P and ISP side). Is >>> this a fundamental limit, though? Aside, of course, from "telling" them that >>> their swarms should be larger :) >> >> Well, peers driven by private trackers are the elite. They do not really >> need a big swarm since these are folks that have their computers on 24x7 and >> have Seedboxes. Most of the time they have co-location boxes and/or pay >> enterprise fees to have tons of bandwidth. >> >>> >>> Getting adoption in major public P2P clients/trackers is certainly important >>> in order for this to make a large difference for ISP networks. >> >> I believe, as I said before, that we need to convince users. The only way to >> convince such users is if we have a tight (very tight) security, privacy >> model. Otherwise the ALTO protocol might not see use in the wild. >> >> As far as convincing public trackers also means convincing the ISP to have a >> relationship with such trackers as thepiratebay. Does Comcast or BT want to >> have such relationship? I have no idea. I guess my point is that the >> business/realities of P2P networks should drive the requirements so we can >> work with (or around them). >> >> Thanks, >> >> Reinaldo >> >> >> _______________________________________________ >> p2pi mailing list >> p2pi@ietf.org >> https://www.ietf.org/mailman/listinfo/p2pi > > _______________________________________________ p2pi mailing list p2pi@ietf.org https://www.ietf.org/mailman/listinfo/p2pi From p2pi-bounces@ietf.org Sun Aug 3 05:30: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 A01423A6B08; Sun, 3 Aug 2008 05:30: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 4F4B73A6B6E for ; Sun, 3 Aug 2008 00:21:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_82=0.6, SPF_PASS=-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 yoLDlOl4gMFE for ; Sun, 3 Aug 2008 00:21:26 -0700 (PDT) Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by core3.amsl.com (Postfix) with ESMTP id 995F13A6B65 for ; Sun, 3 Aug 2008 00:20:47 -0700 (PDT) Received: from [10.107.71.9] (62-50-221-118.client.stsn.net [62.50.221.118]) (authenticated bits=0) by nostrum.com (8.14.2/8.14.1) with ESMTP id m737L5Pe074861 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Sun, 3 Aug 2008 02:21:08 -0500 (CDT) (envelope-from rjsparks@nostrum.com) Message-Id: From: Robert Sparks To: p2pi@ietf.org Content-Type: multipart/mixed; boundary=Apple-Mail-140-1070175938 Mime-Version: 1.0 (Apple Message framework v926) Date: Sun, 3 Aug 2008 08:21:00 +0100 References: X-Mailer: Apple Mail (2.926) Received-SPF: pass (nostrum.com: 62.50.221.118 is authenticated by a trusted mechanism) X-Virus-Scanned: ClamAV 0.93.3/7918/Sat Aug 2 21:45:57 2008 on shaman.nostrum.com X-Virus-Status: Clean X-Mailman-Approved-At: Sun, 03 Aug 2008 05:30:14 -0700 Subject: [p2pi] Fwd: AltoBof 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: , Sender: p2pi-bounces@ietf.org Errors-To: p2pi-bounces@ietf.org --Apple-Mail-140-1070175938 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit > The chairs suggested forwarding these to the list. RjS > --Apple-Mail-140-1070175938 Content-Disposition: attachment; filename=AltoBof.txt Content-Type: text/plain; x-mac-hide-extension=yes; x-unix-mode=0644; name="AltoBof.txt" Content-Transfer-Encoding: 7bit Topic - [ ] Tuesday July 29 - Alto Bof - IETF72 - [ ] Agenda bashing - [ ] no changes discussed - [ ] ALTO Problem Statement - [ ] Slides presented - [ ] Stanislav - is the primary problem reducing interdomain traffic? Can we put the problem we're trying to solve in the charter? This would be a good problem to put there. - [ ] Stanislav - We can already do several of the things called out as responses on the "Addressing the Alto Problem" slide without a standard (using looking glass) - [ ] Jon - (redirecting discussion to focusing on finding the scope for possible work) - [ ] Stanislav - (missed the comment - roughly it was there are plenty of places we can get information from without a new oracle) - [ ] Bob Briscoe - Focus on smaller aspects of the problem to avoid a random walk. Need to determine if we are optimizing for the p2p traffic or the remaining interdomain traffic. Optimization is a balance - [ ] Unknown speaker - (missed comment - about difference between local link and interdomain links?) - [ ] Henning - One problem to consider is locating things like TURN servers. Is that in scope (presenter says yes). - [ ] Henning - Wanted to make sure we were talking about finding a service, not a file. - [ ] Ted Hardie - I think this is about right problem statement, but there should be some tweaks around describing what is "optimal", particularly separating the impact on local link and the network as a whole. Optimal may vary depending on the ALTO service. There should be a way to get information to edge elements to affect finding services. (discussion with chairs - is the scope restricted to interdomain optimization? - chairs say no - more discussion focu - [ ] Yunfei zhen - As an operator - supports having an ALTO like mechanism, but has concerns w/ the problem statement - [ ] even using opaque means, this might give too much information about local topology - [ ] can the operator influence peer selection (chairs/AD redirect conversation to mechanism discussion) - [ ] Dave Oran - Does the claim in the request allow 3rd party queries (answer is probably?) - [ ] ALTO Survey - [ ] Slides Presented - [ ] Henry - most ISPs don't own their facilities and may not be able to provide some of the information this work is asking for - the model doesn't reflect reality - [ ] Jon - Doubts that in an initial iteration we'd be carving off all the approaches just presented. We're certainly not setting up a beauty contest to canonize any particular approach. - [ ] Henning - Do all of the techniques just discussed fit easily into the model being proposed for the ALTO work? If there is existing work that doesn't easily fit we should understand why early. (Are there deficiencies in the model being proposed?) - [ ] Lars - Alto also needs to look at the semantics of the information on the interface, not just the bits. For instance, understanding the metrics for optimization is going to be one of the most important part of the discussions. - [ ] Lars - Alto should not be a mechanism for querying a disparate set of infromation providers (not interoperable on their own) - [ ] Lisa - Predicts that finding one metric for optimization is not going to happen (and certainly not in a bof) - [ ] Bandwidth costs - [ ] slides presented - - [ ] Henry - Most ISP have a different problem - lots of bandwidth in the center, but backhaul costs dominate. - [ ] Bob Briscoe - (refining henry's description of backhaul) - [ ] David Bryan - Cost is different to each observer (operator, end user). Would like _all_ participants to get information about the cost impact of each path. - [ ] Bob Briscoe - We need to be clear about the cost of providing bandwidth or the cost of using it. - [ ] Rich ? - As a cable operator the predominate cost is access network. Other charging models (average vs 95%) are emerging that will have an impact on optimization. And surprising end users with large bills is something we need to avoid. - [ ] Henning - having service suddenly drop off because you're in a penalty box without warning is also to be avoided. - [ ] ? - (from time warner) - trying to expose (or even use real) internal operator costs needs to be out of scope - [ ] unknown speaker - (missed the comment - something about surges in use) - [ ] ALTO requirements - [ ] slides presented - [ ] during presentation : Dave Oran : is there a requirement for the client to know the decay rate of the usefulness of the information its receiving is? (answer - we can consider lifetimes). Any measure like this would be a decay rate, not a lifetime. - [ ] Volker Hilt - (missed the comment) - [ ] Alan (missed last name) - question about peer selection - bias is towards client, but both sides should be involved - is there any work here that would go towards bi-directional peer selection? - [ ] Henry - Shouldn't the peer-to-peer providers be at the table? - [ ] Lars (during error handling and overload slide) - lets just agree to use TCP instead of going "lightweight" now and have something very complicated grow around it later. - [ ] Jason Livingood - There are usecases around content ids in both directions - sometimes we might want to provide them and sometimes not. - [ ] Caching and Peer Selection - [ ] slides presented - [ ] Dave Oran - There's a difference between a service that rates things you know about vrs a service that lets you discover things you don' t know about. Which is in scope for Alto? Do we combine discovery with rating? - [ ] Lisa - Is there anyone here who thinks they _must_ be combined? - [ ] Dave - Refining the terminology to differentiate discovering alto servers from discovering services would be helpful - [ ] Alan Arodvich(sp?) - w p2prep - So far we're only talking about the surface of the problem with caching. There are many more requirements to be captured beyond discovery. - [ ] Alto - Similar Problems - [ ] slides presented - [ ] no discussion - [ ] Charter discussion - [ ] slides presented - [ ] Ted - There seem to be classes of queries for the query protocol? (the things listed on the slide as discovery mechanisms for "special" nodes may need clarification). The Discovery problem is how do I find a useful oracle. Then you have a question about how do a get a candidate list to present to the oracle? Then you get to how do you use the query to the oracle to find one or more services. Which of these three do these work items address? - [ ] Jon - I don't think restriciting to just those 3 at this point in time is appropriate. We may separate things, surely, but not limit to a particular subset of them - [ ] Ted - Larger question is whether the scope in the charter covers work not directly related to the topics discussed so far (like finding TURN or 6to4 boxes). Trying to figure out if that general discovery problem is in scope. - [ ] Henning - we can either build separate protocols to solve the different kinds of questions or decide to build a tightly coupled set of protocols. Choosing now to put answers to all 3 of the questions in "One Oracle" right now feels like it constrains the discussion inappropriately. Generally speaking, separation is a good thing. We should not be talking about "The Oracle". - [ ] Dave - speechsc faced a similar question - one thing that helped was to get agreement on the difference between requirements and preconditions (things we assume are already solved some other way). One precondition might be that we rely on an existing discovery protocol to find ALTO servers, for example. This will help Alto avoid becoming a "must solve everything" problem - [ ] Jon - We will definitely have a requirement phase - the charter doesn't need to determine whether the requirements we write are satisfied by existing things or things this group produces. - [ ] Dave - The charter should also not prejudge - [ ] Jon - Today's discussion should focus on whether doing the work to define a standard service along these lines is something the IETF community is willing to take on. Lets keep this high level and identify discrete scope. - [ ] Hugh? (from microsoft) - Thinks discovery mechanism is a distraction - we should spend more time talking about what "best" means. - [ ] Greg Liebowitz - is the charter going to mandate an existing discovery protocol be used vs producing one here? - [ ] Jon - no. But I anticipate that after we go through requirements we will not likely choose an existing protocol. However, there will not be an item in the charter calling out developing a protocol until the requirements indicate its needed. - [ ] Greg - Bar should be high for a new protocol - and charter should explicitly capture that. - [ ] Dave - This question should be left to the requirements analysis phase. - [ ] Greg - if we do use an existing discovery mechanism, do we need to lump in other problems (like media relay discovery) in this effort, or should those go into existing working groups or a separate effort entirely. - [ ] Avshalom - There is a lot of overlap w/ p2psip - how much discussion of division of work has taken place - [ ] Lisa - The chairs and ADs have been talking about this and there seems to be use for this kind of work outside the p2psip context. - [ ] John Schnizlein - Can we partition out those things that have already been solved by, e.g. bittorrent, which things are being solved in other working groups, and then only focus here on what's left instead of the union of those three sets. - [ ] Henning - still have a terminology problem. A protocol, An oracle., etc.. Run the risk of having participants agreeing to move forward with widely different expectation about what the term "discovery" means. There's still confusion about such things as whether the type of content as part of a query is in scope or not. Would really rather break out explicit questions and argue their scope separately. - [ ] Lars - Tana (transport) will be all about congestion issues with p2p networks. Alto may or may not have other transport related issues. If you get to query it for long term information there should be no transport issues. But querying for fast changing information like load, delay or jitter is likely to lead to problems that should be solved at the transport level, not the application level - so they should be out of scope for Alto. - [ ] Ted - I think we should work on this problem space. The query response protocol is the easiest part of this. There are a whole set of semantic problems to work through and a requirements document may not be the best way to mine those - a separate design effort to answer those will make finishing a requirements document much simpler. - [ ] Call for a Hum on whether the IETF "should take on this work" - [ ] Clarified by Jon by pointing to the two task slide in the deck - [ ] Hum was inconclusive - some of the "no" hums were (in Jon's words) vehement. - [ ] Henry - (missed the comment) - [ ] Bruce - including the general form of discovering arbitrary things may take this into a 3-body problem (as opposed to a 2-body problem). - [ ] Lars - Agrees with bruce - the scope is too wide right now - if we limit what you can query the oracle for will make a better charter - [ ] Jonathan - If people don't think this is appropriate to do in the IETF, what do they think _is_? I support this - [ ] unknown speaker - still not comfortable with what the request should be about - [ ] Jon - the charter isn't going to call out what the metrics are or what the query should answer - that's the work we're talking about doing. - [ ] jason livingood - This is a big problem and we should work on it. - [ ] Laird Popkin - Strongly suggests we do this in the IETF instead of piece by piece - [ ] Ian - Agrees with Jonathan - we should do this - [ ] ? Shephard - would convert hum to a yes if we could make it more clear why an oracle model is the right model. Suspects we're pre-anticipating the solution - the discussion right now feels to researchy. - [ ] --Apple-Mail-140-1070175938 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit > --Apple-Mail-140-1070175938 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 --Apple-Mail-140-1070175938-- From p2pi-bounces@ietf.org Sun Aug 3 08:11: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 12E133A67ED; Sun, 3 Aug 2008 08:11: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 A51233A67ED for ; Sun, 3 Aug 2008 08:11:42 -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.055, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, 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 9vw8fXzorlS2 for ; Sun, 3 Aug 2008 08:11:41 -0700 (PDT) Received: from exprod7og108.obsmtp.com (exprod7og108.obsmtp.com [64.18.2.169]) by core3.amsl.com (Postfix) with ESMTP id E87CC3A67AE for ; Sun, 3 Aug 2008 08:11:40 -0700 (PDT) Received: from source ([66.129.228.6]) by exprod7ob108.postini.com ([64.18.6.12]) with SMTP; Sun, 03 Aug 2008 08:11:24 PDT Received: from emailwf1.jnpr.net ([10.10.2.33]) by p-emsmtp03.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Sun, 3 Aug 2008 08:11:32 -0700 Received: from proton.jnpr.net ([10.10.2.37]) by emailwf1.jnpr.net with Microsoft SMTPSVC(6.0.3790.1830); Sun, 3 Aug 2008 11:11:30 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Sun, 3 Aug 2008 11:11:02 -0400 Message-ID: <9BD5D7887235424FA97DFC223CAE3C28040ACD4F@proton.jnpr.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [p2pi] ALTO service privacy, performance, and architecture Thread-Index: Acj1WkyzEB603EasT3K6nsiOfoFMyAAHMX71 References: <1144783309.99011217762128498.JavaMail.root@dkny.pando.com> From: "Reinaldo Penno" To: "Laird Popkin" X-OriginalArrivalTime: 03 Aug 2008 15:11:30.0840 (UTC) FILETIME=[358EE980:01C8F57B] Cc: p2pi@ietf.org Subject: Re: [p2pi] ALTO service privacy, performance, and architecture X-BeenThere: p2pi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: P2P Infrastructure Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: p2pi-bounces@ietf.org Errors-To: p2pi-bounces@ietf.org -----Original Message----- From: Laird Popkin [mailto:laird@pando.com] Sent: Sun 8/3/2008 4:15 AM To: Reinaldo Penno Cc: p2pi@ietf.org; Richard Alimi Subject: Re: [p2pi] ALTO service privacy, performance, and architecture Regarding the question of whether users know about ALTO, I think that you're reading too much into ALTO. P2P networks already control who users connect to and exchange data with, transparently to users. ALTO doesn't change anything other than that the ISPs are providing some assistance. [reinaldo] yes, peer selection is random, and this randomness is a integral part of the algorithm and some argue one of its strengths. What we are saying is "instead of choosing peers randomly, give preference to these X instead". This changes the algorithm considerably. Regarding public tracker's incentives to implement this, I am not sure why you assume that they don't want their users to have fast download speeds. Users care a lot about download speeds, and would be happy to switch to whichever tracker gave them the best performance. And the people that run trackers care a lot about whether people use them. This is probably why, when I've talked to people that run trackers, they'd be very happy to implement a performance optimization that made their downloads faster. Their concerns are more regarding complexity of implementation, and in working with the ISPs to get the guidance. [reinaldo] I believe trackers want peers to have better download speeds, what I said is that today it already works well. If you talked to public trackers like thepiratebay, mininova and others and they are interested in exchanging info with ISPs that is interesting information. Regarding the statement that "a client can easily get access to a full BGP routing table and perform some optimizations itself", while theoretically a p2p client could retrieve and use full BGP tables, but in practice BGP routing tables are quite large and complex, so I'm not sure that I would call doing this 'easy' to the point where millions of desktop applications should be doing it. It's far more efficient for this kind of work to be done in a centralized server that the clients can query for guidance, IMO. [reinaldo] Yes and no. Both approaches have pros and cons. A centralized server is a single point of failure, needs to interface with the routers on the network to acquire such info since it is not part of the routing mesh. And if the client needs to ask for guidance it needs to send a list of IP/Prefixes/other to this centralized server every time it gets to know a new set of peers. If the policies are pushed (which can be done in a decentralized way), the client can apply the policies against the list of candidate peers. We can even use multicast to push such policies if the network supports it. Since the policies are network based (independent of torrrent), there is no need for the client to keep asking for policies every time it gets to know a new set of peers. That of course does not preclude a client from contacting its closest ALTO Service/Server (not a centralized one) and ask for guidance. - Laird Popkin, CTO, Pando Networks mobile: 646/465-0570 ----- Original Message ----- From: "Reinaldo Penno" To: "Laird Popkin" Cc: p2pi@ietf.org, "Richard Alimi" Sent: Sunday, August 3, 2008 2:03:31 AM (GMT-0500) America/New_York Subject: Re: [p2pi] ALTO service privacy, performance, and architecture On 8/2/08 9:09 PM, "Laird Popkin" wrote: > I don't think that p2p users will know or care about ALTO, any more than they > know or care about BGP, or HTTP proxies - things just work. ALTO will need to > be known about and implemented either by the p2p trackers or clients. At most > some applications might provide an ALTO check box as a preference setting, > just as they might allow for manual proxy configuration. At most or always? If you make it mandatory you are deciding on behalf of the users who he/she should connect and you are dealing in the net neutrality realm. I'm not sure MSO and Telcos want to go through FCC battles again. > > Answering the question "And the motivation for pirate trackers would be? ... > Improve performance seems slim.", I believe that there are two benefits, one > direct and one indirect. > > The direct benefit is that localizing data transfers improves download > performance for users significantly on average, which makes users happier. > While theoretically it shouldn't matter whether data is pulled from nearby > sources or far, in practice localizing data sources appears to improve > performance quite a bit. I can only guess what the cause of the improved > performance is (perhaps shorter RTT's improve TCP throughput, perhaps avoiding > congested internet gateways). In any case, we're seeing real world download > speeds double and triple for users on fast broadband connections (nothing will > speed up a slow broadband connection...). > > The indirect benefit is that by reducing the transit costs created by p2p > traffic, it reduces the incentives for ISPs to degrade p2p traffic. I was talking about what were the incentives for public trackers to perform optimizations. Your arguments seem to be ISP centric. Public trackers do not care or are very happy with the current download speeds of their users. Statistics from these trackers show more bandwidth consumed in a month than all itunes music sold to date. > > "Clients can potentially improve their own performance by choosing closer > peers based on IP addresses." How would they know which IP addresses are > closer? ALTO? As Stas suggested, a client can easily get access to a full BGP routing table and perform some optimizations itself. Is this ALTO? > > - Laird Popkin, CTO, Pando Networks > mobile: 646/465-0570 > > ----- Original Message ----- > From: "Reinaldo Penno" > To: "Laird Popkin" > Cc: p2pi@ietf.org, "Richard Alimi" > Sent: Saturday, August 2, 2008 10:58:44 PM (GMT-0500) America/New_York > Subject: Re: [p2pi] ALTO service privacy, performance, and architecture > > > > > On 8/2/08 7:35 PM, "Laird Popkin" wrote: > >> The P4P tests that were performed so far were performed with legal content so >> that we could focus on technical issues (e.g. implementing and running the >> tests) and not get caught in potentially lengthy policy discussions that >> (IMO) >> are only worth having once the technology demonstrates its value. The test >> results have been very good, so I suspect that the policy discussions will >> start taking place. There's no technical issue limiting who uses P4P (and, I >> hope, ALTO). Given this, I believe that each ISP can decide its own policies >> regarding who it wants to share what information with. > > Understood. > >> >> Keep in mind that ALTO servers can be run by entities other than ISPs. So if >> ISPs don't want to work with pirate trackers, the pirate trackers might join >> together to set up an ALTO server populated using whatever network >> information >> they can collect or determine (e.g. ASN adjacency maps) to improve >> performance >> for their users. > > And the motivation for pirate trackers would be? There is no business > relationship between P2P clients and their public trackers. Improve > performance seems slim. Clients can potentially improve their own > performance by choosing closer peers based on IP addresses. > >> >> Finally, ALTO servers should be accessible by either clients or servers, so >> it >> may be the case that even if ISPs don't want to work with pirate trackers, >> they might approve working with user p2p clients, which would achieve a >> similar result. > > The latter requires a leap of faith. That's where I think we have different > opinions. I think we need to make sure P2P users are on-board. BTW, by P2P > clients you mean the P2P software or P2P users? > > Thanks, > > Reinaldo >> >> - Laird Popkin, CTO, Pando Networks >> mobile: 646/465-0570 >> >> ----- Original Message ----- >> From: "Reinaldo Penno" >> To: "Richard Alimi" >> Cc: p2pi@ietf.org >> Sent: Saturday, August 2, 2008 10:10:11 PM (GMT-0500) America/New_York >> Subject: Re: [p2pi] ALTO service privacy, performance, and architecture >> >> Hi, >> >> Thanks for your answers. Comments inline. >> >> On 8/2/08 6:11 PM, "Richard Alimi" wrote: >> >>>> I just want to remind that we are here because of file-sharing and not >>>> really closed P2P networks where itrackers, apptrackers and others >>>> cooperate nicely. This is the easy case and today does not cause problems >>>> to ISPs. And maybe never will. >>> >>> Let me make one clarification to your statement above. The itracker in P4P >>> is >>> not application specific, and thus is not part of any closed system. It can >>> be queried by many P2P applications, and does not keep any swarm state. The >>> field tests have been done with Pando, but nothing restricts it from being >>> used for "public" P2P networks. >>> >>> Or did I misinterpret your meaning of "closed"? >> >> Closed as in the sense that it assumes cooperation from the AppTracker. >> Otherwise how can it not keep any swarm state? This is is based on the >> functionality from your paper. >> >> Anyway, the two statements seem contradictory. The corollary is that the >> content that such clients access are those of the P2P CDN and not pirated >> content. The P4P trials that I have heard/read are based on legal content. >> Please correct me if I'm wrong. >> >>> >>>> So, when you say "tracker-less" systems you mean a P2P network without a >>>> tracker (Gnutella) or a P2P network where the tracker is something like >>>> thepiratebay? The two 'systems' (as you put it) are quite different. >>> >>> By "tracker-less," I was referring to a P2P network without a tracker. We >>> consider thepiratebay a tracker-based system. >>> >>>> In the case where there is a tracker on the Internet that does not >>>> cooperate (which is 99.99% of P2P traffic today) I'm not sure how ALTO >>>> would work without the ISP tracker pushing information to the clients >>>> (since the clients might not send info to the tracker). >>> >>> I agree that to cover the majority of the P2P traffic, it may be mostly be >>> client-dependent in the beginning. >>> >>> The idea, however, is that as time goes on P2P developers and ISPs will each >>> realize the benefits (better performance for P2P apps, and achieve >>> particular >>> network goals for ISPs) and begin support. Integration should be simple >>> enough that P2P developers understand and use it. >> >> It is not P2P developers that need to be convinced. It is the users, the >> human factor. >> >> And if ALTO does not "get it" that it is not just about having a >> client-server protocol, I'm not sure of the benefits. Yeah, Pando or Joost >> users can be convinced of using it, but how about the other users that are >> responsible for 99.9% of traffic? And if they cannot be convinced, can ALTO >> still do some form of optimization? This goes back to security and privacy. >> >>> >>>> For private trackers (which have the really hardcore users) it is not clear >>>> how ALTO can influence their behavior since the whole point is to stay >>>> within the private tracker's given peers. If we cannot tackle these two >>>> scenarios, ISPs continue to suffer. >>> >>> Interesting point. If there are limited peers in a swarm, then there are >>> limited opportunities for optimization (both for the P2P and ISP side). Is >>> this a fundamental limit, though? Aside, of course, from "telling" them that >>> their swarms should be larger :) >> >> Well, peers driven by private trackers are the elite. They do not really >> need a big swarm since these are folks that have their computers on 24x7 and >> have Seedboxes. Most of the time they have co-location boxes and/or pay >> enterprise fees to have tons of bandwidth. >> >>> >>> Getting adoption in major public P2P clients/trackers is certainly important >>> in order for this to make a large difference for ISP networks. >> >> I believe, as I said before, that we need to convince users. The only way to >> convince such users is if we have a tight (very tight) security, privacy >> model. Otherwise the ALTO protocol might not see use in the wild. >> >> As far as convincing public trackers also means convincing the ISP to have a >> relationship with such trackers as thepiratebay. Does Comcast or BT want to >> have such relationship? I have no idea. I guess my point is that the >> business/realities of P2P networks should drive the requirements so we can >> work with (or around them). >> >> Thanks, >> >> Reinaldo >> >> >> _______________________________________________ >> p2pi mailing list >> p2pi@ietf.org >> https://www.ietf.org/mailman/listinfo/p2pi > > _______________________________________________ p2pi mailing list p2pi@ietf.org https://www.ietf.org/mailman/listinfo/p2pi From p2pi-bounces@ietf.org Sun Aug 3 08:50:01 2008 Return-Path: X-Original-To: p2pi-archive@ietf.org Delivered-To: ietfarch-p2pi-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5CDC73A6830; Sun, 3 Aug 2008 08:50:01 -0700 (PDT) X-Original-To: p2pi@core3.amsl.com Delivered-To: p2pi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4088B3A66B4 for ; Sun, 3 Aug 2008 08:50:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.061 X-Spam-Level: X-Spam-Status: No, score=-10.061 tagged_above=-999 required=5 tests=[AWL=-0.111, 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 qcqj-RB+Drg9 for ; Sun, 3 Aug 2008 08:49:58 -0700 (PDT) Received: from dkny.pando.com (dkny.pando.com [67.99.55.163]) by core3.amsl.com (Postfix) with ESMTP id E99C83A6A8E for ; Sun, 3 Aug 2008 08:49:42 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by dkny.pando.com (Postfix) with ESMTP id 3BF98E10A1E; Sun, 3 Aug 2008 11:50: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 W5ysFdSqMDEv; Sun, 3 Aug 2008 11:49:54 -0400 (EDT) Received: from dkny.pando.com (dkny.pando.com [10.10.60.11]) by dkny.pando.com (Postfix) with ESMTP id D2F0FE10A03; Sun, 3 Aug 2008 11:49:54 -0400 (EDT) Date: Sun, 3 Aug 2008 11:49:54 -0400 (EDT) From: Laird Popkin To: Reinaldo Penno Message-ID: <82886509.99161217778594823.JavaMail.root@dkny.pando.com> In-Reply-To: <9BD5D7887235424FA97DFC223CAE3C28040ACD4F@proton.jnpr.net> MIME-Version: 1.0 X-Originating-IP: [71.187.207.81] Cc: p2pi@ietf.org Subject: Re: [p2pi] ALTO service privacy, performance, and architecture X-BeenThere: p2pi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: P2P Infrastructure Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: p2pi-bounces@ietf.org Errors-To: p2pi-bounces@ietf.org Comments below: - Laird Popkin, CTO, Pando Networks mobile: 646/465-0570 ----- Original Message ----- From: "Reinaldo Penno" To: "Laird Popkin" Cc: p2pi@ietf.org, "Richard Alimi" Sent: Sunday, August 3, 2008 11:11:02 AM (GMT-0500) America/New_York Subject: RE: [p2pi] ALTO service privacy, performance, and architecture -----Original Message----- From: Laird Popkin [mailto:laird@pando.com] Sent: Sun 8/3/2008 4:15 AM To: Reinaldo Penno Cc: p2pi@ietf.org; Richard Alimi Subject: Re: [p2pi] ALTO service privacy, performance, and architecture Regarding the question of whether users know about ALTO, I think that you're reading too much into ALTO. P2P networks already control who users connect to and exchange data with, transparently to users. ALTO doesn't change anything other than that the ISPs are providing some assistance. [reinaldo] yes, peer selection is random, and this randomness is a integral part of the algorithm and some argue one of its strengths. What we are saying is "instead of choosing peers randomly, give preference to these X instead". This changes the algorithm considerably. [laird] Not really. All P2P networks make decisions about which peers to exchange data between in order to optimize p2p performance. ALTO would be an additional input into that decision. Regarding public tracker's incentives to implement this, I am not sure why you assume that they don't want their users to have fast download speeds. Users care a lot about download speeds, and would be happy to switch to whichever tracker gave them the best performance. And the people that run trackers care a lot about whether people use them. This is probably why, when I've talked to people that run trackers, they'd be very happy to implement a performance optimization that made their downloads faster. Their concerns are more regarding complexity of implementation, and in working with the ISPs to get the guidance. [reinaldo] I believe trackers want peers to have better download speeds, what I said is that today it already works well. If you talked to public trackers like thepiratebay, mininova and others and they are interested in exchanging info with ISPs that is interesting information. [laird] While it's true that p2p networks already work well, it also appears to be true that there's significant room for improvement. Specifically, in field testing localizing traffic significantly improves performance when compared to pure random peer connections. As I wrote earlier, I can't prove why this occurs, but I can certainly document that downloads that localize transfers are on average significantly faster than downloads that don't do so. It may be caused by TCP operating better with shorter RTT's. It might be avoiding ISP's saturated internal or external links, or even general internet traffic. But it seems clear that localizing traffic benefits performance on average. Given this, tracker sites appear to have a clear incentive to improve performance by implementing traffic localization. Regarding the statement that "a client can easily get access to a full BGP routing table and perform some optimizations itself", while theoretically a p2p client could retrieve and use full BGP tables, but in practice BGP routing tables are quite large and complex, so I'm not sure that I would call doing this 'easy' to the point where millions of desktop applications should be doing it. It's far more efficient for this kind of work to be done in a centralized server that the clients can query for guidance, IMO. [reinaldo] Yes and no. Both approaches have pros and cons. A centralized server is a single point of failure, needs to interface with the routers on the network to acquire such info since it is not part of the routing mesh. And if the client needs to ask for guidance it needs to send a list of IP/Prefixes/other to this centralized server every time it gets to know a new set of peers. If the policies are pushed (which can be done in a decentralized way), the client can apply the policies against the list of candidate peers. We can even use multicast to push such policies if the network supports it. Since the policies are network based (independent of torrrent), there is no need for the client to keep asking for policies every time it gets to know a new set of peers. That of course does not preclude a client from contacting its closest ALTO Service/Server (not a centralized one) and ask for guidance. [laird] I certainly agree that there are both centralized and decentralized p2p networks. My point was that even if theoretically every p2p client could retrieve and process the ISP's full BGP tables, practically speaking that doesn't preclude the value of a central server that does that work and makes the results available in a more compact, easily processable, standardized format. - Laird Popkin, CTO, Pando Networks mobile: 646/465-0570 ----- Original Message ----- From: "Reinaldo Penno" To: "Laird Popkin" Cc: p2pi@ietf.org, "Richard Alimi" Sent: Sunday, August 3, 2008 2:03:31 AM (GMT-0500) America/New_York Subject: Re: [p2pi] ALTO service privacy, performance, and architecture On 8/2/08 9:09 PM, "Laird Popkin" wrote: > I don't think that p2p users will know or care about ALTO, any more than they > know or care about BGP, or HTTP proxies - things just work. ALTO will need to > be known about and implemented either by the p2p trackers or clients. At most > some applications might provide an ALTO check box as a preference setting, > just as they might allow for manual proxy configuration. At most or always? If you make it mandatory you are deciding on behalf of the users who he/she should connect and you are dealing in the net neutrality realm. I'm not sure MSO and Telcos want to go through FCC battles again. > > Answering the question "And the motivation for pirate trackers would be? ... > Improve performance seems slim.", I believe that there are two benefits, one > direct and one indirect. > > The direct benefit is that localizing data transfers improves download > performance for users significantly on average, which makes users happier. > While theoretically it shouldn't matter whether data is pulled from nearby > sources or far, in practice localizing data sources appears to improve > performance quite a bit. I can only guess what the cause of the improved > performance is (perhaps shorter RTT's improve TCP throughput, perhaps avoiding > congested internet gateways). In any case, we're seeing real world download > speeds double and triple for users on fast broadband connections (nothing will > speed up a slow broadband connection...). > > The indirect benefit is that by reducing the transit costs created by p2p > traffic, it reduces the incentives for ISPs to degrade p2p traffic. I was talking about what were the incentives for public trackers to perform optimizations. Your arguments seem to be ISP centric. Public trackers do not care or are very happy with the current download speeds of their users. Statistics from these trackers show more bandwidth consumed in a month than all itunes music sold to date. > > "Clients can potentially improve their own performance by choosing closer > peers based on IP addresses." How would they know which IP addresses are > closer? ALTO? As Stas suggested, a client can easily get access to a full BGP routing table and perform some optimizations itself. Is this ALTO? > > - Laird Popkin, CTO, Pando Networks > mobile: 646/465-0570 > > ----- Original Message ----- > From: "Reinaldo Penno" > To: "Laird Popkin" > Cc: p2pi@ietf.org, "Richard Alimi" > Sent: Saturday, August 2, 2008 10:58:44 PM (GMT-0500) America/New_York > Subject: Re: [p2pi] ALTO service privacy, performance, and architecture > > > > > On 8/2/08 7:35 PM, "Laird Popkin" wrote: > >> The P4P tests that were performed so far were performed with legal content so >> that we could focus on technical issues (e.g. implementing and running the >> tests) and not get caught in potentially lengthy policy discussions that >> (IMO) >> are only worth having once the technology demonstrates its value. The test >> results have been very good, so I suspect that the policy discussions will >> start taking place. There's no technical issue limiting who uses P4P (and, I >> hope, ALTO). Given this, I believe that each ISP can decide its own policies >> regarding who it wants to share what information with. > > Understood. > >> >> Keep in mind that ALTO servers can be run by entities other than ISPs. So if >> ISPs don't want to work with pirate trackers, the pirate trackers might join >> together to set up an ALTO server populated using whatever network >> information >> they can collect or determine (e.g. ASN adjacency maps) to improve >> performance >> for their users. > > And the motivation for pirate trackers would be? There is no business > relationship between P2P clients and their public trackers. Improve > performance seems slim. Clients can potentially improve their own > performance by choosing closer peers based on IP addresses. > >> >> Finally, ALTO servers should be accessible by either clients or servers, so >> it >> may be the case that even if ISPs don't want to work with pirate trackers, >> they might approve working with user p2p clients, which would achieve a >> similar result. > > The latter requires a leap of faith. That's where I think we have different > opinions. I think we need to make sure P2P users are on-board. BTW, by P2P > clients you mean the P2P software or P2P users? > > Thanks, > > Reinaldo >> >> - Laird Popkin, CTO, Pando Networks >> mobile: 646/465-0570 >> >> ----- Original Message ----- >> From: "Reinaldo Penno" >> To: "Richard Alimi" >> Cc: p2pi@ietf.org >> Sent: Saturday, August 2, 2008 10:10:11 PM (GMT-0500) America/New_York >> Subject: Re: [p2pi] ALTO service privacy, performance, and architecture >> >> Hi, >> >> Thanks for your answers. Comments inline. >> >> On 8/2/08 6:11 PM, "Richard Alimi" wrote: >> >>>> I just want to remind that we are here because of file-sharing and not >>>> really closed P2P networks where itrackers, apptrackers and others >>>> cooperate nicely. This is the easy case and today does not cause problems >>>> to ISPs. And maybe never will. >>> >>> Let me make one clarification to your statement above. The itracker in P4P >>> is >>> not application specific, and thus is not part of any closed system. It can >>> be queried by many P2P applications, and does not keep any swarm state. The >>> field tests have been done with Pando, but nothing restricts it from being >>> used for "public" P2P networks. >>> >>> Or did I misinterpret your meaning of "closed"? >> >> Closed as in the sense that it assumes cooperation from the AppTracker. >> Otherwise how can it not keep any swarm state? This is is based on the >> functionality from your paper. >> >> Anyway, the two statements seem contradictory. The corollary is that the >> content that such clients access are those of the P2P CDN and not pirated >> content. The P4P trials that I have heard/read are based on legal content. >> Please correct me if I'm wrong. >> >>> >>>> So, when you say "tracker-less" systems you mean a P2P network without a >>>> tracker (Gnutella) or a P2P network where the tracker is something like >>>> thepiratebay? The two 'systems' (as you put it) are quite different. >>> >>> By "tracker-less," I was referring to a P2P network without a tracker. We >>> consider thepiratebay a tracker-based system. >>> >>>> In the case where there is a tracker on the Internet that does not >>>> cooperate (which is 99.99% of P2P traffic today) I'm not sure how ALTO >>>> would work without the ISP tracker pushing information to the clients >>>> (since the clients might not send info to the tracker). >>> >>> I agree that to cover the majority of the P2P traffic, it may be mostly be >>> client-dependent in the beginning. >>> >>> The idea, however, is that as time goes on P2P developers and ISPs will each >>> realize the benefits (better performance for P2P apps, and achieve >>> particular >>> network goals for ISPs) and begin support. Integration should be simple >>> enough that P2P developers understand and use it. >> >> It is not P2P developers that need to be convinced. It is the users, the >> human factor. >> >> And if ALTO does not "get it" that it is not just about having a >> client-server protocol, I'm not sure of the benefits. Yeah, Pando or Joost >> users can be convinced of using it, but how about the other users that are >> responsible for 99.9% of traffic? And if they cannot be convinced, can ALTO >> still do some form of optimization? This goes back to security and privacy. >> >>> >>>> For private trackers (which have the really hardcore users) it is not clear >>>> how ALTO can influence their behavior since the whole point is to stay >>>> within the private tracker's given peers. If we cannot tackle these two >>>> scenarios, ISPs continue to suffer. >>> >>> Interesting point. If there are limited peers in a swarm, then there are >>> limited opportunities for optimization (both for the P2P and ISP side). Is >>> this a fundamental limit, though? Aside, of course, from "telling" them that >>> their swarms should be larger :) >> >> Well, peers driven by private trackers are the elite. They do not really >> need a big swarm since these are folks that have their computers on 24x7 and >> have Seedboxes. Most of the time they have co-location boxes and/or pay >> enterprise fees to have tons of bandwidth. >> >>> >>> Getting adoption in major public P2P clients/trackers is certainly important >>> in order for this to make a large difference for ISP networks. >> >> I believe, as I said before, that we need to convince users. The only way to >> convince such users is if we have a tight (very tight) security, privacy >> model. Otherwise the ALTO protocol might not see use in the wild. >> >> As far as convincing public trackers also means convincing the ISP to have a >> relationship with such trackers as thepiratebay. Does Comcast or BT want to >> have such relationship? I have no idea. I guess my point is that the >> business/realities of P2P networks should drive the requirements so we can >> work with (or around them). >> >> Thanks, >> >> Reinaldo >> >> >> _______________________________________________ >> p2pi mailing list >> p2pi@ietf.org >> https://www.ietf.org/mailman/listinfo/p2pi > > _______________________________________________ p2pi mailing list p2pi@ietf.org https://www.ietf.org/mailman/listinfo/p2pi From p2pi-bounces@ietf.org Sun Aug 3 09:16: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 CAD033A69EE; Sun, 3 Aug 2008 09:16: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 4F1F63A69EE for ; Sun, 3 Aug 2008 09:16:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.74 X-Spam-Level: X-Spam-Status: No, score=-1.74 tagged_above=-999 required=5 tests=[BAYES_20=-0.74, 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 JhOw8yQpDZ0C for ; Sun, 3 Aug 2008 09:16:13 -0700 (PDT) Received: from brinza.cc.columbia.edu (brinza.cc.columbia.edu [128.59.29.8]) by core3.amsl.com (Postfix) with ESMTP id 6FBBB3A67F5 for ; Sun, 3 Aug 2008 09:16:13 -0700 (PDT) Received: from [192.168.0.61] (pool-70-21-180-133.nwrk.east.verizon.net [70.21.180.133]) (user=hgs10 mech=PLAIN bits=0) by brinza.cc.columbia.edu (8.14.1/8.14.1) with ESMTP id m73GGWN4017134 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Sun, 3 Aug 2008 12:16:32 -0400 (EDT) Message-Id: From: Henning Schulzrinne To: p2pi@ietf.org In-Reply-To: <74CCBBDF76102846AFA7B29F3A98D3F601940660@PACDCEXCMB06.cable.comcast.com> Mime-Version: 1.0 (Apple Message framework v926) Date: Sun, 3 Aug 2008 12:16:31 -0400 References: <1232737442.90411217507981759.JavaMail.root@dkny.pando.com><1959788251.90461217508317275.JavaMail.root@dkny.pando.com> <200807311754.m6VHsBVg000355@bagheera.jungle.bt.co.uk> <74CCBBDF76102846AFA7B29F3A98D3F601940660@PACDCEXCMB06.cable.comcast.com> X-Mailer: Apple Mail (2.926) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.63 on 128.59.29.8 Cc: "Woundy, Richard" Subject: [p2pi] Costs X-BeenThere: p2pi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: P2P Infrastructure Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: p2pi-bounces@ietf.org Errors-To: p2pi-bounces@ietf.org > I'm changing the subject line, as the previous one has become somewhat uninformative. > BTW, I have heard that for other ISPs, transit costs *are* a > fundamental issue. And not just in the so-called "third world". There are many types of "ISPs", to it's hard to generalize. One class of ISPs that definitely falls into this category are large universities, a favorite location of P2P activity, both upload and download. Universities can often relatively easily upgrade their own internal networks, but we pay real $/Mb for commercial Internet access. As I mentioned, costs are essentially four-tiered: "free/ unbounded" for the same large Ethernet switch (say, a dorm), "free/but bounded capacity" inside campus, "cheap/plenty of capacity" to Internet2 universities and "expensive/bottlenecked" to the commercial Internet. I suspect that many large, multi-site corporations fall into roughly similar divisions, although they typically don't serve upload traffic outside their firewalls. There are also lots of issues of capital costs (upgrading access and backhaul) vs. operational expenses (such as peering/bandwidth charges). Some costs are essentially linear with (monthly) usage, others only occur when a capacity upgrade is needed. As long as we understand the distance in the term "localization" to be measured in dollars (or your local more-valuable, currency) and/or download bandwidth, not miles, we don't really have to play the "my ISP model is better than your ISP model" game. In some cases, these trade-offs are only known to the ISP, so if a third party runs an information service, it will have to extrapolate from typical conditions. Henning _______________________________________________ p2pi mailing list p2pi@ietf.org https://www.ietf.org/mailman/listinfo/p2pi From p2pi-bounces@ietf.org Sun Aug 3 10:53: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 BD9DC3A6BB9; Sun, 3 Aug 2008 10:53: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 A746D3A6BB9 for ; Sun, 3 Aug 2008 10:53:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.233 X-Spam-Level: X-Spam-Status: No, score=-6.233 tagged_above=-999 required=5 tests=[AWL=0.051, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, 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 dr3AQ196IShw for ; Sun, 3 Aug 2008 10:53:32 -0700 (PDT) Received: from exprod7og102.obsmtp.com (exprod7og102.obsmtp.com [64.18.2.157]) by core3.amsl.com (Postfix) with ESMTP id 92BD13A68C2 for ; Sun, 3 Aug 2008 10:53:30 -0700 (PDT) Received: from source ([66.129.228.6]) by exprod7ob102.postini.com ([64.18.6.12]) with SMTP; Sun, 03 Aug 2008 10:53:56 PDT Received: from antipi.jnpr.net ([10.10.2.34]) by p-emsmtp03.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Sun, 3 Aug 2008 10:52:21 -0700 Received: from proton.jnpr.net ([10.10.2.37]) by antipi.jnpr.net with Microsoft SMTPSVC(6.0.3790.1830); Sun, 3 Aug 2008 13:52:20 -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 ; Sun, 3 Aug 2008 17:52:19 +0000 User-Agent: Microsoft-Entourage/12.11.0.080522 Date: Sun, 03 Aug 2008 10:52:16 -0700 From: Reinaldo Penno To: Laird Popkin Message-ID: Thread-Topic: [p2pi] ALTO service privacy, performance, and architecture Thread-Index: Acj1kaqFbKPDVOhXd0uzgICpvOuW5g== In-Reply-To: <82886509.99161217778594823.JavaMail.root@dkny.pando.com> Mime-version: 1.0 X-OriginalArrivalTime: 03 Aug 2008 17:52:20.0356 (UTC) FILETIME=[AD1E3440:01C8F591] Cc: p2pi@ietf.org Subject: Re: [p2pi] ALTO service privacy, performance, and architecture X-BeenThere: p2pi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: P2P Infrastructure Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: p2pi-bounces@ietf.org Errors-To: p2pi-bounces@ietf.org Do not take BGP routing table as a proposed solution. It was just an example. Maybe not a good one for the sake of this discussion. The point I was trying to get across is that ISPs can push policies (the result of the decentralized computation) to clients and they can use these policies as they see fit, using whatever algorithm they want. This way clients do not need to send info about peers to the ISP. On 8/3/08 8:49 AM, "Laird Popkin" wrote: > Comments below: > > - Laird Popkin, CTO, Pando Networks > mobile: 646/465-0570 > > ----- Original Message ----- > From: "Reinaldo Penno" > To: "Laird Popkin" > Cc: p2pi@ietf.org, "Richard Alimi" > Sent: Sunday, August 3, 2008 11:11:02 AM (GMT-0500) America/New_York > Subject: RE: [p2pi] ALTO service privacy, performance, and architecture > > > > > -----Original Message----- > From: Laird Popkin [mailto:laird@pando.com] > Sent: Sun 8/3/2008 4:15 AM > To: Reinaldo Penno > Cc: p2pi@ietf.org; Richard Alimi > Subject: Re: [p2pi] ALTO service privacy, performance, and architecture > > Regarding the question of whether users know about ALTO, I think that you're > reading too much into ALTO. P2P networks already control who users connect to > and exchange data with, transparently to users. ALTO doesn't change anything > other than that the ISPs are providing some assistance. > > [reinaldo] > > yes, peer selection is random, and this randomness is a integral part of the > algorithm and some argue one of its strengths. What we are saying is "instead > of choosing peers randomly, give preference to these X instead". This changes > the algorithm considerably. > > [laird] Not really. All P2P networks make decisions about which peers to > exchange data between in order to optimize p2p performance. ALTO would be an > additional input into that decision. > > Regarding public tracker's incentives to implement this, I am not sure why you > assume that they don't want their users to have fast download speeds. Users > care a lot about download speeds, and would be happy to switch to whichever > tracker gave them the best performance. And the people that run trackers care > a lot about whether people use them. This is probably why, when I've talked to > people that run trackers, they'd be very happy to implement a performance > optimization that made their downloads faster. Their concerns are more > regarding complexity of implementation, and in working with the ISPs to get > the guidance. > > [reinaldo] > > I believe trackers want peers to have better download speeds, what I said is > that today it already works well. If you talked to public trackers like > thepiratebay, mininova and others and they are interested in exchanging info > with ISPs that is interesting information. > > [laird] While it's true that p2p networks already work well, it also appears > to be true that there's significant room for improvement. Specifically, in > field testing localizing traffic significantly improves performance when > compared to pure random peer connections. As I wrote earlier, I can't prove > why this occurs, but I can certainly document that downloads that localize > transfers are on average significantly faster than downloads that don't do so. > It may be caused by TCP operating better with shorter RTT's. It might be > avoiding ISP's saturated internal or external links, or even general internet > traffic. But it seems clear that localizing traffic benefits performance on > average. > > Given this, tracker sites appear to have a clear incentive to improve > performance by implementing traffic localization. > > Regarding the statement that "a client can easily get access to a full BGP > routing table and perform some optimizations itself", while theoretically a > p2p client could retrieve and use full BGP tables, but in practice BGP routing > tables are quite large and complex, so I'm not sure that I would call doing > this 'easy' to the point where millions of desktop applications should be > doing it. It's far more efficient for this kind of work to be done in a > centralized server that the clients can query for guidance, IMO. > > [reinaldo] > > Yes and no. Both approaches have pros and cons. > > A centralized server is a single point of failure, needs to interface with the > routers on the network to acquire such info since it is not part of the > routing mesh. And if the client needs to ask for guidance it needs to send a > list of IP/Prefixes/other to this centralized server every time it gets to > know a new set of peers. > > If the policies are pushed (which can be done in a decentralized way), the > client can apply the policies against the list of candidate peers. We can > even use multicast to push such policies if the network supports it. Since > the policies are network based (independent of torrrent), there is no need for > the client to keep asking for policies every time it gets to know a new set of > peers. That of course does not preclude a client from contacting its closest > ALTO Service/Server (not a centralized one) and ask for guidance. > > [laird] I certainly agree that there are both centralized and decentralized > p2p networks. My point was that even if theoretically every p2p client could > retrieve and process the ISP's full BGP tables, practically speaking that > doesn't preclude the value of a central server that does that work and makes > the results available in a more compact, easily processable, standardized > format. > > - Laird Popkin, CTO, Pando Networks > mobile: 646/465-0570 > > ----- Original Message ----- > From: "Reinaldo Penno" > To: "Laird Popkin" > Cc: p2pi@ietf.org, "Richard Alimi" > Sent: Sunday, August 3, 2008 2:03:31 AM (GMT-0500) America/New_York > Subject: Re: [p2pi] ALTO service privacy, performance, and architecture > > > > > On 8/2/08 9:09 PM, "Laird Popkin" wrote: > >> I don't think that p2p users will know or care about ALTO, any more than they >> know or care about BGP, or HTTP proxies - things just work. ALTO will need to >> be known about and implemented either by the p2p trackers or clients. At most >> some applications might provide an ALTO check box as a preference setting, >> just as they might allow for manual proxy configuration. > > At most or always? If you make it mandatory you are deciding on behalf of > the users who he/she should connect and you are dealing in the net > neutrality realm. I'm not sure MSO and Telcos want to go through FCC battles > again. > >> >> Answering the question "And the motivation for pirate trackers would be? ... >> Improve performance seems slim.", I believe that there are two benefits, one >> direct and one indirect. >> >> The direct benefit is that localizing data transfers improves download >> performance for users significantly on average, which makes users happier. >> While theoretically it shouldn't matter whether data is pulled from nearby >> sources or far, in practice localizing data sources appears to improve >> performance quite a bit. I can only guess what the cause of the improved >> performance is (perhaps shorter RTT's improve TCP throughput, perhaps >> avoiding >> congested internet gateways). In any case, we're seeing real world download >> speeds double and triple for users on fast broadband connections (nothing >> will >> speed up a slow broadband connection...). >> >> The indirect benefit is that by reducing the transit costs created by p2p >> traffic, it reduces the incentives for ISPs to degrade p2p traffic. > > I was talking about what were the incentives for public trackers to perform > optimizations. Your arguments seem to be ISP centric. Public trackers do not > care or are very happy with the current download speeds of their users. > Statistics from these trackers show more bandwidth consumed in a month than > all itunes music sold to date. > >> >> "Clients can potentially improve their own performance by choosing closer >> peers based on IP addresses." How would they know which IP addresses are >> closer? ALTO? > > As Stas suggested, a client can easily get access to a full BGP routing > table and perform some optimizations itself. Is this ALTO? > > >> >> - Laird Popkin, CTO, Pando Networks >> mobile: 646/465-0570 >> >> ----- Original Message ----- >> From: "Reinaldo Penno" >> To: "Laird Popkin" >> Cc: p2pi@ietf.org, "Richard Alimi" >> Sent: Saturday, August 2, 2008 10:58:44 PM (GMT-0500) America/New_York >> Subject: Re: [p2pi] ALTO service privacy, performance, and architecture >> >> >> >> >> On 8/2/08 7:35 PM, "Laird Popkin" wrote: >> >>> The P4P tests that were performed so far were performed with legal content >>> so >>> that we could focus on technical issues (e.g. implementing and running the >>> tests) and not get caught in potentially lengthy policy discussions that >>> (IMO) >>> are only worth having once the technology demonstrates its value. The test >>> results have been very good, so I suspect that the policy discussions will >>> start taking place. There's no technical issue limiting who uses P4P (and, I >>> hope, ALTO). Given this, I believe that each ISP can decide its own policies >>> regarding who it wants to share what information with. >> >> Understood. >> >>> >>> Keep in mind that ALTO servers can be run by entities other than ISPs. So if >>> ISPs don't want to work with pirate trackers, the pirate trackers might join >>> together to set up an ALTO server populated using whatever network >>> information >>> they can collect or determine (e.g. ASN adjacency maps) to improve >>> performance >>> for their users. >> >> And the motivation for pirate trackers would be? There is no business >> relationship between P2P clients and their public trackers. Improve >> performance seems slim. Clients can potentially improve their own >> performance by choosing closer peers based on IP addresses. >> >>> >>> Finally, ALTO servers should be accessible by either clients or servers, so >>> it >>> may be the case that even if ISPs don't want to work with pirate trackers, >>> they might approve working with user p2p clients, which would achieve a >>> similar result. >> >> The latter requires a leap of faith. That's where I think we have different >> opinions. I think we need to make sure P2P users are on-board. BTW, by P2P >> clients you mean the P2P software or P2P users? >> >> Thanks, >> >> Reinaldo >>> >>> - Laird Popkin, CTO, Pando Networks >>> mobile: 646/465-0570 >>> >>> ----- Original Message ----- >>> From: "Reinaldo Penno" >>> To: "Richard Alimi" >>> Cc: p2pi@ietf.org >>> Sent: Saturday, August 2, 2008 10:10:11 PM (GMT-0500) America/New_York >>> Subject: Re: [p2pi] ALTO service privacy, performance, and architecture >>> >>> Hi, >>> >>> Thanks for your answers. Comments inline. >>> >>> On 8/2/08 6:11 PM, "Richard Alimi" wrote: >>> >>>>> I just want to remind that we are here because of file-sharing and not >>>>> really closed P2P networks where itrackers, apptrackers and others >>>>> cooperate nicely. This is the easy case and today does not cause problems >>>>> to ISPs. And maybe never will. >>>> >>>> Let me make one clarification to your statement above. The itracker in P4P >>>> is >>>> not application specific, and thus is not part of any closed system. It >>>> can >>>> be queried by many P2P applications, and does not keep any swarm state. >>>> The >>>> field tests have been done with Pando, but nothing restricts it from being >>>> used for "public" P2P networks. >>>> >>>> Or did I misinterpret your meaning of "closed"? >>> >>> Closed as in the sense that it assumes cooperation from the AppTracker. >>> Otherwise how can it not keep any swarm state? This is is based on the >>> functionality from your paper. >>> >>> Anyway, the two statements seem contradictory. The corollary is that the >>> content that such clients access are those of the P2P CDN and not pirated >>> content. The P4P trials that I have heard/read are based on legal content. >>> Please correct me if I'm wrong. >>> >>>> >>>>> So, when you say "tracker-less" systems you mean a P2P network without a >>>>> tracker (Gnutella) or a P2P network where the tracker is something like >>>>> thepiratebay? The two 'systems' (as you put it) are quite different. >>>> >>>> By "tracker-less," I was referring to a P2P network without a tracker. We >>>> consider thepiratebay a tracker-based system. >>>> >>>>> In the case where there is a tracker on the Internet that does not >>>>> cooperate (which is 99.99% of P2P traffic today) I'm not sure how ALTO >>>>> would work without the ISP tracker pushing information to the clients >>>>> (since the clients might not send info to the tracker). >>>> >>>> I agree that to cover the majority of the P2P traffic, it may be mostly be >>>> client-dependent in the beginning. >>>> >>>> The idea, however, is that as time goes on P2P developers and ISPs will >>>> each >>>> realize the benefits (better performance for P2P apps, and achieve >>>> particular >>>> network goals for ISPs) and begin support. Integration should be simple >>>> enough that P2P developers understand and use it. >>> >>> It is not P2P developers that need to be convinced. It is the users, the >>> human factor. >>> >>> And if ALTO does not "get it" that it is not just about having a >>> client-server protocol, I'm not sure of the benefits. Yeah, Pando or Joost >>> users can be convinced of using it, but how about the other users that are >>> responsible for 99.9% of traffic? And if they cannot be convinced, can ALTO >>> still do some form of optimization? This goes back to security and privacy. >>> >>>> >>>>> For private trackers (which have the really hardcore users) it is not >>>>> clear >>>>> how ALTO can influence their behavior since the whole point is to stay >>>>> within the private tracker's given peers. If we cannot tackle these two >>>>> scenarios, ISPs continue to suffer. >>>> >>>> Interesting point. If there are limited peers in a swarm, then there are >>>> limited opportunities for optimization (both for the P2P and ISP side). Is >>>> this a fundamental limit, though? Aside, of course, from "telling" them >>>> that >>>> their swarms should be larger :) >>> >>> Well, peers driven by private trackers are the elite. They do not really >>> need a big swarm since these are folks that have their computers on 24x7 and >>> have Seedboxes. Most of the time they have co-location boxes and/or pay >>> enterprise fees to have tons of bandwidth. >>> >>>> >>>> Getting adoption in major public P2P clients/trackers is certainly >>>> important >>>> in order for this to make a large difference for ISP networks. >>> >>> I believe, as I said before, that we need to convince users. The only way to >>> convince such users is if we have a tight (very tight) security, privacy >>> model. Otherwise the ALTO protocol might not see use in the wild. >>> >>> As far as convincing public trackers also means convincing the ISP to have a >>> relationship with such trackers as thepiratebay. Does Comcast or BT want to >>> have such relationship? I have no idea. I guess my point is that the >>> business/realities of P2P networks should drive the requirements so we can >>> work with (or around them). >>> >>> Thanks, >>> >>> Reinaldo >>> >>> >>> _______________________________________________ >>> p2pi mailing list >>> p2pi@ietf.org >>> https://www.ietf.org/mailman/listinfo/p2pi >> >> > > > > _______________________________________________ p2pi mailing list p2pi@ietf.org https://www.ietf.org/mailman/listinfo/p2pi From p2pi-bounces@ietf.org Sun Aug 3 11:49: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 9F7093A68E0; Sun, 3 Aug 2008 11:49: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 48C073A68E0 for ; Sun, 3 Aug 2008 11:49:57 -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 CANZQ65HpMOo for ; Sun, 3 Aug 2008 11:49:56 -0700 (PDT) Received: from py-out-1112.google.com (py-out-1112.google.com [64.233.166.177]) by core3.amsl.com (Postfix) with ESMTP id 4CE103A68C2 for ; Sun, 3 Aug 2008 11:49:56 -0700 (PDT) Received: by py-out-1112.google.com with SMTP id x19so860406pyg.24 for ; Sun, 03 Aug 2008 11:50:12 -0700 (PDT) Received: by 10.65.97.18 with SMTP id z18mr969783qbl.40.1217789412396; Sun, 03 Aug 2008 11:50:12 -0700 (PDT) Received: by 10.65.225.14 with HTTP; Sun, 3 Aug 2008 11:50:12 -0700 (PDT) Message-ID: <3efc39a60808031150u37018f9dka1a2915362ee1b3@mail.gmail.com> Date: Sun, 3 Aug 2008 11:50:12 -0700 From: "Robb Topolski" To: "Reinaldo Penno" In-Reply-To: <9BD5D7887235424FA97DFC223CAE3C28040ACD4F@proton.jnpr.net> MIME-Version: 1.0 References: <1144783309.99011217762128498.JavaMail.root@dkny.pando.com> <9BD5D7887235424FA97DFC223CAE3C28040ACD4F@proton.jnpr.net> Cc: p2pi@ietf.org Subject: Re: [p2pi] ALTO service privacy, performance, and architecture X-BeenThere: p2pi@ietf.org X-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="===============1936503602==" Sender: p2pi-bounces@ietf.org Errors-To: p2pi-bounces@ietf.org --===============1936503602== Content-Type: multipart/alternative; boundary="----=_Part_8938_21648320.1217789412281" ------=_Part_8938_21648320.1217789412281 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline > > yes, peer selection is random, and this randomness is a integral part of > the algorithm and some argue one of its strengths. What we are saying is > "instead of choosing peers randomly, give preference to these X instead". > This changes the algorithm considerably > I know that you understand this Laird, but not everyone might understand it: Peer selection is random when peers are being added to a list to be delivered to a client. However, the peers in that client list that will eventually pair and exchange data for extended periods of time is not random -- they are the 2-3** best (fastest) pairs in that list. So far, I haven't seen anything in the P4P suggestions that threatens this important, efficient, and congestion-avoiding feature, *and it's essential that P4P doesn't threaten it.* As closest peers are likely to be fastest, all other things considered, the hope for P4P peer localizing is that it can short-cut the time it takes for great peer pairings to find one another and pair up for extended transferring. This savings is realized because it might take the "random" method one to several tracker queries to deliver the same best peers that P4P could deliver in the first query. (Of course, please correct me if I'm misunderstanding something.) (**typical, but this is configurable and defaults are higher depending on the users' uplink speeds at install time.) ------=_Part_8938_21648320.1217789412281 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline
yes, peer selection is random, and this randomness is a integral part of the algorithm and some argue one of its strengths. What we are saying is "instead of choosing peers randomly, give preference to these X instead". This changes the algorithm considerably

I know that you understand this Laird, but not everyone might understand it:

Peer selection is random when peers are being added to a list to be delivered to a client.  However, the peers in that client list that will eventually pair and exchange data for extended periods of time is not random -- they are the 2-3** best (fastest) pairs in that list.  So far, I haven't seen anything in the P4P suggestions that threatens this important, efficient, and congestion-avoiding feature, and it's essential that P4P doesn't threaten it. 

As closest peers are likely to be fastest, all other things considered, the hope for P4P peer localizing is that it can short-cut the time it takes for great peer pairings to find one another and pair up for extended transferring. This savings is realized because it might take the "random" method one to several tracker queries to deliver the same best peers that P4P could deliver in the first query.  (Of course, please correct me if I'm misunderstanding something.)

(**typical, but this is configurable and defaults are higher depending on the users' uplink speeds at install time.)
------=_Part_8938_21648320.1217789412281-- --===============1936503602== 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 --===============1936503602==-- From p2pi-bounces@ietf.org Sun Aug 3 12:22:14 2008 Return-Path: X-Original-To: p2pi-archive@ietf.org Delivered-To: ietfarch-p2pi-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EE31E3A6C49; Sun, 3 Aug 2008 12:22:13 -0700 (PDT) X-Original-To: p2pi@core3.amsl.com Delivered-To: p2pi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 10C9828C103 for ; Sun, 3 Aug 2008 12:22:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.21 X-Spam-Level: X-Spam-Status: No, score=-10.21 tagged_above=-999 required=5 tests=[AWL=0.054, 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 ciqsYvsFkvUi for ; Sun, 3 Aug 2008 12:22:12 -0700 (PDT) Received: from dkny.pando.com (dkny.pando.com [67.99.55.163]) by core3.amsl.com (Postfix) with ESMTP id B2E263A6C2F for ; Sun, 3 Aug 2008 12:22:11 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by dkny.pando.com (Postfix) with ESMTP id 9AAB0E10A11; Sun, 3 Aug 2008 15:22:33 -0400 (EDT) X-Virus-Scanned: amavisd-new at Received: from dkny.pando.com ([127.0.0.1]) by localhost (dkny.pando.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BgitKD5n24gk; Sun, 3 Aug 2008 15:22:27 -0400 (EDT) Received: from dkny.pando.com (dkny.pando.com [10.10.60.11]) by dkny.pando.com (Postfix) with ESMTP id 1BFFDE10BE7; Sun, 3 Aug 2008 15:22:27 -0400 (EDT) Date: Sun, 3 Aug 2008 15:22:27 -0400 (EDT) From: Laird Popkin To: Robb Topolski Message-ID: <983265347.99241217791347074.JavaMail.root@dkny.pando.com> In-Reply-To: <3efc39a60808031150u37018f9dka1a2915362ee1b3@mail.gmail.com> MIME-Version: 1.0 X-Originating-IP: [71.187.207.81] Cc: p2pi@ietf.org Subject: Re: [p2pi] ALTO service privacy, performance, and architecture X-BeenThere: p2pi@ietf.org X-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="===============0015322828==" Sender: p2pi-bounces@ietf.org Errors-To: p2pi-bounces@ietf.org --===============0015322828== Content-Type: multipart/alternative; boundary="----=_Part_4436_1603611771.1217791347073" ------=_Part_4436_1603611771.1217791347073 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Great explanation, Robb.=20 To elaborate on the topic of randomness a bit, randomness in peer connectio= ns is indeed extremely important in order for the peer mesh to be resilient= - if peers always get the same set of "best" peers to connect to, over and= over again, that would be extremely harmful to the p2p mesh, because the p= 2p mesh would be fragile (i.e. too few connections), and swarms would tend = to be segmented into well connected peers within each ISP, isolated from ea= ch other. To balance between locality and randomness, we did a couple of th= ings:=20 - We implemented a 'weighted random' model in the P4P testing, where the pr= obability of connecting to peers in specific network locations is determine= d by the ISP's iTracker (AKA ALTO tracker), but the p2p network picks rando= m peers based on that probability for each response list sent, so the speci= fic peer list varies in every response.=20 - We always return at least 20% pure random peers (i.e. from the global lis= t) in order to make sure that the swarm doesn't get segmented between ISPs.= =20 The result of this is that peers tend to connect to nearby peers first, est= ablishing (hopefully) fast, cheap connections. Then over time the p2p mesh = fills in, so the peer has a chance to exchange data with the further peers.= If the local peers are indeed the fastest, the further connections won't b= e used much, as we (like many p2p networks) use the fastest available peers= , so localization provides a good speed boost. If the remote peers are fast= er than the local peers, we find that out and use them instead of the local= peers fairly quickly, so localizing doesn't hurt performance for too long.= =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: "Robb Topolski" =20 To: "Reinaldo Penno" =20 Cc: "Laird Popkin" , p2pi@ietf.org=20 Sent: Sunday, August 3, 2008 2:50:12 PM (GMT-0500) America/New_York=20 Subject: Re: [p2pi] ALTO service privacy, performance, and architecture=20 yes, peer selection is random, and this randomness is a integral part of th= e algorithm and some argue one of its strengths. What we are saying is "ins= tead of choosing peers randomly, give preference to these X instead". This = changes the algorithm considerably=20 I know that you understand this Laird, but not everyone might understand it= :=20 Peer selection is random when peers are being added to a list to be deliver= ed to a client.=C2=A0 However, the peers in that client list that will even= tually pair and exchange data for extended periods of time is not random --= they are the 2-3** best (fastest) pairs in that list.=C2=A0 So far, I have= n't seen anything in the P4P suggestions that threatens this important, eff= icient, and congestion-avoiding feature, and it's essential that P4P doesn'= t threaten it. =C2=A0=20 As closest peers are likely to be fastest, all other things considered, the= hope for P4P peer localizing is that it can short-cut the time it takes fo= r great peer pairings to find one another and pair up for extended transfer= ring. This savings is realized because it might take the "random" method on= e to several tracker queries to deliver the same best peers that P4P could = deliver in the first query.=C2=A0 (Of course, please correct me if I'm misu= nderstanding something.)=20 (**typical, but this is configurable and defaults are higher depending on t= he users' uplink speeds at install time.)=20 ------=_Part_4436_1603611771.1217791347073 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable Great explanation, Robb.

To elaborate on the topic of randomness a bit, randomness in peer connect= ions is indeed extremely important in order for the peer mesh to be resilie= nt - if peers always get the same set of "best" peers to connect to, over a= nd over again, that would be extremely harmful to the p2p mesh, because the= p2p mesh would be fragile (i.e. too few connections), and swarms would ten= d to be segmented into well connected peers within each ISP, isolated from = each other. To balance between locality and randomness, we did a couple of = things:

- We implemented a 'weighted random' model= in the P4P testing, where the probability of connecting to peers in specif= ic network locations is determined by the ISP's iTracker (AKA ALTO tracker)= , but the p2p network picks random peers based on that probability for each= response list sent, so the specific peer list varies in every response.
- We always return at least 20% pure random peers (i.e. from the gl= obal list) in order to make sure that the swarm doesn't get segmented betwe= en ISPs.

The result of this is that peers tend to = connect to nearby peers first, establishing (hopefully) fast, cheap connect= ions. Then over time the p2p mesh fills in, so the peer has a chance to exc= hange data with the further peers. If the local peers are indeed the fastes= t, the further connections won't be used much, as we (like many p2p network= s) use the fastest available peers, so localization provides a good speed b= oost. If the remote peers are faster than the local peers, we find that out= and use them instead of the local peers fairly quickly, so localizing does= n't hurt performance for too long.

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

----- Original Message -----
From: "Robb Topolski" <robb@fun= chords.com>
To: "Reinaldo Penno" <rpenno@juniper.net>
Cc: "Laird P= opkin" <laird@pando.com>, p2pi@ietf.org
Sent: Sunday, August 3, 2008 = 2:50:12 PM (GMT-0500) America/New_York
Subject: Re: [p2pi] ALTO service = privacy, performance, and architecture

yes, peer selection is random= , and this randomness is a integral part of the algorithm and some argue one of its strengths. What we are saying is "instead of choosing peers randomly, give preference to these X instead". This changes the algorithm considerably

I know that you understand this Laird, but not ever= yone might understand it:

Peer selection is random when peers = are being added to a list to be delivered to a client.=C2=A0 However, the p= eers in that client list that will eventually pair and exchange data for ex= tended periods of time is not random -- they are the 2-3** best (fastest) p= airs in that list.=C2=A0 So far, I haven't seen anything in the P4P suggest= ions that threatens this important, efficient, and congestion-avoiding feat= ure, and it's essential that P4P doesn't threaten it.=C2=A0

As closest peers are likely to be fastest, all other things considered,= the hope for P4P peer localizing is that it can short-cut the time it take= s for great peer pairings to find one another and pair up for extended tran= sferring. This savings is realized because it might take the "random" metho= d one to several tracker queries to deliver the same best peers that P4P co= uld deliver in the first query.=C2=A0 (Of course, please correct me if I'm = misunderstanding something.)

(**typical, but this is configurable and defaults are higher depending = on the users' uplink speeds at install time.)
------=_Part_4436_1603611771.1217791347073-- --===============0015322828== 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 --===============0015322828==-- From p2pi-bounces@ietf.org Sun Aug 3 12:23: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 91A1B28C11C; Sun, 3 Aug 2008 12:23: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 6B86728C11B for ; Sun, 3 Aug 2008 12:23:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.056 X-Spam-Level: X-Spam-Status: No, score=-10.056 tagged_above=-999 required=5 tests=[AWL=-0.106, 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 P84HMyTZGQJS for ; Sun, 3 Aug 2008 12:23:28 -0700 (PDT) Received: from dkny.pando.com (dkny.pando.com [67.99.55.163]) by core3.amsl.com (Postfix) with ESMTP id 527FA28C11C for ; Sun, 3 Aug 2008 12:23:28 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by dkny.pando.com (Postfix) with ESMTP id 9A56CE10A22; Sun, 3 Aug 2008 15:23:54 -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 EYTjqLvq9UIZ; Sun, 3 Aug 2008 15:23:47 -0400 (EDT) Received: from dkny.pando.com (dkny.pando.com [10.10.60.11]) by dkny.pando.com (Postfix) with ESMTP id 43791E10A11; Sun, 3 Aug 2008 15:23:47 -0400 (EDT) Date: Sun, 3 Aug 2008 15:23:47 -0400 (EDT) From: Laird Popkin To: Reinaldo Penno Message-ID: <711809017.99271217791427228.JavaMail.root@dkny.pando.com> In-Reply-To: MIME-Version: 1.0 X-Originating-IP: [71.187.207.81] Cc: p2pi@ietf.org Subject: Re: [p2pi] ALTO service privacy, performance, and architecture X-BeenThere: p2pi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: P2P Infrastructure Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: p2pi-bounces@ietf.org Errors-To: p2pi-bounces@ietf.org In that case we're in violent agreement. :-) - Laird Popkin, CTO, Pando Networks mobile: 646/465-0570 ----- Original Message ----- From: "Reinaldo Penno" To: "Laird Popkin" Cc: p2pi@ietf.org, "Richard Alimi" Sent: Sunday, August 3, 2008 1:52:16 PM (GMT-0500) America/New_York Subject: Re: [p2pi] ALTO service privacy, performance, and architecture Do not take BGP routing table as a proposed solution. It was just an example. Maybe not a good one for the sake of this discussion. The point I was trying to get across is that ISPs can push policies (the result of the decentralized computation) to clients and they can use these policies as they see fit, using whatever algorithm they want. This way clients do not need to send info about peers to the ISP. On 8/3/08 8:49 AM, "Laird Popkin" wrote: > Comments below: > > - Laird Popkin, CTO, Pando Networks > mobile: 646/465-0570 > > ----- Original Message ----- > From: "Reinaldo Penno" > To: "Laird Popkin" > Cc: p2pi@ietf.org, "Richard Alimi" > Sent: Sunday, August 3, 2008 11:11:02 AM (GMT-0500) America/New_York > Subject: RE: [p2pi] ALTO service privacy, performance, and architecture > > > > > -----Original Message----- > From: Laird Popkin [mailto:laird@pando.com] > Sent: Sun 8/3/2008 4:15 AM > To: Reinaldo Penno > Cc: p2pi@ietf.org; Richard Alimi > Subject: Re: [p2pi] ALTO service privacy, performance, and architecture > > Regarding the question of whether users know about ALTO, I think that you're > reading too much into ALTO. P2P networks already control who users connect to > and exchange data with, transparently to users. ALTO doesn't change anything > other than that the ISPs are providing some assistance. > > [reinaldo] > > yes, peer selection is random, and this randomness is a integral part of the > algorithm and some argue one of its strengths. What we are saying is "instead > of choosing peers randomly, give preference to these X instead". This changes > the algorithm considerably. > > [laird] Not really. All P2P networks make decisions about which peers to > exchange data between in order to optimize p2p performance. ALTO would be an > additional input into that decision. > > Regarding public tracker's incentives to implement this, I am not sure why you > assume that they don't want their users to have fast download speeds. Users > care a lot about download speeds, and would be happy to switch to whichever > tracker gave them the best performance. And the people that run trackers care > a lot about whether people use them. This is probably why, when I've talked to > people that run trackers, they'd be very happy to implement a performance > optimization that made their downloads faster. Their concerns are more > regarding complexity of implementation, and in working with the ISPs to get > the guidance. > > [reinaldo] > > I believe trackers want peers to have better download speeds, what I said is > that today it already works well. If you talked to public trackers like > thepiratebay, mininova and others and they are interested in exchanging info > with ISPs that is interesting information. > > [laird] While it's true that p2p networks already work well, it also appears > to be true that there's significant room for improvement. Specifically, in > field testing localizing traffic significantly improves performance when > compared to pure random peer connections. As I wrote earlier, I can't prove > why this occurs, but I can certainly document that downloads that localize > transfers are on average significantly faster than downloads that don't do so. > It may be caused by TCP operating better with shorter RTT's. It might be > avoiding ISP's saturated internal or external links, or even general internet > traffic. But it seems clear that localizing traffic benefits performance on > average. > > Given this, tracker sites appear to have a clear incentive to improve > performance by implementing traffic localization. > > Regarding the statement that "a client can easily get access to a full BGP > routing table and perform some optimizations itself", while theoretically a > p2p client could retrieve and use full BGP tables, but in practice BGP routing > tables are quite large and complex, so I'm not sure that I would call doing > this 'easy' to the point where millions of desktop applications should be > doing it. It's far more efficient for this kind of work to be done in a > centralized server that the clients can query for guidance, IMO. > > [reinaldo] > > Yes and no. Both approaches have pros and cons. > > A centralized server is a single point of failure, needs to interface with the > routers on the network to acquire such info since it is not part of the > routing mesh. And if the client needs to ask for guidance it needs to send a > list of IP/Prefixes/other to this centralized server every time it gets to > know a new set of peers. > > If the policies are pushed (which can be done in a decentralized way), the > client can apply the policies against the list of candidate peers. We can > even use multicast to push such policies if the network supports it. Since > the policies are network based (independent of torrrent), there is no need for > the client to keep asking for policies every time it gets to know a new set of > peers. That of course does not preclude a client from contacting its closest > ALTO Service/Server (not a centralized one) and ask for guidance. > > [laird] I certainly agree that there are both centralized and decentralized > p2p networks. My point was that even if theoretically every p2p client could > retrieve and process the ISP's full BGP tables, practically speaking that > doesn't preclude the value of a central server that does that work and makes > the results available in a more compact, easily processable, standardized > format. > > - Laird Popkin, CTO, Pando Networks > mobile: 646/465-0570 > > ----- Original Message ----- > From: "Reinaldo Penno" > To: "Laird Popkin" > Cc: p2pi@ietf.org, "Richard Alimi" > Sent: Sunday, August 3, 2008 2:03:31 AM (GMT-0500) America/New_York > Subject: Re: [p2pi] ALTO service privacy, performance, and architecture > > > > > On 8/2/08 9:09 PM, "Laird Popkin" wrote: > >> I don't think that p2p users will know or care about ALTO, any more than they >> know or care about BGP, or HTTP proxies - things just work. ALTO will need to >> be known about and implemented either by the p2p trackers or clients. At most >> some applications might provide an ALTO check box as a preference setting, >> just as they might allow for manual proxy configuration. > > At most or always? If you make it mandatory you are deciding on behalf of > the users who he/she should connect and you are dealing in the net > neutrality realm. I'm not sure MSO and Telcos want to go through FCC battles > again. > >> >> Answering the question "And the motivation for pirate trackers would be? ... >> Improve performance seems slim.", I believe that there are two benefits, one >> direct and one indirect. >> >> The direct benefit is that localizing data transfers improves download >> performance for users significantly on average, which makes users happier. >> While theoretically it shouldn't matter whether data is pulled from nearby >> sources or far, in practice localizing data sources appears to improve >> performance quite a bit. I can only guess what the cause of the improved >> performance is (perhaps shorter RTT's improve TCP throughput, perhaps >> avoiding >> congested internet gateways). In any case, we're seeing real world download >> speeds double and triple for users on fast broadband connections (nothing >> will >> speed up a slow broadband connection...). >> >> The indirect benefit is that by reducing the transit costs created by p2p >> traffic, it reduces the incentives for ISPs to degrade p2p traffic. > > I was talking about what were the incentives for public trackers to perform > optimizations. Your arguments seem to be ISP centric. Public trackers do not > care or are very happy with the current download speeds of their users. > Statistics from these trackers show more bandwidth consumed in a month than > all itunes music sold to date. > >> >> "Clients can potentially improve their own performance by choosing closer >> peers based on IP addresses." How would they know which IP addresses are >> closer? ALTO? > > As Stas suggested, a client can easily get access to a full BGP routing > table and perform some optimizations itself. Is this ALTO? > > >> >> - Laird Popkin, CTO, Pando Networks >> mobile: 646/465-0570 >> >> ----- Original Message ----- >> From: "Reinaldo Penno" >> To: "Laird Popkin" >> Cc: p2pi@ietf.org, "Richard Alimi" >> Sent: Saturday, August 2, 2008 10:58:44 PM (GMT-0500) America/New_York >> Subject: Re: [p2pi] ALTO service privacy, performance, and architecture >> >> >> >> >> On 8/2/08 7:35 PM, "Laird Popkin" wrote: >> >>> The P4P tests that were performed so far were performed with legal content >>> so >>> that we could focus on technical issues (e.g. implementing and running the >>> tests) and not get caught in potentially lengthy policy discussions that >>> (IMO) >>> are only worth having once the technology demonstrates its value. The test >>> results have been very good, so I suspect that the policy discussions will >>> start taking place. There's no technical issue limiting who uses P4P (and, I >>> hope, ALTO). Given this, I believe that each ISP can decide its own policies >>> regarding who it wants to share what information with. >> >> Understood. >> >>> >>> Keep in mind that ALTO servers can be run by entities other than ISPs. So if >>> ISPs don't want to work with pirate trackers, the pirate trackers might join >>> together to set up an ALTO server populated using whatever network >>> information >>> they can collect or determine (e.g. ASN adjacency maps) to improve >>> performance >>> for their users. >> >> And the motivation for pirate trackers would be? There is no business >> relationship between P2P clients and their public trackers. Improve >> performance seems slim. Clients can potentially improve their own >> performance by choosing closer peers based on IP addresses. >> >>> >>> Finally, ALTO servers should be accessible by either clients or servers, so >>> it >>> may be the case that even if ISPs don't want to work with pirate trackers, >>> they might approve working with user p2p clients, which would achieve a >>> similar result. >> >> The latter requires a leap of faith. That's where I think we have different >> opinions. I think we need to make sure P2P users are on-board. BTW, by P2P >> clients you mean the P2P software or P2P users? >> >> Thanks, >> >> Reinaldo >>> >>> - Laird Popkin, CTO, Pando Networks >>> mobile: 646/465-0570 >>> >>> ----- Original Message ----- >>> From: "Reinaldo Penno" >>> To: "Richard Alimi" >>> Cc: p2pi@ietf.org >>> Sent: Saturday, August 2, 2008 10:10:11 PM (GMT-0500) America/New_York >>> Subject: Re: [p2pi] ALTO service privacy, performance, and architecture >>> >>> Hi, >>> >>> Thanks for your answers. Comments inline. >>> >>> On 8/2/08 6:11 PM, "Richard Alimi" wrote: >>> >>>>> I just want to remind that we are here because of file-sharing and not >>>>> really closed P2P networks where itrackers, apptrackers and others >>>>> cooperate nicely. This is the easy case and today does not cause problems >>>>> to ISPs. And maybe never will. >>>> >>>> Let me make one clarification to your statement above. The itracker in P4P >>>> is >>>> not application specific, and thus is not part of any closed system. It >>>> can >>>> be queried by many P2P applications, and does not keep any swarm state. >>>> The >>>> field tests have been done with Pando, but nothing restricts it from being >>>> used for "public" P2P networks. >>>> >>>> Or did I misinterpret your meaning of "closed"? >>> >>> Closed as in the sense that it assumes cooperation from the AppTracker. >>> Otherwise how can it not keep any swarm state? This is is based on the >>> functionality from your paper. >>> >>> Anyway, the two statements seem contradictory. The corollary is that the >>> content that such clients access are those of the P2P CDN and not pirated >>> content. The P4P trials that I have heard/read are based on legal content. >>> Please correct me if I'm wrong. >>> >>>> >>>>> So, when you say "tracker-less" systems you mean a P2P network without a >>>>> tracker (Gnutella) or a P2P network where the tracker is something like >>>>> thepiratebay? The two 'systems' (as you put it) are quite different. >>>> >>>> By "tracker-less," I was referring to a P2P network without a tracker. We >>>> consider thepiratebay a tracker-based system. >>>> >>>>> In the case where there is a tracker on the Internet that does not >>>>> cooperate (which is 99.99% of P2P traffic today) I'm not sure how ALTO >>>>> would work without the ISP tracker pushing information to the clients >>>>> (since the clients might not send info to the tracker). >>>> >>>> I agree that to cover the majority of the P2P traffic, it may be mostly be >>>> client-dependent in the beginning. >>>> >>>> The idea, however, is that as time goes on P2P developers and ISPs will >>>> each >>>> realize the benefits (better performance for P2P apps, and achieve >>>> particular >>>> network goals for ISPs) and begin support. Integration should be simple >>>> enough that P2P developers understand and use it. >>> >>> It is not P2P developers that need to be convinced. It is the users, the >>> human factor. >>> >>> And if ALTO does not "get it" that it is not just about having a >>> client-server protocol, I'm not sure of the benefits. Yeah, Pando or Joost >>> users can be convinced of using it, but how about the other users that are >>> responsible for 99.9% of traffic? And if they cannot be convinced, can ALTO >>> still do some form of optimization? This goes back to security and privacy. >>> >>>> >>>>> For private trackers (which have the really hardcore users) it is not >>>>> clear >>>>> how ALTO can influence their behavior since the whole point is to stay >>>>> within the private tracker's given peers. If we cannot tackle these two >>>>> scenarios, ISPs continue to suffer. >>>> >>>> Interesting point. If there are limited peers in a swarm, then there are >>>> limited opportunities for optimization (both for the P2P and ISP side). Is >>>> this a fundamental limit, though? Aside, of course, from "telling" them >>>> that >>>> their swarms should be larger :) >>> >>> Well, peers driven by private trackers are the elite. They do not really >>> need a big swarm since these are folks that have their computers on 24x7 and >>> have Seedboxes. Most of the time they have co-location boxes and/or pay >>> enterprise fees to have tons of bandwidth. >>> >>>> >>>> Getting adoption in major public P2P clients/trackers is certainly >>>> important >>>> in order for this to make a large difference for ISP networks. >>> >>> I believe, as I said before, that we need to convince users. The only way to >>> convince such users is if we have a tight (very tight) security, privacy >>> model. Otherwise the ALTO protocol might not see use in the wild. >>> >>> As far as convincing public trackers also means convincing the ISP to have a >>> relationship with such trackers as thepiratebay. Does Comcast or BT want to >>> have such relationship? I have no idea. I guess my point is that the >>> business/realities of P2P networks should drive the requirements so we can >>> work with (or around them). >>> >>> Thanks, >>> >>> Reinaldo >>> >>> >>> _______________________________________________ >>> 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 Aug 4 06:59: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 050D93A6CC2; Mon, 4 Aug 2008 06:59: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 C490A3A6CC4 for ; Mon, 4 Aug 2008 06:59:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.544 X-Spam-Level: X-Spam-Status: No, score=-103.544 tagged_above=-999 required=5 tests=[AWL=0.055, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y-zWPwnBXEDv for ; Mon, 4 Aug 2008 06:59:15 -0700 (PDT) Received: from multicasttech.com (lennon.multicasttech.com [63.105.122.7]) by core3.amsl.com (Postfix) with ESMTP id 874DC3A6CC1 for ; Mon, 4 Aug 2008 06:59:14 -0700 (PDT) Received: from [63.105.122.7] (account marshall_eubanks HELO [IPv6:::1]) by multicasttech.com (CommuniGate Pro SMTP 3.4.8) with ESMTP-TLS id 12357288; Mon, 04 Aug 2008 09:59:42 -0400 Message-Id: From: Marshall Eubanks To: Reinaldo Penno In-Reply-To: Mime-Version: 1.0 (Apple Message framework v926) Date: Mon, 4 Aug 2008 09:59:41 -0400 References: X-Mailer: Apple Mail (2.926) Cc: p2pi@ietf.org Subject: Re: [p2pi] ALTO service privacy, performance, and architecture X-BeenThere: p2pi@ietf.org 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 Aug 3, 2008, at 2:46 AM, Reinaldo Penno wrote: > Laird, > > > On 8/2/08 9:09 PM, "Laird Popkin" wrote: > >> I don't think that p2p users will know or care about ALTO, any more >> than they >> know or care about BGP, or HTTP proxies - things just work. > > I would say they care a lot. You statement that you "don't think p2p > users > will know" does not seem to reflect the transparency we need. Doing > anything > under the covers already proved disastrous. I would tend to agree, especially for the power users. Remember the extensive on-line discussion of TCP resets. Regards Marshall > > > Once bitten, twice shy. I would be surprised if users/EFF/consumers > groups > do not scrutinize what is happening with, within the ALTO protocol > and how > their information will be used. You have to see it from the users > point of > view, the people that complained to the FCC, had connections > dropped/policed/whatever, go to messages board in droves to > complain, etc. > > Thanks, > > Reinaldo > > > > ALTO will need to >> be known about and implemented either by the p2p trackers or >> clients. At most >> some applications might provide an ALTO check box as a preference >> setting, >> just as they might allow for manual proxy configuration. >> >> Answering the question "And the motivation for pirate trackers >> would be? ... >> Improve performance seems slim.", I believe that there are two >> benefits, one >> direct and one indirect. >> >> The direct benefit is that localizing data transfers improves >> download >> performance for users significantly on average, which makes users >> happier. >> While theoretically it shouldn't matter whether data is pulled from >> nearby >> sources or far, in practice localizing data sources appears to >> improve >> performance quite a bit. I can only guess what the cause of the >> improved >> performance is (perhaps shorter RTT's improve TCP throughput, >> perhaps avoiding >> congested internet gateways). In any case, we're seeing real world >> download >> speeds double and triple for users on fast broadband connections >> (nothing will >> speed up a slow broadband connection...). >> >> The indirect benefit is that by reducing the transit costs created >> by p2p >> traffic, it reduces the incentives for ISPs to degrade p2p traffic. >> >> "Clients can potentially improve their own performance by choosing >> closer >> peers based on IP addresses." How would they know which IP >> addresses are >> closer? ALTO? >> >> - Laird Popkin, CTO, Pando Networks >> mobile: 646/465-0570 >> >> ----- Original Message ----- >> From: "Reinaldo Penno" >> To: "Laird Popkin" >> Cc: p2pi@ietf.org, "Richard Alimi" >> Sent: Saturday, August 2, 2008 10:58:44 PM (GMT-0500) America/ >> New_York >> Subject: Re: [p2pi] ALTO service privacy, performance, and >> architecture >> >> >> >> >> On 8/2/08 7:35 PM, "Laird Popkin" wrote: >> >>> The P4P tests that were performed so far were performed with legal >>> content so >>> that we could focus on technical issues (e.g. implementing and >>> running the >>> tests) and not get caught in potentially lengthy policy >>> discussions that >>> (IMO) >>> are only worth having once the technology demonstrates its value. >>> The test >>> results have been very good, so I suspect that the policy >>> discussions will >>> start taking place. There's no technical issue limiting who uses >>> P4P (and, I >>> hope, ALTO). Given this, I believe that each ISP can decide its >>> own policies >>> regarding who it wants to share what information with. >> >> Understood. >> >>> >>> Keep in mind that ALTO servers can be run by entities other than >>> ISPs. So if >>> ISPs don't want to work with pirate trackers, the pirate trackers >>> might join >>> together to set up an ALTO server populated using whatever network >>> information >>> they can collect or determine (e.g. ASN adjacency maps) to improve >>> performance >>> for their users. >> >> And the motivation for pirate trackers would be? There is no business >> relationship between P2P clients and their public trackers. Improve >> performance seems slim. Clients can potentially improve their own >> performance by choosing closer peers based on IP addresses. >> >>> >>> Finally, ALTO servers should be accessible by either clients or >>> servers, so >>> it >>> may be the case that even if ISPs don't want to work with pirate >>> trackers, >>> they might approve working with user p2p clients, which would >>> achieve a >>> similar result. >> >> The latter requires a leap of faith. That's where I think we have >> different >> opinions. I think we need to make sure P2P users are on-board. BTW, >> by P2P >> clients you mean the P2P software or P2P users? >> >> Thanks, >> >> Reinaldo >>> >>> - Laird Popkin, CTO, Pando Networks >>> mobile: 646/465-0570 >>> >>> ----- Original Message ----- >>> From: "Reinaldo Penno" >>> To: "Richard Alimi" >>> Cc: p2pi@ietf.org >>> Sent: Saturday, August 2, 2008 10:10:11 PM (GMT-0500) America/ >>> New_York >>> Subject: Re: [p2pi] ALTO service privacy, performance, and >>> architecture >>> >>> Hi, >>> >>> Thanks for your answers. Comments inline. >>> >>> On 8/2/08 6:11 PM, "Richard Alimi" wrote: >>> >>>>> I just want to remind that we are here because of file-sharing >>>>> and not >>>>> really closed P2P networks where itrackers, apptrackers and others >>>>> cooperate nicely. This is the easy case and today does not cause >>>>> problems >>>>> to ISPs. And maybe never will. >>>> >>>> Let me make one clarification to your statement above. The >>>> itracker in P4P >>>> is >>>> not application specific, and thus is not part of any closed >>>> system. It can >>>> be queried by many P2P applications, and does not keep any swarm >>>> state. The >>>> field tests have been done with Pando, but nothing restricts it >>>> from being >>>> used for "public" P2P networks. >>>> >>>> Or did I misinterpret your meaning of "closed"? >>> >>> Closed as in the sense that it assumes cooperation from the >>> AppTracker. >>> Otherwise how can it not keep any swarm state? This is is based on >>> the >>> functionality from your paper. >>> >>> Anyway, the two statements seem contradictory. The corollary is >>> that the >>> content that such clients access are those of the P2P CDN and not >>> pirated >>> content. The P4P trials that I have heard/read are based on legal >>> content. >>> Please correct me if I'm wrong. >>> >>>> >>>>> So, when you say "tracker-less" systems you mean a P2P network >>>>> without a >>>>> tracker (Gnutella) or a P2P network where the tracker is >>>>> something like >>>>> thepiratebay? The two 'systems' (as you put it) are quite >>>>> different. >>>> >>>> By "tracker-less," I was referring to a P2P network without a >>>> tracker. We >>>> consider thepiratebay a tracker-based system. >>>> >>>>> In the case where there is a tracker on the Internet that does not >>>>> cooperate (which is 99.99% of P2P traffic today) I'm not sure >>>>> how ALTO >>>>> would work without the ISP tracker pushing information to the >>>>> clients >>>>> (since the clients might not send info to the tracker). >>>> >>>> I agree that to cover the majority of the P2P traffic, it may be >>>> mostly be >>>> client-dependent in the beginning. >>>> >>>> The idea, however, is that as time goes on P2P developers and >>>> ISPs will each >>>> realize the benefits (better performance for P2P apps, and achieve >>>> particular >>>> network goals for ISPs) and begin support. Integration should be >>>> simple >>>> enough that P2P developers understand and use it. >>> >>> It is not P2P developers that need to be convinced. It is the >>> users, the >>> human factor. >>> >>> And if ALTO does not "get it" that it is not just about having a >>> client-server protocol, I'm not sure of the benefits. Yeah, Pando >>> or Joost >>> users can be convinced of using it, but how about the other users >>> that are >>> responsible for 99.9% of traffic? And if they cannot be convinced, >>> can ALTO >>> still do some form of optimization? This goes back to security and >>> privacy. >>> >>>> >>>>> For private trackers (which have the really hardcore users) it >>>>> is not clear >>>>> how ALTO can influence their behavior since the whole point is >>>>> to stay >>>>> within the private tracker's given peers. If we cannot tackle >>>>> these two >>>>> scenarios, ISPs continue to suffer. >>>> >>>> Interesting point. If there are limited peers in a swarm, then >>>> there are >>>> limited opportunities for optimization (both for the P2P and ISP >>>> side). Is >>>> this a fundamental limit, though? Aside, of course, from >>>> "telling" them that >>>> their swarms should be larger :) >>> >>> Well, peers driven by private trackers are the elite. They do not >>> really >>> need a big swarm since these are folks that have their computers >>> on 24x7 and >>> have Seedboxes. Most of the time they have co-location boxes and/ >>> or pay >>> enterprise fees to have tons of bandwidth. >>> >>>> >>>> Getting adoption in major public P2P clients/trackers is >>>> certainly important >>>> in order for this to make a large difference for ISP networks. >>> >>> I believe, as I said before, that we need to convince users. The >>> only way to >>> convince such users is if we have a tight (very tight) security, >>> privacy >>> model. Otherwise the ALTO protocol might not see use in the wild. >>> >>> As far as convincing public trackers also means convincing the ISP >>> to have a >>> relationship with such trackers as thepiratebay. Does Comcast or >>> BT want to >>> have such relationship? I have no idea. I guess my point is that the >>> business/realities of P2P networks should drive the requirements >>> so we can >>> work with (or around them). >>> >>> Thanks, >>> >>> Reinaldo >>> >>> >>> _______________________________________________ >>> 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 Aug 4 07:55: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 BD4D13A6CC0; Mon, 4 Aug 2008 07:55: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 226B43A6CC0 for ; Mon, 4 Aug 2008 07:55:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.044 X-Spam-Level: X-Spam-Status: No, score=0.044 tagged_above=-999 required=5 tests=[AWL=0.507, 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 DTKoDuzFkRop for ; Mon, 4 Aug 2008 07:55:28 -0700 (PDT) Received: from pacdcimo01.cable.comcast.com (PacdcIMO01.cable.comcast.com [24.40.8.145]) by core3.amsl.com (Postfix) with ESMTP id 73E0A3A6CBE for ; Mon, 4 Aug 2008 07:55:28 -0700 (PDT) Received: from ([24.40.15.92]) by pacdcimo01.cable.comcast.com with ESMTP id 5503620.10060780; Mon, 04 Aug 2008 10:55:40 -0400 Received: from PACDCEXCMB06.cable.comcast.com ([24.40.15.22]) by PACDCEXCSMTP03.cable.comcast.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 4 Aug 2008 10:55:40 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 4 Aug 2008 10:55:38 -0400 Message-ID: <74CCBBDF76102846AFA7B29F3A98D3F60107C2A3@PACDCEXCMB06.cable.comcast.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [p2pi] ALTO service privacy, performance, and architecture Thread-Index: Acj2Op+FLoTVXvhXQvqKgijLGriCXgAB4icV From: "Woundy, Richard" To: , X-OriginalArrivalTime: 04 Aug 2008 14:55:40.0128 (UTC) FILETIME=[294D8600:01C8F642] Cc: p2pi@ietf.org Subject: Re: [p2pi] ALTO service privacy, performance, and architecture X-BeenThere: p2pi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: P2P Infrastructure Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: p2pi-bounces@ietf.org Errors-To: p2pi-bounces@ietf.org Maybe we ought to distinguish between opt-in transparency (ie the user can know what is going on, and can opt-in or opt-out as desired) and usage transparency (ie once the user preference is selected, little intervention by the user is needed). I suspect both 'transparency types' are needed. Users and applications won't adopt any ISP preference selections unless they see the benefits to them. I think this has to be a win-win (for the user/app and for the ISP) if Alto is going to succeed. (I am assuming ISP-supplied preferences of course.) -- Rich ----- Original Message ----- From: p2pi-bounces@ietf.org To: Reinaldo Penno Cc: p2pi@ietf.org Sent: Mon Aug 04 09:59:41 2008 Subject: Re: [p2pi] ALTO service privacy, performance, and architecture On Aug 3, 2008, at 2:46 AM, Reinaldo Penno wrote: > Laird, > > > On 8/2/08 9:09 PM, "Laird Popkin" wrote: > >> I don't think that p2p users will know or care about ALTO, any more >> than they >> know or care about BGP, or HTTP proxies - things just work. > > I would say they care a lot. You statement that you "don't think p2p > users > will know" does not seem to reflect the transparency we need. Doing > anything > under the covers already proved disastrous. I would tend to agree, especially for the power users. Remember the extensive on-line discussion of TCP resets. Regards Marshall > > > Once bitten, twice shy. I would be surprised if users/EFF/consumers > groups > do not scrutinize what is happening with, within the ALTO protocol > and how > their information will be used. You have to see it from the users > point of > view, the people that complained to the FCC, had connections > dropped/policed/whatever, go to messages board in droves to > complain, etc. > > Thanks, > > Reinaldo > > > > ALTO will need to >> be known about and implemented either by the p2p trackers or >> clients. At most >> some applications might provide an ALTO check box as a preference >> setting, >> just as they might allow for manual proxy configuration. >> >> Answering the question "And the motivation for pirate trackers >> would be? ... >> Improve performance seems slim.", I believe that there are two >> benefits, one >> direct and one indirect. >> >> The direct benefit is that localizing data transfers improves >> download >> performance for users significantly on average, which makes users >> happier. >> While theoretically it shouldn't matter whether data is pulled from >> nearby >> sources or far, in practice localizing data sources appears to >> improve >> performance quite a bit. I can only guess what the cause of the >> improved >> performance is (perhaps shorter RTT's improve TCP throughput, >> perhaps avoiding >> congested internet gateways). In any case, we're seeing real world >> download >> speeds double and triple for users on fast broadband connections >> (nothing will >> speed up a slow broadband connection...). >> >> The indirect benefit is that by reducing the transit costs created >> by p2p >> traffic, it reduces the incentives for ISPs to degrade p2p traffic. >> >> "Clients can potentially improve their own performance by choosing >> closer >> peers based on IP addresses." How would they know which IP >> addresses are >> closer? ALTO? >> >> - Laird Popkin, CTO, Pando Networks >> mobile: 646/465-0570 >> >> ----- Original Message ----- >> From: "Reinaldo Penno" >> To: "Laird Popkin" >> Cc: p2pi@ietf.org, "Richard Alimi" >> Sent: Saturday, August 2, 2008 10:58:44 PM (GMT-0500) America/ >> New_York >> Subject: Re: [p2pi] ALTO service privacy, performance, and >> architecture >> >> >> >> >> On 8/2/08 7:35 PM, "Laird Popkin" wrote: >> >>> The P4P tests that were performed so far were performed with legal >>> content so >>> that we could focus on technical issues (e.g. implementing and >>> running the >>> tests) and not get caught in potentially lengthy policy >>> discussions that >>> (IMO) >>> are only worth having once the technology demonstrates its value. >>> The test >>> results have been very good, so I suspect that the policy >>> discussions will >>> start taking place. There's no technical issue limiting who uses >>> P4P (and, I >>> hope, ALTO). Given this, I believe that each ISP can decide its >>> own policies >>> regarding who it wants to share what information with. >> >> Understood. >> >>> >>> Keep in mind that ALTO servers can be run by entities other than >>> ISPs. So if >>> ISPs don't want to work with pirate trackers, the pirate trackers >>> might join >>> together to set up an ALTO server populated using whatever network >>> information >>> they can collect or determine (e.g. ASN adjacency maps) to improve >>> performance >>> for their users. >> >> And the motivation for pirate trackers would be? There is no business >> relationship between P2P clients and their public trackers. Improve >> performance seems slim. Clients can potentially improve their own >> performance by choosing closer peers based on IP addresses. >> >>> >>> Finally, ALTO servers should be accessible by either clients or >>> servers, so >>> it >>> may be the case that even if ISPs don't want to work with pirate >>> trackers, >>> they might approve working with user p2p clients, which would >>> achieve a >>> similar result. >> >> The latter requires a leap of faith. That's where I think we have >> different >> opinions. I think we need to make sure P2P users are on-board. BTW, >> by P2P >> clients you mean the P2P software or P2P users? >> >> Thanks, >> >> Reinaldo >>> >>> - Laird Popkin, CTO, Pando Networks >>> mobile: 646/465-0570 >>> >>> ----- Original Message ----- >>> From: "Reinaldo Penno" >>> To: "Richard Alimi" >>> Cc: p2pi@ietf.org >>> Sent: Saturday, August 2, 2008 10:10:11 PM (GMT-0500) America/ >>> New_York >>> Subject: Re: [p2pi] ALTO service privacy, performance, and >>> architecture >>> >>> Hi, >>> >>> Thanks for your answers. Comments inline. >>> >>> On 8/2/08 6:11 PM, "Richard Alimi" wrote: >>> >>>>> I just want to remind that we are here because of file-sharing >>>>> and not >>>>> really closed P2P networks where itrackers, apptrackers and others >>>>> cooperate nicely. This is the easy case and today does not cause >>>>> problems >>>>> to ISPs. And maybe never will. >>>> >>>> Let me make one clarification to your statement above. The >>>> itracker in P4P >>>> is >>>> not application specific, and thus is not part of any closed >>>> system. It can >>>> be queried by many P2P applications, and does not keep any swarm >>>> state. The >>>> field tests have been done with Pando, but nothing restricts it >>>> from being >>>> used for "public" P2P networks. >>>> >>>> Or did I misinterpret your meaning of "closed"? >>> >>> Closed as in the sense that it assumes cooperation from the >>> AppTracker. >>> Otherwise how can it not keep any swarm state? This is is based on >>> the >>> functionality from your paper. >>> >>> Anyway, the two statements seem contradictory. The corollary is >>> that the >>> content that such clients access are those of the P2P CDN and not >>> pirated >>> content. The P4P trials that I have heard/read are based on legal >>> content. >>> Please correct me if I'm wrong. >>> >>>> >>>>> So, when you say "tracker-less" systems you mean a P2P network >>>>> without a >>>>> tracker (Gnutella) or a P2P network where the tracker is >>>>> something like >>>>> thepiratebay? The two 'systems' (as you put it) are quite >>>>> different. >>>> >>>> By "tracker-less," I was referring to a P2P network without a >>>> tracker. We >>>> consider thepiratebay a tracker-based system. >>>> >>>>> In the case where there is a tracker on the Internet that does not >>>>> cooperate (which is 99.99% of P2P traffic today) I'm not sure >>>>> how ALTO >>>>> would work without the ISP tracker pushing information to the >>>>> clients >>>>> (since the clients might not send info to the tracker). >>>> >>>> I agree that to cover the majority of the P2P traffic, it may be >>>> mostly be >>>> client-dependent in the beginning. >>>> >>>> The idea, however, is that as time goes on P2P developers and >>>> ISPs will each >>>> realize the benefits (better performance for P2P apps, and achieve >>>> particular >>>> network goals for ISPs) and begin support. Integration should be >>>> simple >>>> enough that P2P developers understand and use it. >>> >>> It is not P2P developers that need to be convinced. It is the >>> users, the >>> human factor. >>> >>> And if ALTO does not "get it" that it is not just about having a >>> client-server protocol, I'm not sure of the benefits. Yeah, Pando >>> or Joost >>> users can be convinced of using it, but how about the other users >>> that are >>> responsible for 99.9% of traffic? And if they cannot be convinced, >>> can ALTO >>> still do some form of optimization? This goes back to security and >>> privacy. >>> >>>> >>>>> For private trackers (which have the really hardcore users) it >>>>> is not clear >>>>> how ALTO can influence their behavior since the whole point is >>>>> to stay >>>>> within the private tracker's given peers. If we cannot tackle >>>>> these two >>>>> scenarios, ISPs continue to suffer. >>>> >>>> Interesting point. If there are limited peers in a swarm, then >>>> there are >>>> limited opportunities for optimization (both for the P2P and ISP >>>> side). Is >>>> this a fundamental limit, though? Aside, of course, from >>>> "telling" them that >>>> their swarms should be larger :) >>> >>> Well, peers driven by private trackers are the elite. They do not >>> really >>> need a big swarm since these are folks that have their computers >>> on 24x7 and >>> have Seedboxes. Most of the time they have co-location boxes and/ >>> or pay >>> enterprise fees to have tons of bandwidth. >>> >>>> >>>> Getting adoption in major public P2P clients/trackers is >>>> certainly important >>>> in order for this to make a large difference for ISP networks. >>> >>> I believe, as I said before, that we need to convince users. The >>> only way to >>> convince such users is if we have a tight (very tight) security, >>> privacy >>> model. Otherwise the ALTO protocol might not see use in the wild. >>> >>> As far as convincing public trackers also means convincing the ISP >>> to have a >>> relationship with such trackers as thepiratebay. Does Comcast or >>> BT want to >>> have such relationship? I have no idea. I guess my point is that the >>> business/realities of P2P networks should drive the requirements >>> so we can >>> work with (or around them). >>> >>> Thanks, >>> >>> Reinaldo >>> >>> >>> _______________________________________________ >>> 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 Aug 4 08:48: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 D81993A6CD8; Mon, 4 Aug 2008 08:48: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 B18733A6CD8 for ; Mon, 4 Aug 2008 08:48:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.392 X-Spam-Level: X-Spam-Status: No, score=-2.392 tagged_above=-999 required=5 tests=[AWL=0.207, 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 0puhzFHiEm5c for ; Mon, 4 Aug 2008 08:48:56 -0700 (PDT) Received: from mailhost.jlc.net (mailhost.jlc.net [199.201.159.9]) by core3.amsl.com (Postfix) with ESMTP id 9A7BE3A6B6F for ; Mon, 4 Aug 2008 08:48:56 -0700 (PDT) Received: by mailhost.jlc.net (Postfix, from userid 104) id 5FF2233C43; Mon, 4 Aug 2008 11:49:11 -0400 (EDT) Date: Mon, 4 Aug 2008 11:49:11 -0400 From: John Leslie To: p2pi@ietf.org Message-ID: <20080804154911.GB19747@verdi> References: <20080731143742.GM10916@cisco.com> Mime-Version: 1.0 Content-Disposition: inline In-Reply-To: <20080731143742.GM10916@cisco.com> User-Agent: Mutt/1.4.1i Subject: [p2pi] Rock, meet Hard Place X-BeenThere: p2pi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: P2P Infrastructure Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: p2pi-bounces@ietf.org Errors-To: p2pi-bounces@ietf.org It would appear Comcast is under a deadline: http://hraunfoss.fcc.gov/edocs_public/attachmatch/DOC-284286A1.pdf ] ] Under the plan, within 30 days of release of the OrderComcast must: ] - Disclose the details of its discriminatory network management ] practices to the Commission ] - Submit a compliance plan describing how it intends to stop these ] discriminatory management practices by the end of the year ] - Disclose to customers and the Commission the network management ] practices that will replace current practices -- John Leslie _______________________________________________ p2pi mailing list p2pi@ietf.org https://www.ietf.org/mailman/listinfo/p2pi From p2pi-bounces@ietf.org Mon Aug 4 10:29: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 053323A6D25; Mon, 4 Aug 2008 10:29: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 825573A6D25 for ; Mon, 4 Aug 2008 10:29:21 -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 y774A-t+8PmE for ; Mon, 4 Aug 2008 10:29:20 -0700 (PDT) Received: from smtp0.neclab.eu (smtp0.neclab.eu [195.37.70.41]) by core3.amsl.com (Postfix) with ESMTP id 2E1983A69C8 for ; Mon, 4 Aug 2008 10:29:20 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp0.neclab.eu (Postfix) with ESMTP id 7CD092C01D461 for ; Mon, 4 Aug 2008 19:29:48 +0200 (CEST) X-Virus-Scanned: Amavisd on Debian GNU/Linux (atlas2.office) Received: from smtp0.neclab.eu ([127.0.0.1]) by localhost (atlas2.office [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kbde1WcO4Rx9 for ; Mon, 4 Aug 2008 19:29:48 +0200 (CEST) Received: from VENUS.office (mx1.office [192.168.24.3]) by smtp0.neclab.eu (Postfix) with ESMTP id 569602C009E93 for ; Mon, 4 Aug 2008 19:29:43 +0200 (CEST) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----_=_NextPart_001_01C8F657.AEE7C52F" Date: Mon, 4 Aug 2008 19:29:42 +0200 Message-ID: X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: My notes from the ALTO BoF Thread-Index: Acj2V64YNawSwPkcQFqS30oh/Tej7A== From: "Jan Seedorf" To: Subject: [p2pi] My notes from the ALTO BoF X-BeenThere: p2pi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: P2P Infrastructure Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: p2pi-bounces@ietf.org Errors-To: p2pi-bounces@ietf.org This is a multi-part message in MIME format. ------_=_NextPart_001_01C8F657.AEE7C52F Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dear all, Attached are my notes from the ALTO BoF. Kind regards, Jan =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Jan Seedorf Research Scientist NEC Europe Ltd., NEC Laboratories Europe, Network Division=09 Kurfuerstenanlage 36, D-69115 Heidelberg Tel. +49 (0)6221 4342-221 Fax: +49 (0)6221 4342-155 e-mail: jan.seedorf@nw.neclab.eu=20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D NEC Europe Limited Registered Office: NEC House, 1 Victoria Road, London W3 6BL Registered in England 2832014=20 ------_=_NextPart_001_01C8F657.AEE7C52F Content-Type: application/rtf; name="minutes_ALTO_bof_IETF72_jan_seedorf.rtf" Content-Transfer-Encoding: base64 Content-Description: minutes_ALTO_bof_IETF72_jan_seedorf.rtf Content-Disposition: attachment; filename="minutes_ALTO_bof_IETF72_jan_seedorf.rtf" e1xydGYxXGFkZWZsYW5nMTAyNVxhbnNpXGFuc2ljcGcxMjUyXHVjMVxhZGVmZjBcZGVmZjBcc3Rz aGZkYmNoMFxzdHNoZmxvY2gwXHN0c2hmaGljaDBcc3RzaGZiaTBcZGVmbGFuZzEwMzNcZGVmbGFu Z2ZlMTAzM3tcZm9udHRibHtcZjBcZnJvbWFuXGZjaGFyc2V0MFxmcHJxMntcKlxwYW5vc2UgMDIw MjA2MDMwNTA0MDUwMjAzMDR9VGltZXMgTmV3IFJvbWFuO317XGYxXGZzd2lzc1xmY2hhcnNldDBc ZnBycTJ7XCpccGFub3NlIDAyMGIwNjA0MDIwMjAyMDIwMjA0fUFyaWFsO317XGYzN1xmcm9tYW5c ZmNoYXJzZXQyMzhcZnBycTIgVGltZXMgTmV3IFJvbWFuIENFO30NCntcZjM4XGZyb21hblxmY2hh cnNldDIwNFxmcHJxMiBUaW1lcyBOZXcgUm9tYW4gQ3lyO317XGY0MFxmcm9tYW5cZmNoYXJzZXQx NjFcZnBycTIgVGltZXMgTmV3IFJvbWFuIEdyZWVrO317XGY0MVxmcm9tYW5cZmNoYXJzZXQxNjJc ZnBycTIgVGltZXMgTmV3IFJvbWFuIFR1cjt9e1xmNDJcZmJpZGkgXGZyb21hblxmY2hhcnNldDE3 N1xmcHJxMiBUaW1lcyBOZXcgUm9tYW4gKEhlYnJldyk7fQ0Ke1xmNDNcZmJpZGkgXGZyb21hblxm Y2hhcnNldDE3OFxmcHJxMiBUaW1lcyBOZXcgUm9tYW4gKEFyYWJpYyk7fXtcZjQ0XGZyb21hblxm Y2hhcnNldDE4NlxmcHJxMiBUaW1lcyBOZXcgUm9tYW4gQmFsdGljO317XGY0NVxmcm9tYW5cZmNo YXJzZXQxNjNcZnBycTIgVGltZXMgTmV3IFJvbWFuIChWaWV0bmFtZXNlKTt9e1xmNDdcZnN3aXNz XGZjaGFyc2V0MjM4XGZwcnEyIEFyaWFsIENFO30NCntcZjQ4XGZzd2lzc1xmY2hhcnNldDIwNFxm cHJxMiBBcmlhbCBDeXI7fXtcZjUwXGZzd2lzc1xmY2hhcnNldDE2MVxmcHJxMiBBcmlhbCBHcmVl azt9e1xmNTFcZnN3aXNzXGZjaGFyc2V0MTYyXGZwcnEyIEFyaWFsIFR1cjt9e1xmNTJcZmJpZGkg XGZzd2lzc1xmY2hhcnNldDE3N1xmcHJxMiBBcmlhbCAoSGVicmV3KTt9e1xmNTNcZmJpZGkgXGZz d2lzc1xmY2hhcnNldDE3OFxmcHJxMiBBcmlhbCAoQXJhYmljKTt9DQp7XGY1NFxmc3dpc3NcZmNo YXJzZXQxODZcZnBycTIgQXJpYWwgQmFsdGljO317XGY1NVxmc3dpc3NcZmNoYXJzZXQxNjNcZnBy cTIgQXJpYWwgKFZpZXRuYW1lc2UpO319e1xjb2xvcnRibDtccmVkMFxncmVlbjBcYmx1ZTA7XHJl ZDBcZ3JlZW4wXGJsdWUyNTU7XHJlZDBcZ3JlZW4yNTVcYmx1ZTI1NTtccmVkMFxncmVlbjI1NVxi bHVlMDtccmVkMjU1XGdyZWVuMFxibHVlMjU1O1xyZWQyNTVcZ3JlZW4wXGJsdWUwOw0KXHJlZDI1 NVxncmVlbjI1NVxibHVlMDtccmVkMjU1XGdyZWVuMjU1XGJsdWUyNTU7XHJlZDBcZ3JlZW4wXGJs dWUxMjg7XHJlZDBcZ3JlZW4xMjhcYmx1ZTEyODtccmVkMFxncmVlbjEyOFxibHVlMDtccmVkMTI4 XGdyZWVuMFxibHVlMTI4O1xyZWQxMjhcZ3JlZW4wXGJsdWUwO1xyZWQxMjhcZ3JlZW4xMjhcYmx1 ZTA7XHJlZDEyOFxncmVlbjEyOFxibHVlMTI4O1xyZWQxOTJcZ3JlZW4xOTJcYmx1ZTE5Mjt9e1xz dHlsZXNoZWV0ew0KXHFsIFxsaTBccmkwXHdpZGN0bHBhclx3cmFwZGVmYXVsdFxhc3BhbHBoYVxh c3BudW1cZmFhdXRvXGFkanVzdHJpZ2h0XHJpbjBcbGluMFxpdGFwMCBccnRsY2hcZmNzMSBcYWYw XGFmczI0XGFsYW5nMTAyNSBcbHRyY2hcZmNzMCBcZnMyNFxsYW5nMTAzM1xsYW5nZmUxMDMzXGNn cmlkXGxhbmducDEwMzNcbGFuZ2ZlbnAxMDMzIFxzbmV4dDAgTm9ybWFsO317XCpcY3MxMCBcYWRk aXRpdmUgXHNzZW1paGlkZGVuIA0KRGVmYXVsdCBQYXJhZ3JhcGggRm9udDt9e1wqXHRzMTFcdHNy b3dkXHRyZnRzV2lkdGhCM1x0cnBhZGRsMTA4XHRycGFkZHIxMDhcdHJwYWRkZmwzXHRycGFkZGZ0 M1x0cnBhZGRmYjNcdHJwYWRkZnIzXHRyY2JwYXQxXHRyY2ZwYXQxXHRibGluZDBcdGJsaW5kdHlw ZTNcdHNjZWxsd2lkdGhmdHMwXHRzdmVydGFsdFx0c2JyZHJ0XHRzYnJkcmxcdHNicmRyYlx0c2Jy ZHJyXHRzYnJkcmRnbFx0c2JyZHJkZ3JcdHNicmRyaFx0c2JyZHJ2IA0KXHFsIFxsaTBccmkwXHdp ZGN0bHBhclx3cmFwZGVmYXVsdFxhc3BhbHBoYVxhc3BudW1cZmFhdXRvXGFkanVzdHJpZ2h0XHJp bjBcbGluMFxpdGFwMCBccnRsY2hcZmNzMSBcYWYwXGFmczIwIFxsdHJjaFxmY3MwIFxmczIwXGxh bmcxMDI0XGxhbmdmZTEwMjRcY2dyaWRcbGFuZ25wMTAyNFxsYW5nZmVucDEwMjQgXHNuZXh0MTEg XHNzZW1paGlkZGVuIE5vcm1hbCBUYWJsZTt9fQ0Ke1wqXGxhdGVudHN0eWxlc1xsc2RzdGltYXgx NTZcbHNkbG9ja2VkZGVmMH17XCpccnNpZHRibCBccnNpZDMxNzI3OTFccnNpZDkxNzgyMjRccnNp ZDkxOTA4NDhccnNpZDEwOTY0NjE5XHJzaWQxNDkwMDcyMn17XCpcZ2VuZXJhdG9yIE1pY3Jvc29m dCBXb3JkIDExLjAuMDAwMDt9e1xpbmZve1xvcGVyYXRvciBKYW4gU2VlZG9yZn17XGNyZWF0aW1c eXIyMDA4XG1vOFxkeTNcaHIyMFxtaW43fQ0Ke1xyZXZ0aW1ceXIyMDA4XG1vOFxkeTRcaHIxOVxt aW4yOH17XHZlcnNpb241fXtcZWRtaW5zMTB9e1xub2ZwYWdlczN9e1xub2Z3b3JkczE0NTZ9e1xu b2ZjaGFyczgzMDN9e1xub2ZjaGFyc3dzOTc0MH17XHZlcm4yNDYxM317XCpccGFzc3dvcmQgMDAw MDAwMDB9fXtcKlx4bWxuc3RibCB7XHhtbG5zMSBodHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29t L29mZmljZS93b3JkLzIwMDMvd29yZG1sfX0NClxwYXBlcncxMjI0MFxwYXBlcmgxNTg0MFxtYXJn bDE4MDBcbWFyZ3IxODAwXG1hcmd0MTQ0MFxtYXJnYjE0NDBcZ3V0dGVyMFxsdHJzZWN0IA0KXHdp ZG93Y3RybFxmdG5ialxhZW5kZG9jXGRvbm90ZW1iZWRzeXNmb250MFxkb25vdGVtYmVkbGluZ2Rh dGExXGdyZmRvY2V2ZW50czBcdmFsaWRhdGV4bWwwXHNob3dwbGFjZWhvbGR0ZXh0MFxpZ25vcmVt aXhlZGNvbnRlbnQwXHNhdmVpbnZhbGlkeG1sMFxzaG93eG1sZXJyb3JzMFxob3J6ZG9jXGRnaHNw YWNlMTIwXGRndnNwYWNlMTIwXGRnaG9yaWdpbjE3MDFcZGd2b3JpZ2luMTk4NFxkZ2hzaG93MFxk Z3ZzaG93Mw0KXGpjb21wcmVzc1x2aWV3a2luZDRcdmlld3NjYWxlMTUwXHJzaWRyb290OTE3ODIy NCBcZmV0MHtcKlx3Z3JmZm10ZmlsdGVyIDAxM2Z9XGlsZm9tYWNhdGNsbnVwMFxsdHJwYXIgXHNl Y3RkIFxsdHJzZWN0XGxpbmV4MFxzZWN0ZGVmYXVsdGNsXHNmdG5iaiB7XCpccG5zZWNsdmwxXHBu dWNybVxwbnN0YXJ0MVxwbmluZGVudDcyMFxwbmhhbmcge1xwbnR4dGEgLn19e1wqXHBuc2VjbHZs Mg0KXHBudWNsdHJccG5zdGFydDFccG5pbmRlbnQ3MjBccG5oYW5nIHtccG50eHRhIC59fXtcKlxw bnNlY2x2bDNccG5kZWNccG5zdGFydDFccG5pbmRlbnQ3MjBccG5oYW5nIHtccG50eHRhIC59fXtc KlxwbnNlY2x2bDRccG5sY2x0clxwbnN0YXJ0MVxwbmluZGVudDcyMFxwbmhhbmcge1xwbnR4dGEg KX19e1wqXHBuc2VjbHZsNVxwbmRlY1xwbnN0YXJ0MVxwbmluZGVudDcyMFxwbmhhbmcge1xwbnR4 dGIgKH17XHBudHh0YSApfX17XCpccG5zZWNsdmw2DQpccG5sY2x0clxwbnN0YXJ0MVxwbmluZGVu dDcyMFxwbmhhbmcge1xwbnR4dGIgKH17XHBudHh0YSApfX17XCpccG5zZWNsdmw3XHBubGNybVxw bnN0YXJ0MVxwbmluZGVudDcyMFxwbmhhbmcge1xwbnR4dGIgKH17XHBudHh0YSApfX17XCpccG5z ZWNsdmw4XHBubGNsdHJccG5zdGFydDFccG5pbmRlbnQ3MjBccG5oYW5nIHtccG50eHRiICh9e1xw bnR4dGEgKX19e1wqXHBuc2VjbHZsOVxwbmxjcm1ccG5zdGFydDFccG5pbmRlbnQ3MjBccG5oYW5n IA0Ke1xwbnR4dGIgKH17XHBudHh0YSApfX1ccGFyZFxwbGFpbiBcbHRycGFyXHFsIFxsaTBccmkw XG5vd2lkY3RscGFyXHdyYXBkZWZhdWx0XGZhYXV0b1xyaW4wXGxpbjBcaXRhcDAgXHJ0bGNoXGZj czEgXGFmMFxhZnMyNFxhbGFuZzEwMjUgXGx0cmNoXGZjczAgXGZzMjRcbGFuZzEwMzNcbGFuZ2Zl MTAzM1xjZ3JpZFxsYW5nbnAxMDMzXGxhbmdmZW5wMTAzMyB7XHJ0bGNoXGZjczEgXGFmMVxhZnMy MCBcbHRyY2hcZmNzMCANClxmMVxmczIwXGluc3JzaWQ5MTc4MjI0XGNoYXJyc2lkOTE3ODIyNCBN ZWV0aW5nIG5vdGVzIGZyb20gQUxUTyBCb0YgYXQgSUVURi03Mg0KXHBhciBKdWx5IDI5dGgsIDIw MDgsIDk6MDAtMTE6MzAgYS5tLg0KXHBhciBOb3RlLXRha2VyOiBKYW4gU2VlZG9yZiAoamFuLnNl ZWRvcmZAbncubmVjbGFiLmV1KQ0KXHBhciB9e1xydGxjaFxmY3MxIFxhZjFcYWZzMjAgXGx0cmNo XGZjczAgXGYxXGZzMjBcaW5zcnNpZDkxNzgyMjQgDQpccGFyIH17XHJ0bGNoXGZjczEgXGFmMVxh ZnMyMCBcbHRyY2hcZmNzMCBcZjFcZnMyMFxpbnNyc2lkMzE3Mjc5MSAtLSBBYm91dCAzMDAgYXR0 ZW5kZWVzIGF0IHRoZSBCb0YNClxwYXIgfXtccnRsY2hcZmNzMSBcYWYxXGFmczIwIFxsdHJjaFxm Y3MwIFxmMVxmczIwXGluc3JzaWQzMTcyNzkxXGNoYXJyc2lkOTE3ODIyNCANClxwYXIgfXtccnRs Y2hcZmNzMSBcYWYxXGFmczIwIFxsdHJjaFxmY3MwIFxmMVxmczIwXGluc3JzaWQ5MTc4MjI0XGNo YXJyc2lkOTE3ODIyNCAtLSBjaGFpcnM6IFZpamF5IEd1cmJhbmkgYW5kIEVucmljbyBNYXJvY2Nv DQpccGFyIA0KXHBhciAtLSBWaWpheSBHdXJiYW5pIHByZXNlbnRzIHRoZSBhZ2VuZGEsIGFza2lu ZyBpZiB0aGVyZSBhcmUgYW55IG9iamVjdGlvbnMgdG8gdGhlIGFnZW5kYSwgdGhlcmUgYXJlIG5v bmUNClxwYXIgDQpccGFyIC0tIEVucmljbyBNYXJvY2NvIHByZXNlbnRzIHRoZSBwcm9ibGVtIHN0 YXRlbWVudCBmb3IgQUxUTzogUDJQIHRyYWZmaWMgYWNjb3VudHMgZm9yIG1vc3QgaW50ZXJuZXQg dHJhZmZpYyB0b2RheTsgdGhlcmUgaGFzIGJlZW4gYSBQMlAgSW5mcmFzdHJ1Y3R1cmUgV29ya3No b3Agb3JnYW5pemVkIGJ5IHRoZSBSQUkgQURzLCBhdCB0aGUgd29ya3Nob3AgdGhyZWUgd29yayBh cmVhcyBmb3IgdGhlIElFVEYgaGF2ZX17XHJ0bGNoXGZjczEgDQpcYWYxXGFmczIwIFxsdHJjaFxm Y3MwIFxmMVxmczIwXGluc3JzaWQxMDk2NDYxOSAgYmVlbn17XHJ0bGNoXGZjczEgXGFmMVxhZnMy MCBcbHRyY2hcZmNzMCBcZjFcZnMyMFxpbnNyc2lkOTE3ODIyNFxjaGFycnNpZDkxNzgyMjQgDQog aWRlbnRpZmllZCwgYW1vbmcgdGhlc2UgQUxUTyByZWZlcnMgdG8gY2FjaGluZyBhbmQgbG9jYWxp emF0aW9uOyB0aGUgQUxUTyBwcm9ibGVtIGlzIGJhc2ljYWxseSB0aGF0IHRoZSBwZWVycyBoYXZl IG5vIGtub3dsZWRnZSBvZiB0aGUgbmV0d29yayB0b3BvbG9neTsgQUxUTyBwcm9wb3NlcyB0byBk ZWZpbmUgYW4gaW50ZXJmYWNlIGZvciBhIHBlZXIgc2VsZWN0aW9uIG9wdGltaXphdGlvbiBzZX17 XHJ0bGNoXGZjczEgXGFmMVxhZnMyMCANClxsdHJjaFxmY3MwIFxmMVxmczIwXGluc3JzaWQ5MTc4 MjI0IHJ2aWNlfXtccnRsY2hcZmNzMSBcYWYxXGFmczIwIFxsdHJjaFxmY3MwIFxmMVxmczIwXGlu c3JzaWQ5MTc4MjI0XGNoYXJyc2lkOTE3ODIyNCANCjsgdGhlcmUgY2FuIGJlIGRpZmZlcmVudCBr aW5kcyBvZiBBTFRPIHNlcnZpY2UgcHJvdmlkZXJzOyByZXNlYXJjaCBoYXMgc2hvd24gdGhhdCBz dWNoIGEgc2VydmljZSBjYW4gaW1wcm92ZSBQMlAgcm91dGluZyB3aXRoIHJlc3BlY3QgdG8gSVNQ cycgbG9hZCBhbmQgb3RoZXIgdGhpbmdzOyBpc3N1ZXMgaW5jbHVkZSBJU1BzIHdhbnRpDQpuZyB0 byBoaWRlIHRoZWlyIHRvcG9sb2d5IGFuZCBwb3NzaWJseSBtaXNiZWhhdmluZyBBTFRPIHNlcnZp Y2VzOyB0aGUgY29yZSBnb2FscyBvZiBBTFRPIGFyZSB0byBoYXZlIGEgcHJvdG9jb2wgZm9yIGZp bmRpbmcgdGhlIEFMVE8gb3JhY2xlIGFuZCBhIHByb3RvY29sIGZvciBxdWVyeWluZyB0aGUgb3Jh Y2xlOyB0aGVyZSBhcmUgc2V2ZXJhbCB1c2UgY2FzZXMgZm9yIEFMVE8sIGluY2x1ZGluZyByZWFs LXRpbWUgY29tbXVuaWNhdGlvbnMsIFANCjJQIHN0cmVhbWluZywgcHJveGltaXR5IG5laWdoYm9y IHNlbGVjdGlvbiBpbiBESFRzOyANClxwYXIgDQpccGFyIC0tIHF1ZXN0aW9ucy9jb21tZW50czoN ClxwYXIgPz86IGRvZXMgQkdQIG5vdCBnaXZlIHlvdSBpbmZvcm1hdGlvbiBhYm91dCB0aGUgQVMg b2Ygb3RoZXIgcGV9e1xydGxjaFxmY3MxIFxhZjFcYWZzMjAgXGx0cmNoXGZjczAgXGYxXGZzMjBc aW5zcnNpZDEwOTY0NjE5IGVycz8gSm9uIFBldGVyc29uOiB0aGUgcXVlc3Rpb259e1xydGxjaFxm Y3MxIFxhZjFcYWZzMjAgXGx0cmNoXGZjczAgXGYxXGZzMjBcaW5zcnNpZDkxNzgyMjRcY2hhcnJz aWQ5MTc4MjI0IA0KIGlzIG5vdCBpZiBhcHBsaWNhdGlvbnMgY2FuIGdldCBpbmZvcm1hdGlvbiBz b21laG93LCB0aGlzIEJvZiBzaGFsbCBleHBsb3JlIGlmIHRoZXJlIGlzIGEgbmVlZCBmb3IgYSBz dGFuZGFyZCBmb3IgYXBwbGljYXRpb25zIHRvIG9idGFpbiB0aGlzIGluZm9ybWF0aW9uOw0KXHBh ciA/Pzogd2hhdCB3aWxsIGJlIG9wdGltaXplZCwgdGhlIFAyUCB0cmFmZmljIG9yIGZvciB0aGUg bm9uLVAyUCB0cmFmZmljPw0KXHBhciBIZW5uaW5nIFNjaHVsenJpbm5lOiB3b3VsZCBsaWtlIHRv IGhhdmUgYSBzZXQgb2YgYXBwbGljYXRpb24gc2NlbmFyaW9zOyBhcmUgbm9uLVAyUCBhcHBsaWNh dGlvbnMgaW4gdGhlIHNjb3BlIG9mIEFMVE8/OyBFbnJpY286IHllczsgDQpccGFyIFRlZCBIYXJk aWU6IHRoaW5rcyB0aGlzIHByb2JsZW0gc3RhdGVtZW50IGdvZXMgaW4gdGhlIHJpZ2h0IGRpcmVj dGlvbjsgd2hhdCB3aWxsIGJlIG9wdGltaXplZCB3aWxsIHByb2JhYmx5IGRlcGVuZCBvbiB0aGUg QUxUTyBzZXJ2aWNlOyBpcyBBTFRPIHNjb3BlZCB0byBhIHNwZWNpZmljIG9wdGltaXphdGlvbiBm b3IgaW50ZXItZG9tYWluIHRyYWZmaWM/IEVucmljbzogbm87DQpccGFyID8/OiBjYW4gY2xpZW50 IGNsYWltIHRvIGJlIGEgcGVlciBvciB3aWxsIHRoYXQgaWRlbnRpdHkgYmUgYXNjZXJ0YWluZWQg YnkgYSBzZXJ2ZXI/DQpccGFyIA0KXHBhciAtLSBNYXJjbyBUb21zdSBwcmVzZW50ZWQgYSBzdXJ2 ZXkgb24gZXhpc3Rpbmcgd29yayByZWxhdGVkIHRvIHRoZSBBTFRPIHNjb3BlOiBmdW5kYW1lbnRh bCBxdWVzdGlvbiBpcyBob3cgdG8gc2VsZWN0IGEgZ29vZCBwZWVyPyB0aGlzIGNhbiBiZSBkb25l IG9uIHRoZSBhcHBsaWNhdGlvbiBsZXZlbCBvciB3aXRoIGxheWVyIGNvb3BlcmF0aW9uLCBkaWZm ZXJlbnQgc29sdXRpb25zIGV4aXN0IGZvciBlYWNoIG9mIHRoZXNlIGFwcHJvYWNoZXM7DQoNClxw YXIgDQpccGFyIC0tIHF1ZXN0aW9ucy9jb21tZW50czoNClxwYXIgSGVucnkgU2lubnJlaWNoOiB0 aGUgbW9kZWwgdGhhdCBhbiBJU1Agb3ducyBhIG5ldHdvcmsgbWF5IGJlIGZhbHNlOyANClxwYXIg Sm9uIFBldGVyc29uOiB0aGlzIHJlbGF0ZWQgd29yayBpcyBub3Qgd2hhdCB3aWxsIGJlIHN0YW5k YXJkaXplZCwgcmF0aGVyIHRoZSBpbnRlcmZhY2UgYWJvdXQgcXVlcnlpbmcgYW4gb3JhY2xlIGlz IGluIHRoZSBzY29wZSBvZiBBTFRPDQpccGFyIEhlbm5pbmcgU2NodWx6cmlubmU6IGl0IG5lZWRz IHRvIGJlIGludmVzdGlnYXRlZCBpZiBhbGwgdGhlIGV4aXN0aW5nIGFwcHJvYWNoZXMgZml0IGlu IHRoZSBBTFRPIGFwcHJvYWNoLCBzcGVjaWZpY2FsbHksIGRvIHNvbWUgZXhpc3Rpbmcgc29sdXRp b25zIG5vdCBmaXQgaW4gdGhlIEFMVE8gYXBwcm9hY2g/DQpccGFyIExhcnMgRWdnZXJ0OiBBTFRP IG5lZWRzIHRvIGNvbnNpZGVyIHdoYXQgdGhlIA0Kc2VtYW50aWNzIG9mIHRoZSBpbmZvcm1hdGlv biByZXR1cm5lZCBieSBhbiBBTFRPIHNlcnZpY2UgaXMsIGkuZS4sIHdoYXQgZG9lcyB0aGUgaW5m b3JtYXRpb24gYWN0dWFsbHkgbWVhbiBtYXkgaW5mbHVlbmNlIEFMVE8gZGVzaWduIGFuZCBuZWVk cyB0byBiZSBjb25zaWRlcmVkOyBBTFRPIHNob3VsZCBub3QgYmUgc3BlY2lmaWMgYnV0IHJhdGhl ciBjb25jZXJuIHRoZSB1bmlmaWVkIHNldCBvZiBlbGVtZW50cyBuZWNlc3NhcnkNClxwYXIgDQpc cGFyIC0tIEhlbm5pbg0KZyBTY2h1bHpyaW5uZSBwcmVzZW50ZWQgb24gYmFuZHdpZHRoIGNvc3Rz OiBsb25nIHRlcm0gZ29hbCBpcyB0byBtaW5pbWl6ZSBiYW5kd2lkdGggY29zdHM7IHRoZSBhdmVy YWdlIGJhbmR3aWR0aCBjb3N0cyBvbiB0aGUgSW50ZXJuZXQgYXJlIGRlY3JlYXNpbmcgb3ZlciB0 aW1lOyBpZiB3ZSBtb3ZlIHRvIGFuIGV4cGxpY2l0IHByaWNpbmcgbW9kZWwsIHdpbGwgdGhlcmUg YmUgYXBwbGljYXRpb24tdmlzaWJsZSBjaGFyZ2luZyBpbmRpY2F0aW9uDQogKGdhdmUgZXhhbXBs ZXMsIGUuZy4sICJ5b3UgYXJlIGN1cnJlbnRseSBpbiB5b3VyIHBlbmFsdHkgYm94Iik7IHRoZSBB TFRPIHByb2JsZW0gaW4gZXNzZW5jZSBpcyBhbiBlY29ub21pY3MgcHJvYmxlbSwgaXQgaXMgdG99 e1xydGxjaFxmY3MxIFxhZjFcYWZzMjAgXGx0cmNoXGZjczAgXGYxXGZzMjBcaW5zcnNpZDkxNzgy MjQgb317XHJ0bGNoXGZjczEgXGFmMVxhZnMyMCBcbHRyY2hcZmNzMCANClxmMVxmczIwXGluc3Jz aWQ5MTc4MjI0XGNoYXJyc2lkOTE3ODIyNCAgc2hvcnQtc2lnaHRlZCB0byBsb29rIGF0IHRoZSBw cm9ibGVtIGZyb20gYSB0ZWNobmljYWwgcGVyc3BlY3RpdmUgb25seQ0KXHBhciANClxwYXIgLS0g cXVlc3Rpb25zL2NvbW1lbnRzOg0KXHBhciBIZW5ucmljaCBTaW5ucmVpY2g6IHRoZSBiYWNraGF1 bCBjb3N0cyBhcmUgdGhlIGltcG9ydGFudCBmYWN0b3IgcmVnYXJkaW5nIGVjb25vbWljcyAoaS5l LiwgaG93IGlzIGFuIElTUCBjb25uZWN0ZWQgdG8gdGhlIGdsb2JhbCBpbnRlcm5ldCkNClxwYXIg Pz86IGNvc3Qgb2YgcHJvdmlkaW5nIGJhbmR3aWR0aCBpcyBkaWZmZXJlbnQgdG8gdGhlIGNvc3Qg b2YgdXNpbmcgYmFuZHdpZHRoOyB0aGUgZ29hbCBvZiBBTFRPIHNob3VsZCBiZSBhYm91dCBhZG9w dGluZyB0byBydW4tdGltZSBjb25kaXRpb25zDQpccGFyID8/OiBldmVyeSBwcm92aWRlciBoYXMg YSBkaWZmZXJlbnQgY29zdCBtb2RlbDsgSGVubmluZzogdGhlcmUgYXJlIGFscmVhZHkgcHJvYmxl bXMgd2l0aCB1c2VycyBydW5uaW5nIGludG8gdGhlICJwZW5hbHR5IGJveCIgcHJvYmxlbQ0KXHBh ciA/PzogaWYgeW91IHJlZmVyIGV2ZXJ5Ym9keSB0byBkb3dubG9hZCBsYXRlciBhbmQgZXZlcnli b2R5IGRvZXMgdGhhdCwgeW91IGhhdmUgbm90IHNvbHZlZCB0aGUgcHJvYmxlbTsgSGVubmluZzog dGhhdCBpcyBhbiBhbGdvcml0aG1pYyBwcm9ibGVtDQpccGFyIA0KXHBhciAtLSBTZWJhc3RpYW4g S2llc2VsIHByZXNlbnRlZCBBTFRPIHJlcXVpcmVtZW50czogcmVxdWlyZW1lbnRzIGFyZSBpbmRl cGVuZGVudCBvZiBzb2x1dGlvbnMsIGhvd2V2ZXIgbG9va2luZyBhdCBhbiBleGFtcGxlIGhvdyBB TFRPIGNvdWxkIGxvb2sgbGlrZSBtYWtlcyBzZW5zZTsgZ2l2ZXMgYW4gZXhhbXBsZSBvbiBob3cg QUxUTyBjb3VsZCB3b3JrIGluIGEgdHJhY2tlci1iYXNlZCBQMlAgbmV0d29yazsgdGhlDQpyZSBp cyBhbHJlYWR5IGFuIHRlcm1pbm9sb2d5IGluIGEgdmVyeSBlYXJseSBzdGFnZTsgbGV0J3MgZm9j dXMgb24gcXVlcnlpbmcgdGhlIEFMVE8gc2VydmljZSBieSBjbGllbnRzIGZvciBub3csIGFuZCBu b3Qgb24gZmVlZGluZyB0aGUgQUxUTyBzZXJ2aWNlIHdpdGggaW5mb3JtYXRpb24gbm9yIGNvb3Jk aW5hdGlvbiBhbW9uZyBBTFRPIHNlcnZlcnM7IHRoZSBpbmZvcm1hdGlvbiBhdmFpbGFibGUgZnJv bSB0aGUgQUxUTyBzZXJ2aWNlIGlzIG4NCm90IGEgcmVwbGFjZW1lbnQgZm9yIGNvbmdlc3Rpb24g Y29udHJvbCBtZWNoYW5pc21zOyBBTFRPIHJlcXVpcmVtZW50cyBhcmUgcmVnYXJkaW5nIHRoZSBB TFRPIGludGVyZmFjZSwgZXJyb3IgaGFuZGxpbmcgYW5kIG92ZXJsb2FkIHByb3RlY3Rpb24sIGFu ZCBzZWN1cml0eS9wcml2YWN5OyB0aGVyZSBhcmUgc3RpbGwgcXVpdGUgYSBmZXcgb3BlbiBpc3N1 ZXM7DQpccGFyIA0KXHBhciAtLSBxdWVzdGlvbnMvY29tbWVudHM6DQpccGFyID8/OiBhIGxpZmV0 aW1lIGF0dHJpYnV0ZSBpfXtccnRsY2hcZmNzMSBcYWYxXGFmczIwIFxsdHJjaFxmY3MwIFxmMVxm czIwXGluc3JzaWQxMDk2NDYxOSBzIG5vdCBlbm91Z2gsIHRoZSBkZX17XHJ0bGNoXGZjczEgXGFm MVxhZnMyMCBcbHRyY2hcZmNzMCBcZjFcZnMyMFxpbnNyc2lkOTE3ODIyNFxjaGFycnNpZDkxNzgy MjQgY2F5IG9mIGluZm9ybWF0aW9uIHByb3ZpZGVkIGJ5IEFMVE8gbmVlZHMgdG8gYmUga25vd24g dG8gdGhlIGNsaWVudA0KDQpccGFyID8/OiBwZWVyIHNlbGVjdGlvbiBpcyBhIHByb2Nlc3MgaGFw cGVuaW5nIG9uIGJvdGggc2lkZXMgKHByb3ZpZGVyIGFuZCByZWNlaXZlciBvZiBjb250ZW50KQ0K XHBhciBIZW5yeSBTaW5ucmVpY2g6IHNob3VsZCBub3QgYmUgdGhlIFAyUCBwcm92aWRlcnMgYmUg cGFydCBvZiB0aGUgQUxUTyBkZXNpZ24gdGVhbTsgSm9uIFBldGVyc29uOiB0aGlzIGJvZiB3b3Vs ZCBub3QgdGFrZSBwbGFjZSBpZiB0aGVyZSBoYWQgbm90IGJlZW4gY29uc2lkZXJhYmxlIGlucHV0 IGFuZCBzdXBwb3J0IGZyb20gUDJQIHByb3ZpZGVycw0KXHBhciBMYXJzIEVnZ2VydDogQUxUTyBz aG91bGQgaGF2ZSB1c2luZyBUQ1AgYXMgYW4gcmVxdWlyZW1lbnQNClxwYXIgSmFzb24gTGl2aW5n b29kOiB0aGVyZSBhcmUgaXNzdWVzIHdpdGggdGhlIGFtb3VudCBvZiBpbmZvcm1hdGlvbiBhbiBv cGVyYXRvciBpcyB3aWxsaW5nIHRvIGRpc2Nsb3NlDQpccGFyIA0KXHBhciAtLSBSZWluYWxkbyBQ ZW5ubyBwcmVzZW50ZWQgb24gY2FjaGluZyBhbmQgcGVlciBzZWxlY3Rpb24gaW4gQUxUTzogdGhl cmUgYXJlIHNldmVyYWwgdHlwZXMgb2YgZGlzY292ZXJ5OyB0aGUgbmV4dCBzdGVwIGlzIHRvIGNv bWUgdXAgd2l0aCBhIGRvY3VtZW50IG9uIGRpc2NvdmVyeSBmb3IgQUxUTyBzZXJ2ZXJzIGFuZCBj YWNoZXMNClxwYXIgDQpccGFyIC0tIHF1ZXN0aW9ucy9jb21tZW50czoNClxwYXIgRGF2aWQgT3Jh bjogdGhlcmUgaXMgYSBkaWZmZXJlbmNlIGJldHdlZW4gdGhlIGRpc2NvdmVyeSBvZiB1bmtub3du IHBlZXJzIGFuZCB0aGUgcmF0aW5nIG9mIGtub3duIHBlZXJzDQpccGFyID8/OiBkb2VzIGRpc2Nv dmVyeSBoYXZlIHRvIGJlIGNvbWJpbmVkIHdpdGggcmF0aW5nPw0KXHBhciANClxwYXIgLS0gRC4g UGFwYWRpbWl0cmlvdSBwcmVzZW50ZWQgb24gc2ltaWxhciBwcm9ibGVtcyBpbiBtdWx0aS1ob21l ZCBuZXR3b3JrczogdGhlIEFMVE8gcHJvYmxlbSBpcyBzZWxlY3RpbmcgdGhlIGJlc3QgcGVlcg0K IGZyb20gYSBzd2FybTsgdGhpcyBpcyBzaW1pbGFyIHRvIHRoZSBtdWx0aWhvbWluZyBwcm9ibGVt IGFuZCBJUHY0LUlQdjYgRFM7IHRoZSBwcm9ibGVtIGlzIGdlbmVyaWMsIHRoZSBjb21tb24gcHJv YmxlbSBpcyBiZXN0IHBhdGggc2VsZWN0aW9uOyBBTFRPIGNhbiBiZSB1c2VkIGZvciB0aGUgY29t bW9uIHByb2JsZW0gaWYgQUxUTyBkb2VzIG5vdCByZXN0cmljdCBpdHMgdXNhYml9e1xydGxjaFxm Y3MxIFxhZjFcYWZzMjAgXGx0cmNoXGZjczAgDQpcZjFcZnMyMFxpbnNyc2lkOTE5MDg0OCBsfXtc cnRsY2hcZmNzMSBcYWYxXGFmczIwIFxsdHJjaFxmY3MwIFxmMVxmczIwXGluc3JzaWQ5MTc4MjI0 XGNoYXJyc2lkOTE3ODIyNCBpdHkgYW5kIGV4dGVuc2liaWxpdHkgYW5kIGlmIHRoZSBBTFRPIHBy b3RvY29sIHN1cHBvcnRzIHRyYW5zcG9ydCBhZGRyZXNzZXM7DQpccGFyIA0KXHBhciAtLSBubyBx dWVzdGlvbnMgbm9yIGNvbW1lbnRzIG9uIHRoaXMgcHJlc2VudGF0aW9uIChELiBQYXBhZGltaXRy aW91KQ0KXHBhciANClxwYXIgLS0gVmlqYXkgR3VyYmFuaSBwcmVzZW50ZWQgdGhlIGNoYXJ0ZXIg Zm9yIEFMVE86IHRoZSBwcm9ibGVtIGNvbnNpc3RzIGluIG9wdGltaXppbmcgcGVlciBzZWxlY3Rp b247IFdHIHdpbGwgcHJvZHVjZSBwcm90b2NvbHMgdG8gZW5hYmxlIGNvbW11bmljYQ0KdGlvbiBi ZXR3ZWVuIFAyUCBzeXN0ZW1zIGFuZCAiaW5mb3JtZWQiIGV4dGVybmFsIHNlcnZpY2VzLCBhbGwg a2luZHMgb2YgUDJQIHN5c3RlbXMgYXJlIGNvbnNpZGVyZWQ7IHdvcmsgaXRlbXMgaW5jbHVkZSBz dXJ2ZXksIHRheG9ub215LCBhIHJlcXVpcmVtZW50cyBkb2N1bWVudCwgYSBkaXNjb3ZlcnkgbWVj aGFuaXNtIGZvciBsb2NhdGluZyB0aGUgb3JhY2xlLCBhIHF1ZXJ5L3Jlc3BvbnNlIHByb3RvY29s IGZvciBjb21tdW5pY2F0aW5nIHdpDQp0DQpoIHRoZSBvcmFjbGUgKGNvcmUgcHJvdG9jb2wgb2Yg QUxUTyksIGRpc2NvdmVyeSBtZWNoYW5pc20gZm9yIGxvY2F0aW5nIHNwZWNpYWwgbm9kZXMgKGUu Zy4sIGNhY2hlcywgbWVkaWEgcmVsYXlzKTsgdGhlIGZvY3VzIHNoYWxsIGJlIG9uIHRoZSBBTFRP IGludGVyZmFjZSwgYWxnb3JpdGhtcyBmb3IgYWN0dWFsbHkgaW1wbGVtZW50aW5nIHRoZSBzZXJ2 aWNlIGFyZSBvdXQgb2Ygc2NvcGU7IGxlZ2FsIGlzc3VlcyBhcmUgb3V0IG9mIHNjb3BlOyANCg0K XHBhciANClxwYXIgLS0gcXVlc3Rpb25zL2NvbW1lbnRzOg0KXHBhciBUZWQgSGFyZGllOiB0aGVy ZSBpcyBzb21lIGNvbmZ1c2lvbiBhYm91dCB0aGUgV0cgaXRlbXMgcmVnYXJkaW5nIGRpc2NvdmVy eTsNClxwYXIgSm9uIFBldGVyc29uOiBhdCB0aGlzIHN0YWdlIGl0IGlzIG5vdCBpbXBvcnRhbnQg dG8gcHJlY2lzZWx5IGRpc3Rpbmd1aXNoL2xpbWl0IHRoZSBXRyBpdGVtcyByZWdhcmRpbmcgZGlz Y292ZXJ5Ow0KXHBhciBUZWQgSGFyZGllOiB3aGF0IGlzIHRoZSBzY29wZSBpbiB0aGUgY2hhcnRl ciBmb3Igd29yayBub3QgZGlyZWN0bHkgcmVsYXRlZCB0byB0aGUgQUxUTyBwcm9ibGVtIHNwYWNl LCB0aGlzIHJlbGF0ZXMgdG8gZGlzY292ZXJ5IG9mLCBlLmcuLCBUVVJOIHNlcnZlcnM/DQpccGFy IEhlbm5pbmcgU2NodWx6cmlubmU6IGRvIHdlIHdhbnQgdG8gYnVpbGQgYW4gb3ZlcmFsbCBmcmFt ZXdvcmsgb3Igc2VwYXJhdGUgcXVlcnkgbWVjaGFuaXNtcz8sIHNlcGFyYXRpb24gaXMgYSBnb29k IHRoaW5nLCBjb25jZXJucyBhYm91dCBhIGdlbmVyYWwgcHJvdG9jb2wgZm9yIGRpZmZlcmVudCB1 c2VzDQpccGFyIERhdmlkIE9yYW46IHRoZXJlIGlzIGEgZGlmZmVyZW5jZSBiZXR3ZWVuIHByZWNv bmRpdGlvbnMgYW5kIHJlcXVpcmVtZW50cywgdGhpcyBuZWVkcyB0byBiZSBzb3J0ZWQgb3V0DQpc cGFyIEpvbiBQZXRlcnNvbjogdGhlIHJlcXVpcmVtZW50cyBuZWVkIHRvIGJlIHdvcmtlZCBvbiwg YnV0IHRoaXMgaXMgbm90IGFuIGlzc3VlIGZvciB0aGUgY2hhcnRlcg0KXHBhciBKb24gUGV0ZXJz b246IHRoZSBkaXNjdXNzaW9uIHNob3VsZCBiZSBpZiB0aGVyZSBpcyBjb25zZW5zdXMgdGhhdCB0 aGUgSUVURiB3YW50cyB0byB3b3JrIG9uIHRoYXQgYW5kIGlmIHRoZXJlIGlzIGEgZGlzY3JldGUg c2NvcGUNClxwYXIgPz86IHdoYXQgYXJlIHRoZSBzZW1hbnRpY3Mgb2YgdGhlIGludGVyZmFjZT8N ClxwYXIgR3JlZyA/OiB3aWxsIGFuIGV4aXN0aW5nIGRpc2NvdmVyeSBwcm90b2NvbCBiZSB1c2Vk IChhcyBwYXJ0IG9mIHRoZSByZXF1aXJlbWVudHMpPyB3aWxsIHRoZSBiYXIgYmUgaGlnaCB0byBk ZWZpbmUgYSBuZXcgZGlzY292ZXJ5IHByb3RvY29sPw0KXHBhciBEYXZpZCBPcmFuOiB0aGlzIHNo b3VsZCBub3QgYmUgYSBxdWVzdGlvbiBmb3IgdGhlIHJlcXVpcmVtZW50cyBkb2N1bWVudA0KXHBh ciBHcmVnID86IGlmIGFuIGV4aXN0aW5nIGRpc2NvdmVyeSBwcm90b2NvbCB3aWxsIGJlIHVzZWQs IGlzIHRoZXJlIHRoYW4gYSBuZWVkIGZvciB3b3JrIHJlbGF0ZWQgdG8gZGlzY292ZXJ5IGluIEFM VE8/IGlzIHRoZXJlIGEgZ2VuZXJpYyBkaXNjb3ZlcnkgcHJvYmxlbSBhbmQgaXMgdGhhdCB3aGF0 IHRoZSBjaGFydGVyIGlzIGFib3V0Pw0KXHBhciA/PzogaG93IG11Y2ggb3ZlcmxhcCBpcyB0aGVy ZSB3aXRoIFAyUFNJUD8NClxwYXIgVmlqYXkgR3VyYmFuaTogQUxUTyBjYW4gYmUgdXNlZCBieSBQ MlBTSVAgYnV0IGFsc28gYnkgb3RoZXJzDQpccGFyIEpvaG4gPzogaXQgbmVlZHMgdG8gYmUgc2Vw YXJhdGVkIHdoaWNoIHRoaW5nfXtccnRsY2hcZmNzMSBcYWYxXGFmczIwIFxsdHJjaFxmY3MwIFxm MVxmczIwXGluc3JzaWQ5MTkwODQ4IHN9e1xydGxjaFxmY3MxIFxhZjFcYWZzMjAgXGx0cmNoXGZj czAgXGYxXGZzMjBcaW5zcnNpZDkxNzgyMjRcY2hhcnJzaWQ5MTc4MjI0ICBhcmUgYWxyZWFkeSBk b25lIGJ5IGJpdHRvcnJlbg0KdCwgdGhlbiBsb29rIHdoYXQgaXMgZG9uZSBieSBvdGhlciBXR3Ms IGFuZCB0aGVuIGRvIHdoYXQgaXMgbGVmdCBhbmQgbm90IGRvbmUgc28gZmFyDQpccGFyIH17XHJ0 bGNoXGZjczEgXGFmMVxhZnMyMCBcbHRyY2hcZmNzMCBcZjFcZnMyMFxpbnNyc2lkOTE3ODIyNCBI ZW5uaW5nIFNjaHVsenJpbm5lOiB0ZXJtaW5vbG9neSBuZWVkcyB0byBiZSBkZWZpbmVkIGJldHRl ciwgZS5nLiwgdGhlcmUgYXJlIGRpZmZlcmVudCBpbnRlcnByZXRhdGlvbnMgcmVnYXJkaW5nICJk aXNjb3ZlcnkiDQpccGFyIExhcnMgRWdnZXJ0OiBUQU5BIGlzIGFsbCBhYm91dCBjb25lc3Rpb24g Y29udHJvbCBhbmQgZGVhbGluZyB3aXRoIFAyUCBkYXRhIHRyYW5zbWlzc2lvbnM7IEFMVE8gbWln aHQgb3IgbWlnaHQgbm90IGhhdmUgb3RoZXIgdHJhbnNwb3J0IGlzc3VlczsgY29uY2VybnMgd2l0 aCBwcm9wb3NhbHMgdGhhdCB3YW50fXtccnRsY2hcZmNzMSBcYWYxXGFmczIwIFxsdHJjaFxmY3Mw IFxmMVxmczIwXGluc3JzaWQ5MTkwODQ4IHN9e1xydGxjaFxmY3MxIA0KXGFmMVxhZnMyMCBcbHRy Y2hcZmNzMCBcZjFcZnMyMFxpbnNyc2lkOTE3ODIyNCAgdG8gYXNrIHRoaW5ncyBsaWtlIGRlbGF5 LCByYXRoZXIgc3RhdGljIGluZm9ybWF0aW9uIHNob3VsZCBiZSBxdWVyaWVkDQpccGFyIFRlZCBI YXJkaWU6IHRoaW5rcyB0aGUgSUVURiBzaG91bGQgd29yayBvbiB0aGlzIHByb2JsZW0sIHRoZXJl IGFyZSBwcm9ibGVtcyB3aXRoIHNlbWFudGljcyB0aGF0IG5lZWQgdG8gYmUgY29uc2lkZXJlZA0K XHBhciANClxwYXIgLS0gdGhlcmUgd2FzIGEgaHVtOiBtYW55IHBlb3BsZSBhZ3JlZWQgdGhhdCB0 aGlzIGlzIGltcG9ydGFudCB3b3JrIGZvciB0aGUgSUVURiwgYWxzbyBzb21lIChsZXNzKSBwZW9w bGUgaHVtbWVkIHN0cm9uZ2x5IGFnYWluc3QgdGhlIElFVEYgd29ya2luZyBvbiB0aGlzfXtccnRs Y2hcZmNzMSBcYWYxXGFmczIwIFxsdHJjaFxmY3MwIFxmMVxmczIwXGluc3JzaWQ5MTkwODQ4IDsg b3ZlcmFsbCwgbm8gYWdyZWVtZW50IGNvdWxkIGJlIGZvdW5kfXsNClxydGxjaFxmY3MxIFxhZjFc YWZzMjAgXGx0cmNoXGZjczAgXGYxXGZzMjBcaW5zcnNpZDkxNzgyMjQgDQpccGFyIA0KXHBhciBK b24gUGV0ZXJzb246IEFMVE8gd29yayB3b3VsZCBnaXZlIGNyZWRpYmlsaXR5IHRvIHRoZSBJRVRG IGZvciBzb2x2aW5nIGFuIGltcG9ydGFudCBwcm9ibGVtDQpccGFyIExhcnMgRWdnZXJ0OiBuZWVk cyB0byBrbm93IHdoYXQgaW5mb3JtYXRpb24gd2lsbCBiZSBxdWVyaWVkIHRvIGRlY2lkZSB0aGlz DQpccGFyIEpvbmF0aGFuIFJvc2VuYmVyZzogaWYgdGhpcyBpcyBub3QgYW4gaW1wb3J0YW50IHBy b2JsZW0gZm9yIHRoZSBJRVRGLCB3aGljaCBwcm9ibGVtIGlzIGF0IGFsbD8gc3VwcG9ydGluZyB0 aGlzDQpccGFyID8/OiB3aGF0IGluZm9ybWF0aW9uIHdpbGwgYmUgcXVlcmllZD8NClxwYXIgSmFz b24gTGl2aW5nb29kOiB0aGlzIGlzIGEgYmlnIHByb2JsZW0gZm9yIHNlcnZpY2UgcHJvdmlkZXJz IGFuZCBpdCBpcyBtZWFuaW5nZnVsIHRvIHdvcmsgb24gdGhpcw0KXHBhciBMYWlyZCBQb3BraW46 IHN0cm9uZ2x5IHN1Z2dlc3RlZCB0aGF0IHRoaXMgd2lsbCBiZSB3b3JrZWQgb24gaW4gdGhlIElF VEYNClxwYXIgPz86IHN0cm9uZyBzdXBwb3J0IGZvciB0aGlzIHdvcmsgaW4gdGhlIElFVEYNClxw YXIgPz86IHRoZXJlIHNlZW0gdG8gYmUgcmVzZWFyY2ggcXVlc3Rpb25zIGludm9sdmVkIGhlcmUs IGlzIHRoZSBvcmFjbGUgdGhlIHJpZ2h0IG1vZGVsL3dheSBmb3Igc29sdmluZyB0aGlzIHByb2Js ZW0/DQpccGFyIH19 ------_=_NextPart_001_01C8F657.AEE7C52F 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 ------_=_NextPart_001_01C8F657.AEE7C52F-- From p2pi-bounces@ietf.org Mon Aug 4 10:35: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 8D68C3A6B8F; Mon, 4 Aug 2008 10:35: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 9EB463A6B8F for ; Mon, 4 Aug 2008 10:35:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.187 X-Spam-Level: X-Spam-Status: No, score=0.187 tagged_above=-999 required=5 tests=[AWL=0.650, 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 QTAXBjo39S1l for ; Mon, 4 Aug 2008 10:35:15 -0700 (PDT) Received: from paoakoavas09.cable.comcast.com (paoakoavas09.cable.comcast.com [208.17.35.58]) by core3.amsl.com (Postfix) with ESMTP id F2E803A6A39 for ; Mon, 4 Aug 2008 10:35:13 -0700 (PDT) Received: from ([10.52.116.30]) by paoakoavas09.cable.comcast.com with ESMTP id KP-NTF18.58563183; Mon, 04 Aug 2008 13:35:12 -0400 Received: from PACDCEXCMB04.cable.comcast.com ([24.40.15.86]) by PAOAKEXCSMTP01.cable.comcast.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 4 Aug 2008 13:35:12 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 4 Aug 2008 13:35:11 -0400 Message-ID: <45AEC6EF95942140888406588E1A6602045CC1B1@PACDCEXCMB04.cable.comcast.com> In-Reply-To: <20080804154911.GB19747@verdi> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [p2pi] Rock, meet Hard Place Thread-Index: Acj2Sb6KCScBfu0kQKa1/J84E4F8igADkzrA References: <20080731143742.GM10916@cisco.com> <20080804154911.GB19747@verdi> From: "Livingood, Jason" To: "John Leslie" , X-OriginalArrivalTime: 04 Aug 2008 17:35:12.0651 (UTC) FILETIME=[72F89DB0:01C8F658] Subject: Re: [p2pi] Rock, meet Hard Place X-BeenThere: p2pi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: P2P Infrastructure Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: p2pi-bounces@ietf.org Errors-To: p2pi-bounces@ietf.org I'm not a lawyer, and this is in no way, shape or form an official statement by Comcast... Just my individual / personal two cents. Check out http://www.comcast.net/networkmanagement/ as this contains some relevant information... Needless to say, our team is hard at work on the new, protocol-agnostic network management technique. Jason > -----Original Message----- > From: p2pi-bounces@ietf.org [mailto:p2pi-bounces@ietf.org] On > Behalf Of John Leslie > Sent: Monday, August 04, 2008 11:49 AM > To: p2pi@ietf.org > Subject: [p2pi] Rock, meet Hard Place > > > It would appear Comcast is under a deadline: > > http://hraunfoss.fcc.gov/edocs_public/attachmatch/DOC-284286A1.pdf > ] > ] Under the plan, within 30 days of release of the OrderComcast must: > ] - Disclose the details of its discriminatory network management > ] practices to the Commission > ] - Submit a compliance plan describing how it intends to stop these > ] discriminatory management practices by the end of the year > ] - Disclose to customers and the Commission the network management > ] practices that will replace current practices > > -- > John Leslie > _______________________________________________ > p2pi mailing list > p2pi@ietf.org > https://www.ietf.org/mailman/listinfo/p2pi > _______________________________________________ p2pi mailing list p2pi@ietf.org https://www.ietf.org/mailman/listinfo/p2pi From p2pi-bounces@ietf.org Mon Aug 4 12:40: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 05C013A6A05; Mon, 4 Aug 2008 12:40: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 8AAFE3A6A09 for ; Mon, 4 Aug 2008 12:40:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.024 X-Spam-Level: X-Spam-Status: No, score=0.024 tagged_above=-999 required=5 tests=[AWL=0.488, 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 9O-+MSmxMO3F for ; Mon, 4 Aug 2008 12:40:30 -0700 (PDT) Received: from paoakoavas09.cable.comcast.com (paoakoavas09.cable.comcast.com [208.17.35.58]) by core3.amsl.com (Postfix) with ESMTP id 736613A6A05 for ; Mon, 4 Aug 2008 12:40:30 -0700 (PDT) Received: from ([10.195.246.152]) by paoakoavas09.cable.comcast.com with ESMTP id KP-NTF18.58573589; Mon, 04 Aug 2008 15:40:27 -0400 Received: from PACDCEXCMB04.cable.comcast.com ([24.40.15.86]) by NJMDCEXCRLY01.cable.comcast.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 4 Aug 2008 15:40:27 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 4 Aug 2008 15:40:27 -0400 Message-ID: <45AEC6EF95942140888406588E1A6602045CC1BF@PACDCEXCMB04.cable.comcast.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [p2pi] ALTO service privacy, performance, and architecture Thread-Index: Acj1I0MdkHvVtL0kQgaIwo6wCoUKAwBQzKTA References: <200808022240.23300.richard.alimi@yale.edu><2549C209-67E8-4363-998F-F82807F916CE@shlang.com><3054D171-EBE8-44FA-BEA0-37A06EE7DD08@shlang.com> From: "Livingood, Jason" To: "Y. R. Yang" , "Stanislav Shalunov" X-OriginalArrivalTime: 04 Aug 2008 19:40:27.0961 (UTC) FILETIME=[F271EA90:01C8F669] Cc: p2pi@ietf.org Subject: Re: [p2pi] ALTO service privacy, performance, and architecture X-BeenThere: p2pi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: P2P Infrastructure Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: 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 was referring to ISP guidance to improve not only its > network expense but also application performance. As you > pointed out, faster ISPs benefits by guiding for localizaing, > and slower ISPs may need to balance between transit costs and > application performance (by pointing to outside). This is the > incentive issue I was referring to. Believe or not, some ISPs > do care a lot about giving guidance to improve application as > well, as we see in the test :-) This is certainly true... Jason _______________________________________________ p2pi mailing list p2pi@ietf.org https://www.ietf.org/mailman/listinfo/p2pi From p2pi-bounces@ietf.org Mon Aug 4 12:40: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 316103A6A49; Mon, 4 Aug 2008 12:40: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 24C9A3A6A05 for ; Mon, 4 Aug 2008 12:40:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.03 X-Spam-Level: X-Spam-Status: No, score=-0.03 tagged_above=-999 required=5 tests=[AWL=0.433, 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 VLgF324FyyrD for ; Mon, 4 Aug 2008 12:40:31 -0700 (PDT) Received: from paoakoavas09.cable.comcast.com (paoakoavas09.cable.comcast.com [208.17.35.58]) by core3.amsl.com (Postfix) with ESMTP id 2B5A13A691C for ; Mon, 4 Aug 2008 12:40:31 -0700 (PDT) Received: from ([24.40.15.118]) by paoakoavas09.cable.comcast.com with ESMTP id KP-NTF18.58573591; Mon, 04 Aug 2008 15:40:29 -0400 Received: from PACDCEXCMB04.cable.comcast.com ([24.40.15.86]) by PACDCEXCSMTP04.cable.comcast.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 4 Aug 2008 15:40:29 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 4 Aug 2008 15:40:28 -0400 Message-ID: <45AEC6EF95942140888406588E1A6602045CC1C0@PACDCEXCMB04.cable.comcast.com> In-Reply-To: <5156BEE8-42F5-43A1-89F2-C5C0775A9FD5@shlang.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [p2pi] ALTO service privacy, performance, and architecture Thread-Index: Acj099xRi8JWAnFVRUKF76mhwzJxbQBbFvgg References: <2BC23947-E7E7-4E59-98B2-05E79AE8BA78@shlang.com><4894CF1C.2030904@cs.yale.edu> <5156BEE8-42F5-43A1-89F2-C5C0775A9FD5@shlang.com> From: "Livingood, Jason" To: "Stanislav Shalunov" , "Y. Richard Yang" X-OriginalArrivalTime: 04 Aug 2008 19:40:29.0510 (UTC) FILETIME=[F35E4660:01C8F669] Cc: p2pi@ietf.org Subject: Re: [p2pi] ALTO service privacy, performance, and architecture X-BeenThere: p2pi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: P2P Infrastructure Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: p2pi-bounces@ietf.org Errors-To: p2pi-bounces@ietf.org > > - Like Laird said in the previous email, we allowing the > addition of > > sources, instead of only destinations, for specifying ISP > preference. > > It's important for privacy reasons that the app should not have to > tell the ISP about every IP address it might consider > connecting to. > WRT asking about sources other than yourself, I'm fine either > way, because the tracker can get the information from the peers. I would agree, and would venture that ISPs would probably not want to know this information either. Jason _______________________________________________ p2pi mailing list p2pi@ietf.org https://www.ietf.org/mailman/listinfo/p2pi From p2pi-bounces@ietf.org Tue Aug 5 23:41:53 2008 Return-Path: X-Original-To: p2pi-archive@ietf.org Delivered-To: ietfarch-p2pi-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B76903A6A01; Tue, 5 Aug 2008 23:41:53 -0700 (PDT) X-Original-To: p2pi@core3.amsl.com Delivered-To: p2pi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8658C3A69C1 for ; Tue, 5 Aug 2008 23:41:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ylIRUnDWDUcp for ; Tue, 5 Aug 2008 23:41:51 -0700 (PDT) Received: from mout.perfora.net (mout.perfora.net [74.208.4.196]) by core3.amsl.com (Postfix) with ESMTP id 81E663A6A82 for ; Tue, 5 Aug 2008 23:41:51 -0700 (PDT) Received: from viceroy (c-24-130-57-189.hsd1.ca.comcast.net [24.130.57.189]) by mrelay.perfora.net (node=mrus1) with ESMTP (Nemesis) id 0MKpCa-1KQciv3V9n-0004Rn; Wed, 06 Aug 2008 02:42:21 -0400 From: "Stas Khirman" To: "'Y. R. Yang'" , "'Stanislav Shalunov'" References: <200808022240.23300.richard.alimi@yale.edu><2549C209-67E8-4363-998F-F82807F916CE@shlang.com> Date: Tue, 5 Aug 2008 23:42:19 -0700 Message-ID: <019d01c8f78f$95c99820$6400a8c0@jnpr.net> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 Thread-Index: Acj1GXXVnc5rMDEaQWKn3LV5ItyQqgCc0f5w In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 X-Provags-ID: V01U2FsdGVkX18oVKM+bX9EXlx8bHkdKZrr/s9wxWHmEQUeSHT TcmzHOCqn+5WJ1WN7xvQObhYi3gIWPygQz+jnhOCZRYZYHmffF D+aJmyNauLy5cU7Nr0ODw== Cc: p2pi@ietf.org Subject: Re: [p2pi] ALTO service privacy, performance, and architecture X-BeenThere: p2pi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: P2P Infrastructure Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: p2pi-bounces@ietf.org Errors-To: p2pi-bounces@ietf.org > > I'm somewhat skeptical of possibility of great improvements in average > > download speeds. Such possibility would imply that there are vast > amount of > > upload capacity that sit unused in a regular unwashed swarm. While > there can > > be substantial local improvements to be made every now and then, the > system > > clearly gives very high average uplink use fraction when comprised of > decent > > clients. Given how thin the uplink is, it's not too hard to use it all > > regardless of RTT, particularly with several active connections. > > I do not know if I can release the results from the current experiment we > are running. So I cannot give exact numbers. We do see improvement on > download speed averaged across all ISPs. The improvement for some > participating ISPs can be much larger than the global average, supporting > your aforementioned that there can be substantial local improvement. The > implication on ISP incentive will be an interesting issue. The key, as you > pointed out, is to "download go as fast." I think this is more likely to > be achievable. > [Stas Khirman] I believe that both of you are probably correct - accordingly to P4P test descriptions I hear, it performed in relatively small files. For those files, when download time is under 15-20 min, detection of fast connections is critical for average download speed. As shown in number of papers (I can dig for references if needed) for large file downloads (at least 1-2h total download time), initial peer selection is less critical, as peers will find (eventually) speedy connections (it depends not only on the local congestion, but, for example, on corresponding peer availability). In my personal testing on localization, download speed differs only in the first 10-15 minutes of download (my test wasn't academic, just run for few "piratebay"-type torrents using a proxy tracker that returns peers from one large US DSL provider) My guess is that ALTO "advise" will give significant benefits for end-users for - P2P streaming where bootstrap is critical - downloads for 100Mb and under _______________________________________________ p2pi mailing list p2pi@ietf.org https://www.ietf.org/mailman/listinfo/p2pi From p2pi-bounces@ietf.org Tue Aug 5 23:42: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 014323A6A5E; Tue, 5 Aug 2008 23:42: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 D49D03A6ADF for ; Tue, 5 Aug 2008 23:42:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gko+ZH3ZbuOI for ; Tue, 5 Aug 2008 23:42:09 -0700 (PDT) Received: from mout.perfora.net (mout.perfora.net [74.208.4.194]) by core3.amsl.com (Postfix) with ESMTP id 06B7D3A67B4 for ; Tue, 5 Aug 2008 23:42:09 -0700 (PDT) Received: from viceroy (c-24-130-57-189.hsd1.ca.comcast.net [24.130.57.189]) by mrelay.perfora.net (node=mrus1) with ESMTP (Nemesis) id 0MKpCa-1KQciz3t1B-0004Rn; Wed, 06 Aug 2008 02:42:25 -0400 From: "Stas Khirman" To: "'Stanislav Shalunov'" , "'Satish Raghunath'" References: <2378673b0808022115h49ee3aedjb7f460122fbb4674@mail.gmail.com> <98610365-2F83-4F8D-A812-F8447ADB0107@shlang.com> Date: Tue, 5 Aug 2008 23:42:19 -0700 Message-ID: <019e01c8f78f$9818df50$6400a8c0@jnpr.net> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 Thread-Index: Acj1IKlomFY/S7GcQz+ox/hYd+b36ACbH4yA In-Reply-To: <98610365-2F83-4F8D-A812-F8447ADB0107@shlang.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 X-Provags-ID: V01U2FsdGVkX18ioqbjuf5pHid8w7Eiq8Zd9yHuQgdK98ABZc1 1SM6pQf6L6zZFeRcp5F9IvHMeAcGykfsMnoipxyqkLwYmDlPVe 0aY3ykOycYXgwoOUG9gWg== Cc: p2pi@ietf.org Subject: Re: [p2pi] ALTO service privacy, performance, and architecture X-BeenThere: p2pi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: P2P Infrastructure Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: 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 > Stanislav Shalunov > On Aug 2, 2008, at 9:15 PM, Satish Raghunath wrote: > > If any peer is able to discover most of the participants of a > > particular swarm, would you still consider it to be a privacy issue to > > send a list of IP addresses/prefixes to the Oracle? > > Yes. The ISP does not have this information currently. It could, in > principle, play Media Defender and try to get it. But it doesn't, > because there is no incentive to do this. The log files of a sorting > oracle would become subpoena fodder. [Stas Khirman] Not so sure - if oracle has no information about specific content associated with given ALTO request, its log file contains no evidence of legal/illegal content download. From evidence perspective, oracle log is less sensitive than NetFlow information that any ISP may collect today (for traffic planning purpose for example). _______________________________________________ p2pi mailing list p2pi@ietf.org https://www.ietf.org/mailman/listinfo/p2pi From p2pi-bounces@ietf.org Wed Aug 6 03:57: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 AD6DE3A6BCF; Wed, 6 Aug 2008 03:57: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 B43693A6BCF for ; Wed, 6 Aug 2008 03:57:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.507 X-Spam-Level: X-Spam-Status: No, score=-6.507 tagged_above=-999 required=5 tests=[AWL=0.092, 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 aKHG1DHdxj2S for ; Wed, 6 Aug 2008 03:57:13 -0700 (PDT) Received: from mgw-mx03.nokia.com (smtp.nokia.com [192.100.122.230]) by core3.amsl.com (Postfix) with ESMTP id AE8723A68DB for ; Wed, 6 Aug 2008 03:57:12 -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 m76Av1nU019286; Wed, 6 Aug 2008 13:57:31 +0300 Received: from vaebh103.NOE.Nokia.com ([10.160.244.24]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 6 Aug 2008 13:57:27 +0300 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by vaebh103.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 6 Aug 2008 13:57:26 +0300 Received: from [192.168.1.116] ([10.241.184.208]) by esebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Wed, 6 Aug 2008 13:57:25 +0300 Message-Id: From: Lars Eggert To: ext Richard Alimi In-Reply-To: <200808022010.14891.richard.alimi@yale.edu> Mime-Version: 1.0 (Apple Message framework v926) Date: Wed, 6 Aug 2008 13:57:20 +0300 References: <2BC23947-E7E7-4E59-98B2-05E79AE8BA78@shlang.com> <200808021734.54855.rich@velvetsea.net> <76E4BF6A-7C26-466A-BB58-19D04D6FF6EF@shlang.com> <200808022010.14891.richard.alimi@yale.edu> X-Mailer: Apple Mail (2.926) X-OriginalArrivalTime: 06 Aug 2008 10:57:26.0122 (UTC) FILETIME=[363CCCA0:01C8F7B3] X-Nokia-AV: Clean Cc: p2pi@ietf.org Subject: Re: [p2pi] ALTO service privacy, performance, and architecture X-BeenThere: p2pi@ietf.org 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-8-3, at 3:10, ext Richard Alimi wrote: > The query in the P4P protocol that I'm referring to is for a client > to obtain > its PID (a la DHCP). (...) > ISPs with many subscribers may need this to be UDP. I'm not convinced that the flow- and congestion-control mechanism required for a UDP-based protocol would be lighter-weight than simply using TCP. Lars _______________________________________________ p2pi mailing list p2pi@ietf.org https://www.ietf.org/mailman/listinfo/p2pi From p2pi-bounces@ietf.org Wed Aug 6 05:30: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 CACD53A6807; Wed, 6 Aug 2008 05:30: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 9501A3A6807 for ; Wed, 6 Aug 2008 05:30: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 0qlnWwiqacoK for ; Wed, 6 Aug 2008 05:30:16 -0700 (PDT) Received: from QMTA06.emeryville.ca.mail.comcast.net (qmta06.emeryville.ca.mail.comcast.net [76.96.30.56]) by core3.amsl.com (Postfix) with ESMTP id E0BD93A6780 for ; Wed, 6 Aug 2008 05:30:16 -0700 (PDT) Received: from OMTA08.emeryville.ca.mail.comcast.net ([76.96.30.12]) by QMTA06.emeryville.ca.mail.comcast.net with comcast id z0Az1Z00V0FhH24A60VxUS; Wed, 06 Aug 2008 12:29:57 +0000 Received: from poweredge.velvetsea.net ([76.182.22.132]) by OMTA08.emeryville.ca.mail.comcast.net with comcast id z0Vj1Z00K2qze2s8U0Vm6v; Wed, 06 Aug 2008 12:29:55 +0000 X-Authority-Analysis: v=1.0 c=1 a=HQ6x2VH6PSwA:10 a=Mr5i1LQ58koA:10 a=_V4z3Kl1jQiismrZFKsA:9 a=9JDlmYChpDq3J40E7oYA:7 a=gRPWO_XoPtVrrPBqQeTrA6UOI-8A:4 a=LY0hPdMaydYA:10 Received: from [192.168.1.128] (cpe-076-182-022-132.nc.res.rr.com [76.182.22.132]) by poweredge.velvetsea.net (Postfix) with ESMTP id 5B12F424001; Wed, 6 Aug 2008 08:29:43 -0400 (EDT) From: Richard Alimi To: Lars Eggert Date: Wed, 6 Aug 2008 08:31:38 -0400 User-Agent: KMail/1.9.9 References: <2BC23947-E7E7-4E59-98B2-05E79AE8BA78@shlang.com> <200808022010.14891.richard.alimi@yale.edu> In-Reply-To: MIME-Version: 1.0 Content-Disposition: inline Message-Id: <200808060831.38462.richard.alimi@yale.edu> Cc: p2pi@ietf.org Subject: Re: [p2pi] ALTO service privacy, performance, and architecture X-BeenThere: p2pi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: P2P Infrastructure Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: 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 Wednesday 06 August 2008 6:57:20 am Lars Eggert wrote: > On 2008-8-3, at 3:10, ext Richard Alimi wrote: > > The query in the P4P protocol that I'm referring to is for a client > > to obtain > > its PID (a la DHCP). > > (...) > > > ISPs with many subscribers may need this to be UDP. > > I'm not convinced that the flow- and congestion-control mechanism > required for a UDP-based protocol would be lighter-weight than simply > using TCP. That is a good consideration. In this case, both the request and reply are small (1 packet each), and the query only needs to be done once (at application startup). If a response is not received, it can be retried periodically. You're right that for more queries whose requests/responses are larger or need to be done much more frequently UDP may not be worth it. -- Richard Alimi Department of Computer Science Yale University _______________________________________________ p2pi mailing list p2pi@ietf.org https://www.ietf.org/mailman/listinfo/p2pi From p2pi-bounces@ietf.org Wed Aug 6 06:37:00 2008 Return-Path: X-Original-To: p2pi-archive@ietf.org Delivered-To: ietfarch-p2pi-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BE9D628C33F; Wed, 6 Aug 2008 06:37:00 -0700 (PDT) X-Original-To: p2pi@core3.amsl.com Delivered-To: p2pi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9B19428C33F for ; Wed, 6 Aug 2008 06:36:59 -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 VDlc3E-Itil7 for ; Wed, 6 Aug 2008 06:36:58 -0700 (PDT) Received: from mgw-mx09.nokia.com (smtp.nokia.com [192.100.105.134]) by core3.amsl.com (Postfix) with ESMTP id CD05C28C286 for ; Wed, 6 Aug 2008 06:36:58 -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 m76DaTMk007666; Wed, 6 Aug 2008 08:36:55 -0500 Received: from vaebh102.NOE.Nokia.com ([10.160.244.23]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 6 Aug 2008 16:36:16 +0300 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by vaebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 6 Aug 2008 16:36:15 +0300 Received: from [192.168.1.116] ([10.241.184.208]) by esebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Wed, 6 Aug 2008 16:36:15 +0300 Message-Id: From: Lars Eggert To: "ext Richard Alimi" In-Reply-To: <200808060831.38462.richard.alimi@yale.edu> Mime-Version: 1.0 (Apple Message framework v926) Date: Wed, 6 Aug 2008 16:35:46 +0300 References: <2BC23947-E7E7-4E59-98B2-05E79AE8BA78@shlang.com> <200808022010.14891.richard.alimi@yale.edu> <200808060831.38462.richard.alimi@yale.edu> X-Mailer: Apple Mail (2.926) X-OriginalArrivalTime: 06 Aug 2008 13:36:15.0469 (UTC) FILETIME=[662BC1D0:01C8F7C9] X-Nokia-AV: Clean Cc: p2pi@ietf.org Subject: Re: [p2pi] ALTO service privacy, performance, and architecture X-BeenThere: p2pi@ietf.org 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-8-6, at 15:31, ext Richard Alimi wrote: >> I'm not convinced that the flow- and congestion-control mechanism >> required for a UDP-based protocol would be lighter-weight than simply >> using TCP. > > That is a good consideration. In this case, both the request and > reply are > small (1 packet each), and the query only needs to be done once (at > application startup). If a response is not received, it can be > retried > periodically. I don't think we know enough about the types of queries we're talking about to be sure they request and esp. the response will fit in a single packet, or exactly when and how often transactions would take place. Lars _______________________________________________ p2pi mailing list p2pi@ietf.org https://www.ietf.org/mailman/listinfo/p2pi From p2pi-bounces@ietf.org Wed Aug 6 07:12: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 B54533A6A38; Wed, 6 Aug 2008 07:12: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 CC1C53A6C4B for ; Wed, 6 Aug 2008 07:12:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iituq151JT9E for ; Wed, 6 Aug 2008 07:12:29 -0700 (PDT) Received: from QMTA05.emeryville.ca.mail.comcast.net (qmta05.emeryville.ca.mail.comcast.net [76.96.30.48]) by core3.amsl.com (Postfix) with ESMTP id E1F473A63D3 for ; Wed, 6 Aug 2008 07:12:29 -0700 (PDT) Received: from OMTA13.emeryville.ca.mail.comcast.net ([76.96.30.52]) by QMTA05.emeryville.ca.mail.comcast.net with comcast id z25N1Z01517UAYkA52Cq3e; Wed, 06 Aug 2008 14:12:50 +0000 Received: from poweredge.velvetsea.net ([76.182.22.132]) by OMTA13.emeryville.ca.mail.comcast.net with comcast id z2Ca1Z00R2qze2s8Z2Ceuy; Wed, 06 Aug 2008 14:12:47 +0000 X-Authority-Analysis: v=1.0 c=1 a=HQ6x2VH6PSwA:10 a=Mr5i1LQ58koA:10 a=UkFocQXyqQfufIHlRAQA:9 a=uosxtaPyAB4r44HV-3w48TzHXaAA:4 a=LY0hPdMaydYA:10 Received: from ralimi-linux-009027138252.raleigh.ibm.com (bi01p1.nc.us.ibm.com [129.33.49.251]) by poweredge.velvetsea.net (Postfix) with ESMTP id 18837424001; Wed, 6 Aug 2008 10:12:34 -0400 (EDT) From: Richard Alimi To: Lars Eggert Date: Wed, 6 Aug 2008 10:14:28 -0400 User-Agent: KMail/1.9.9 References: <2BC23947-E7E7-4E59-98B2-05E79AE8BA78@shlang.com> <200808060831.38462.richard.alimi@yale.edu> In-Reply-To: MIME-Version: 1.0 Content-Disposition: inline Message-Id: <200808061014.28283.richard.alimi@yale.edu> Cc: p2pi@ietf.org Subject: Re: [p2pi] ALTO service privacy, performance, and architecture X-BeenThere: p2pi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: P2P Infrastructure Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: 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 Wednesday 06 August 2008 9:35:46 am Lars Eggert wrote: > On 2008-8-6, at 15:31, ext Richard Alimi wrote: > >> I'm not convinced that the flow- and congestion-control mechanism > >> required for a UDP-based protocol would be lighter-weight than simply > >> using TCP. > > > > That is a good consideration. In this case, both the request and > > reply are > > small (1 packet each), and the query only needs to be done once (at > > application startup). If a response is not received, it can be > > retried > > periodically. > > I don't think we know enough about the types of queries we're talking > about to be sure they request and esp. the response will fit in a > single packet, or exactly when and how often transactions would take > place. Right - this was in reference to a specific query in the P4P protocol we're working on, but the details of that aren't necessarily directly relevant to ALTO at this stage :) The overall point was that some queries are better as UDP, and some are better as TCP. -- Richard Alimi Department of Computer Science Yale University _______________________________________________ p2pi mailing list p2pi@ietf.org https://www.ietf.org/mailman/listinfo/p2pi From p2pi-bounces@ietf.org Wed Aug 6 07:29: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 621F43A6D5C; Wed, 6 Aug 2008 07:29: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 2AB7728C23A for ; Wed, 6 Aug 2008 07:29:46 -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 mNgY-PctHmT3 for ; Wed, 6 Aug 2008 07:29:45 -0700 (PDT) Received: from kiwi.cs.ucla.edu (Kiwi.CS.UCLA.EDU [131.179.128.19]) by core3.amsl.com (Postfix) with ESMTP id 6D08228C0FC for ; Wed, 6 Aug 2008 07:29:45 -0700 (PDT) Received: from Cs-32-143.CS.UCLA.EDU (Cs-32-143.CS.UCLA.EDU [131.179.32.143]) by kiwi.cs.ucla.edu (8.13.8+Sun/8.13.8/UCLACS-6.0) with ESMTP id m76EUIFX012331; Wed, 6 Aug 2008 07:30:18 -0700 (PDT) Message-Id: <48E73402-4D74-4892-86EF-0C1486371546@cs.ucla.edu> From: Lixia Zhang To: Lars Eggert In-Reply-To: Mime-Version: 1.0 (Apple Message framework v926) Date: Wed, 6 Aug 2008 07:30:18 -0700 References: <2BC23947-E7E7-4E59-98B2-05E79AE8BA78@shlang.com> <200808022010.14891.richard.alimi@yale.edu> <200808060831.38462.richard.alimi@yale.edu> X-Mailer: Apple Mail (2.926) Cc: p2pi@ietf.org Subject: Re: [p2pi] ALTO service privacy, performance, and architecture X-BeenThere: p2pi@ietf.org 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 Aug 6, 2008, at 6:35 AM, Lars Eggert wrote: > On 2008-8-6, at 15:31, ext Richard Alimi wrote: >>> I'm not convinced that the flow- and congestion-control mechanism >>> required for a UDP-based protocol would be lighter-weight than >>> simply >>> using TCP. step up a level: it seems there is a multi-dimension consideration space. light-weight may be one dimension. other dimensions; - head-of-line blocking (by TCP, that someone may not like). - any future need for sending mcast pkts? - transaction vs connection - implementation maturity - etc. >> That is a good consideration. In this case, both the request and >> reply are >> small (1 packet each), and the query only needs to be done once (at >> application startup). If a response is not received, it can be >> retried >> periodically. > > I don't think we know enough about the types of queries we're > talking about to be sure they request and esp. the response will fit > in a single packet, or exactly when and how often transactions would > take place. > > Lars conventional wisdom says that in case of uncertainty: slow start. i.e. using what one has now to get ball rolling, while learn more about the the new space (to potentially moving to a new design later). pros: easier start, lower risk cons: possibility of getting stuck in a sub-optimal solution Lixia _______________________________________________ p2pi mailing list p2pi@ietf.org https://www.ietf.org/mailman/listinfo/p2pi From p2pi-bounces@ietf.org Wed Aug 6 07:40: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 C526F3A68B8; Wed, 6 Aug 2008 07:40: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 AA3B23A68B8 for ; Wed, 6 Aug 2008 07:40:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.283 X-Spam-Level: X-Spam-Status: No, score=-2.283 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 IYMS5jB6d1-d for ; Wed, 6 Aug 2008 07:40:53 -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 3E2963A6860 for ; Wed, 6 Aug 2008 07:40:53 -0700 (PDT) Received: by wf-out-1314.google.com with SMTP id 27so2938862wfd.31 for ; Wed, 06 Aug 2008 07:41:26 -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:references; bh=V9bUxRp92Fbd57+QRh9a68o19eWNdBXWLBbwNTpea38=; b=BJR3kqyPMW+MLO1w2hk802rzTYeTduXBWCEdwAu1C1eJnt3QSY8Dp/0WGBS5G1IZj+ 7fy4vp2YdOvuBaPokU/+vrnajS8p6UJJz8hFaQqY7T2K//LpVQbxoMWNMmNjoQWAqIo0 67HbiMmAYMhk7U84D9ZdrxCm3aBzUPsyJiyRM= 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:references; b=pv+7TKFxMDrl1jytlcOiAKcBhzb6tfrQIsWmMmyRhSJMiQravhJFmeHhnR9XZ5Wsxp 1lAs1openXH0fYSMQpcN3IMeymaCxiFOc8V9eHVLH+TvVJ51LMT60EF+o7CFTTMnXNmq XfLFtdH/+7joour/6C9aAylS/gmCrYc9if4AY= Received: by 10.142.180.19 with SMTP id c19mr27690wff.263.1218033686383; Wed, 06 Aug 2008 07:41:26 -0700 (PDT) Received: by 10.142.128.20 with HTTP; Wed, 6 Aug 2008 07:41:26 -0700 (PDT) Message-ID: <2574b1d30808060741x4729329fre1a1862d46fa2680@mail.gmail.com> Date: Wed, 6 Aug 2008 10:41:26 -0400 From: "Ye WANG" To: p2pi@ietf.org In-Reply-To: <019d01c8f78f$95c99820$6400a8c0@jnpr.net> MIME-Version: 1.0 References: <200808022240.23300.richard.alimi@yale.edu> <2549C209-67E8-4363-998F-F82807F916CE@shlang.com> <019d01c8f78f$95c99820$6400a8c0@jnpr.net> Subject: Re: [p2pi] ALTO service privacy, performance, and architecture X-BeenThere: p2pi@ietf.org X-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="===============1271622489==" Sender: p2pi-bounces@ietf.org Errors-To: p2pi-bounces@ietf.org --===============1271622489== Content-Type: multipart/alternative; boundary="----=_Part_22870_4631213.1218033686380" ------=_Part_22870_4631213.1218033686380 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline On Wed, Aug 6, 2008 at 2:42 AM, Stas Khirman wrote: > > > I'm somewhat skeptical of possibility of great improvements in average > > > download speeds. Such possibility would imply that there are vast > > amount of > > > upload capacity that sit unused in a regular unwashed swarm. While > > there can > > > be substantial local improvements to be made every now and then, the > > system > > > clearly gives very high average uplink use fraction when comprised of > > decent > > > clients. Given how thin the uplink is, it's not too hard to use it all > > > regardless of RTT, particularly with several active connections. > > > > I do not know if I can release the results from the current experiment we > > are running. So I cannot give exact numbers. We do see improvement on > > download speed averaged across all ISPs. The improvement for some > > participating ISPs can be much larger than the global average, supporting > > your aforementioned that there can be substantial local improvement. The > > implication on ISP incentive will be an interesting issue. The key, as > you > > pointed out, is to "download go as fast." I think this is more likely to > > be achievable. > > > [Stas Khirman] > I believe that both of you are probably correct - accordingly to P4P test > descriptions I hear, it performed in relatively small files. For those > files, when download time is under 15-20 min, detection of fast connections > is critical for average download speed. > > As shown in number of papers (I can dig for references if needed) for large > file downloads (at least 1-2h total download time), initial peer selection > is less critical, as peers will find (eventually) speedy connections (it > depends not only on the local congestion, but, for example, on > corresponding > peer availability). > [Ye (Yale)] This is an interesting issue. Actually, we were considering using a large file (1GB movie, etc) in the field test to verify this case. I think this can be done in the near future. In addition to file size, do you think the swarm size (number of concurrent downloadings/seedings) also matters? It could take longer time to gossip faster neighbors if there are millions of peers in a swarm. Anyway, most swarms are relatively small. From the results of the field tests, we see larger download rate improvements for larger swarms. Another observation we have is that faster peers could have larger benefits. ALTO advise is more critical to faster peers because users using new access techniques are usually minority and may not be easy to find each other. As a result, although fater peers are potentially able to download 1GB in 30 minutes, the gossip process would introduce 30 minutes overhead. > In my personal testing on localization, download speed differs only in the > first 10-15 minutes of download (my test wasn't academic, just run for few > "piratebay"-type torrents using a proxy tracker that returns peers from one > large US DSL provider) > > My guess is that ALTO "advise" will give significant benefits for end-users > for > - P2P streaming where bootstrap is critical > - downloads for 100Mb and under [Ye (Yale)] We may probably add two items: - downloading in large swarms (e.g., 100,000+ peers) - with faster network access > > > > > > > _______________________________________________ > p2pi mailing list > p2pi@ietf.org > https://www.ietf.org/mailman/listinfo/p2pi > ------=_Part_22870_4631213.1218033686380 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline


On Wed, Aug 6, 2008 at 2:42 AM, Stas Khirman <stas@khirman.com> wrote:
> > I'm somewhat skeptical of possibility of great improvements in average
> > download speeds.  Such possibility would imply that there are vast
> amount of
> > upload capacity that sit unused in a regular unwashed swarm.  While
> there can
> > be substantial local improvements to be made every now and then, the
> system
> > clearly gives very high average uplink use fraction when comprised of
> decent
> > clients.  Given how thin the uplink is, it's not too hard to use it all
> > regardless of RTT, particularly with several active connections.
>
> I do not know if I can release the results from the current experiment we
> are running. So I cannot give exact numbers. We do see improvement on
> download speed averaged across all ISPs. The improvement for some
> participating ISPs can be much larger than the global average, supporting
> your aforementioned that there can be substantial local improvement. The
> implication on ISP incentive will be an interesting issue. The key, as you
> pointed out, is to "download go as fast." I think this is more likely to
> be achievable.
>
[Stas Khirman]
I believe that both of you are probably correct - accordingly to P4P test
descriptions I hear, it performed in relatively small files. For those
files, when download time is under 15-20 min, detection of fast connections
is critical for average download speed. 


As shown in number of papers (I can dig for references if needed) for large
file downloads (at least 1-2h total download time), initial peer selection
is less critical, as peers will find (eventually) speedy connections (it
depends not only on the local congestion, but, for example, on corresponding
peer availability).
[Ye (Yale)]
This is an interesting issue.  Actually, we were considering using a large file (1GB movie, etc) in the field test to verify this case.  I think this can be done in the near future.
In addition to file size, do you think the swarm size (number of concurrent downloadings/seedings) also matters?  It could take longer time to gossip faster neighbors if there are millions of peers in a swarm.  Anyway, most swarms are relatively small.  From the results of the field tests, we see larger download rate improvements for larger swarms.
Another observation we have is that faster peers could have larger benefits.  ALTO advise is more critical to faster peers because users using new access techniques are usually minority and may not be easy to find each other.  As a result, although fater peers are potentially able to download 1GB in 30 minutes, the gossip process would introduce 30 minutes overhead.
In my personal testing on localization, download speed differs only in the
first 10-15 minutes of download (my test wasn't academic, just run for few
"piratebay"-type torrents using a proxy tracker that returns peers from one
large US DSL provider)

My guess is that ALTO "advise" will give significant benefits for end-users
for
- P2P streaming where bootstrap is critical
- downloads for 100Mb and under
[Ye (Yale)]
We may probably add two items:
- downloading in large swarms (e.g., 100,000+ peers)
- with faster network access






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

------=_Part_22870_4631213.1218033686380-- --===============1271622489== 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 --===============1271622489==-- From p2pi-bounces@ietf.org Thu Aug 7 12: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 CCB333A6899; Thu, 7 Aug 2008 12: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 2B6D43A6899 for ; Thu, 7 Aug 2008 12:12:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.88 X-Spam-Level: * X-Spam-Status: No, score=1.88 tagged_above=-999 required=5 tests=[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 hexagtAoDgEl for ; Thu, 7 Aug 2008 12:12:36 -0700 (PDT) Received: from maild.telecomitalia.it (maild.telecomitalia.it [156.54.233.30]) by core3.amsl.com (Postfix) with ESMTP id A4EDE3A6824 for ; Thu, 7 Aug 2008 12:12:31 -0700 (PDT) Received: from ptpxch007ba020.idc.cww.telecomitalia.it ([156.54.240.50]) by maild.telecomitalia.it with Microsoft SMTPSVC(6.0.3790.1830); Thu, 7 Aug 2008 21:11:58 +0200 Received: from grfhub701ba020.griffon.local ([10.188.101.111]) by ptpxch007ba020.idc.cww.telecomitalia.it with Microsoft SMTPSVC(6.0.3790.1830); Thu, 7 Aug 2008 21:11:58 +0200 Received: from [172.16.82.18] (163.162.180.246) by smtp.telecomitalia.it (10.188.101.114) with Microsoft SMTP Server (TLS) id 8.1.278.0; Thu, 7 Aug 2008 21:11:57 +0200 Message-ID: <489B47A0.1050507@telecomitalia.it> Date: Thu, 7 Aug 2008 21:06:08 +0200 From: Enrico Marocco User-Agent: Mozilla-Thunderbird 2.0.0.16 (X11/20080724) MIME-Version: 1.0 To: "p2pi@ietf.org" X-OriginalArrivalTime: 07 Aug 2008 19:11:58.0268 (UTC) FILETIME=[76A0B7C0:01C8F8C1] Cc: Lisa Dusseault Subject: [p2pi] After-BoF charter X-BeenThere: p2pi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: P2P Infrastructure Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0279771090==" Sender: p2pi-bounces@ietf.org Errors-To: p2pi-bounces@ietf.org --===============0279771090== Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms040107040302080807040803" --------------ms040107040302080807040803 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit We have tried to collect all comments received during the meeting, in mailing list and hallway discussions. The new version of the charter, available as always at http://alto.tilab.com/docs/charter.txt, should reflect at least some of them. Please take a look and comment. Feel free to say if you don't like it -- entirely or partially -- and why; or if you like it. And why. Major changes include: + terminology: dropped terms like "the oracle" and "best peer"; + scope: removed cache/TURN/whatever service discovery; + path selection: stressed the importance of routing preferences and peering policies; + forbidden third-party queries; + mentioned IRTF for analysis on more sophisticated metrics. The current version of the charter is also more explicit about what pieces of information will be provided by an ALTO service; I'll start a separate thread specifically for this discussion. -- Ciao, Enrico --------------ms040107040302080807040803 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 hkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wODA4MDcxOTA2MDhaMCMG CSqGSIb3DQEJBDEWBBTIx02YDRTjDJpiuM0ZRqnci0jKljBfBgkqhkiG9w0BCQ8xUjBQMAsG CWCGSAFlAwQBAjAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAw BwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgYUGCSsGAQQBgjcQBDF4MHYwYjELMAkGA1UEBhMC WkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1Ro YXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAhAeTAANDUMJU97n0e1AWxu4MIGH BgsqhkiG9w0BCRACCzF4oHYwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25z dWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJ c3N1aW5nIENBAhAeTAANDUMJU97n0e1AWxu4MA0GCSqGSIb3DQEBAQUABIIBAHnJywgC5+KQ XlCcYcYBzGE8/Li4wDiR2BljiYghne7vmxHWJl2s+/pOCnQ3l4dzSeED55OHOIHLHsd+NHKv 9CweoqpVed6rK35OUWo+oEyVdJO1zIKim9pTXmsaDSRLz1AlyarOi4Zs8Z5IeNqwDMj0Vtts 8zbk4KS8WwhJ0KDGTGqUDBryCOY2gpZlrpSo/1IZxWdOTpYYUQJIxipPnPR54zbtiMCsHqhm r9e7HxWzoCMYPw7bg/oVCXW9XHaFi7A85pnFpbcifVra3r9J5RS4hyGRY6XujvZFY1jAUzGI 5IFEke9mGiPoy9qzeEI1nw3YuJ/4nnv7JWWKjAjABQ4AAAAAAAA= --------------ms040107040302080807040803-- --===============0279771090== 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 --===============0279771090==-- From p2pi-bounces@ietf.org Thu Aug 7 12:20: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 D7B373A6958; Thu, 7 Aug 2008 12:20: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 8E80E3A6958 for ; Thu, 7 Aug 2008 12:20:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.88 X-Spam-Level: * X-Spam-Status: No, score=1.88 tagged_above=-999 required=5 tests=[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 sbk0EAuTEf2g for ; Thu, 7 Aug 2008 12:20:10 -0700 (PDT) Received: from maild.telecomitalia.it (maild.telecomitalia.it [156.54.233.30]) by core3.amsl.com (Postfix) with ESMTP id 472683A6942 for ; Thu, 7 Aug 2008 12:20:10 -0700 (PDT) Received: from ptpxch010ba020.idc.cww.telecomitalia.it ([156.54.240.53]) by maild.telecomitalia.it with Microsoft SMTPSVC(6.0.3790.1830); Thu, 7 Aug 2008 21:20:09 +0200 Received: from grfhub701ba020.griffon.local ([10.188.101.111]) by ptpxch010ba020.idc.cww.telecomitalia.it with Microsoft SMTPSVC(6.0.3790.1830); Thu, 7 Aug 2008 21:20:09 +0200 Received: from [172.16.82.18] (163.162.180.246) by smtp.telecomitalia.it (10.188.101.114) with Microsoft SMTP Server (TLS) id 8.1.278.0; Thu, 7 Aug 2008 21:20:08 +0200 Message-ID: <489B498B.4040804@telecomitalia.it> Date: Thu, 7 Aug 2008 21:14:19 +0200 From: Enrico Marocco User-Agent: Mozilla-Thunderbird 2.0.0.16 (X11/20080724) MIME-Version: 1.0 To: "p2pi@ietf.org" X-OriginalArrivalTime: 07 Aug 2008 19:20:09.0252 (UTC) FILETIME=[9B46EE40:01C8F8C2] Cc: Lisa Dusseault Subject: [p2pi] Information in an ALTO protocol X-BeenThere: p2pi@ietf.org X-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="===============2011568660==" Sender: p2pi-bounces@ietf.org Errors-To: p2pi-bounces@ietf.org --===============2011568660== Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms010502000105090005080707" --------------ms010502000105090005080707 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit As some people suggested, it may be useful to try to understand what kind of information will be provided by an ALTO service. Current version of the charter lists four pieces of information: + routing preferences and priority values. The network operator is usually the only entity in possession of such information, but it is in its interests to share at least part of it with applications, in order to reduce traffic on critical links. On the other hand, if following such preferences leads to better-than-random choices, it is also in applications' interest to follow them; + AS numbers and approximate geographic locations. Such information is today (partially) available and, in fact, is in some cases already used for peer selection. However, since there is no standard way to obtain it, it is not easy for applications to switch from an information provider to another. The charter does not preclude any other kind of information entirely, but it sets the bar pretty high, requiring that: When the WG considers standardizing schemas, measures or other information that the ALTO service could provide, the following criteria are important to ensure real feasibility. - Can an ALTO service technically provide that information? - Is the ALTO service willing to obtain and divulge that information? - Is it information that some client will find useful? - Can that client get that information without excessive privacy concerns (e.g. by sending large lists of peers)? - Is it information that clients cannot find easily some other way? Thoughts? -- Ciao, Enrico --------------ms010502000105090005080707 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 hkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wODA4MDcxOTE0MTlaMCMG CSqGSIb3DQEJBDEWBBRpnFEaxLy3pBLEgb++5nNdwE6zwzBfBgkqhkiG9w0BCQ8xUjBQMAsG CWCGSAFlAwQBAjAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAw BwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgYUGCSsGAQQBgjcQBDF4MHYwYjELMAkGA1UEBhMC WkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1Ro YXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAhAeTAANDUMJU97n0e1AWxu4MIGH BgsqhkiG9w0BCRACCzF4oHYwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25z dWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJ c3N1aW5nIENBAhAeTAANDUMJU97n0e1AWxu4MA0GCSqGSIb3DQEBAQUABIIBAGsyVIxshnkU 31QS+XOisFLCXsk3us3Y2WtALpBeOdVdclndrPEEAo48qX5THUg1ffjN/SN3tutRSVU+pj0j o/3JgrgYtFEtmALZsdvNPEdyXjceBb5bqGad/fVsD+c7ayIw/2LyL3M4p9Wi3CknEaA/4PEu fVSFqtHA9qqVkZXMyP1SGSoYkZurwxrL7ldqukvqTnHjWVwkaIpCKn8aXDfspe6eke3ScNiD 6cXzqgiYyT6H/a6mxytXJDKHeXBUUaEKsfiBcRfzmcDy7ORRAumF0+MtzW2v/xf8oePGVTXM +0YfYLAressUKRUiUAQ4e8k8sHQQTegV8bV/MGJnqh0AAAAAAAA= --------------ms010502000105090005080707-- --===============2011568660== 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 --===============2011568660==-- From p2pi-bounces@ietf.org Thu Aug 7 21:17: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 5BD8B3A6AF7; Thu, 7 Aug 2008 21:17: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 A68ED3A6A86 for ; Thu, 7 Aug 2008 21:17:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.352 X-Spam-Level: * X-Spam-Status: No, score=1.352 tagged_above=-999 required=5 tests=[BAYES_05=-1.11, HTML_IMAGE_ONLY_12=2.46, HTML_MESSAGE=0.001, HTML_SHORT_LINK_IMG_1=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 P61YnXqsKL5H for ; Thu, 7 Aug 2008 21:17:26 -0700 (PDT) Received: from wf-out-1314.google.com (wf-out-1314.google.com [209.85.200.175]) by core3.amsl.com (Postfix) with ESMTP id AE0B83A68C0 for ; Thu, 7 Aug 2008 21:17:25 -0700 (PDT) Received: by wf-out-1314.google.com with SMTP id 27so688124wfd.31 for ; Thu, 07 Aug 2008 21:17:25 -0700 (PDT) Received: by 10.142.225.11 with SMTP id x11mr553481wfg.101.1218169044951; Thu, 07 Aug 2008 21:17:24 -0700 (PDT) Received: from ?192.168.1.103? ( [67.188.243.194]) by mx.google.com with ESMTPS id 22sm1103645wfi.14.2008.08.07.21.17.23 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 07 Aug 2008 21:17:24 -0700 (PDT) Message-Id: <2688DAA4-2F9C-489D-B0CE-87A9560837F0@shlang.com> From: Stanislav Shalunov To: TSV Area , p2pi@ietf.org Mime-Version: 1.0 (Apple Message framework v926) Date: Thu, 7 Aug 2008 21:17:22 -0700 X-Mailer: Apple Mail (2.926) Cc: Gorry Fairhurst Subject: [p2pi] Subscribe to the new TANA mailing list X-BeenThere: p2pi@ietf.org X-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="===============1667027963==" Sender: p2pi-bounces@ietf.org Errors-To: p2pi-bounces@ietf.org --===============1667027963== Content-Type: multipart/alternative; boundary=Apple-Mail-7--656325520 --Apple-Mail-7--656325520 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit If you attended the TANA BoF or are interested in the TANA work (the TANA problem is described in draft-shalunov-tana-problem- statement-01), please subscribe to the newly created TANA mailing list: https://www.ietf.org/mailman/listinfo/tana Future discussion of TANA-specific topics is best conducted on the TANA mailing list. If a working group is formed, we expect this mailing list to become the WG list. Thank you, -- Stas -- Stanislav Shalunov --Apple-Mail-7--656325520 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit
If you attended the TANA BoF or are interested in the TANA work (the TANA problem is described in draft-shalunov-tana-problem-statement-01), please subscribe to the newly created TANA mailing list:


Future discussion of TANA-specific topics is best conducted on the TANA mailing list.  If a working group is formed, we expect this mailing list to become the WG list.

Thank you,  -- Stas --Apple-Mail-7--656325520-- --===============1667027963== 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 --===============1667027963==-- From p2pi-bounces@ietf.org Thu Aug 7 21:24: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 30E633A6A83; Thu, 7 Aug 2008 21:24: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 6E10B3A69FE for ; Thu, 7 Aug 2008 21:24:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.623 X-Spam-Level: X-Spam-Status: No, score=-0.623 tagged_above=-999 required=5 tests=[AWL=1.976, 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 RA1AatFirHKc for ; Thu, 7 Aug 2008 21:24:16 -0700 (PDT) Received: from wf-out-1314.google.com (wf-out-1314.google.com [209.85.200.169]) by core3.amsl.com (Postfix) with ESMTP id 7BF8E3A6A83 for ; Thu, 7 Aug 2008 21:24:16 -0700 (PDT) Received: by wf-out-1314.google.com with SMTP id 27so690112wfd.31 for ; Thu, 07 Aug 2008 21:24:16 -0700 (PDT) Received: by 10.142.218.4 with SMTP id q4mr91734wfg.262.1218169456306; Thu, 07 Aug 2008 21:24:16 -0700 (PDT) Received: from ?192.168.1.103? ( [67.188.243.194]) by mx.google.com with ESMTPS id 32sm1110967wfa.8.2008.08.07.21.24.14 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 07 Aug 2008 21:24:14 -0700 (PDT) Message-Id: From: Stanislav Shalunov To: Enrico Marocco In-Reply-To: <489B498B.4040804@telecomitalia.it> Mime-Version: 1.0 (Apple Message framework v926) Date: Thu, 7 Aug 2008 21:24:13 -0700 References: <489B498B.4040804@telecomitalia.it> X-Mailer: Apple Mail (2.926) Cc: Lisa Dusseault , "p2pi@ietf.org" Subject: Re: [p2pi] Information in an ALTO protocol X-BeenThere: p2pi@ietf.org 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 For what it's worth, I think this is the right kind of information to convey. On Aug 7, 2008, at 12:14 PM, Enrico Marocco wrote: > As some people suggested, it may be useful to try to understand what > kind of information will be provided by an ALTO service. > > Current version of the charter lists four pieces of information: > + routing preferences and priority values. The network operator is > usually the only entity in possession of such information, but it is > in its interests to share at least part of it with applications, in > order to reduce traffic on critical links. On the other hand, if > following such preferences leads to better-than-random choices, it is > also in applications' interest to follow them; > + AS numbers and approximate geographic locations. Such information is > today (partially) available and, in fact, is in some cases already > used for peer selection. However, since there is no standard way to > obtain it, it is not easy for applications to switch from an > information provider to another. > > The charter does not preclude any other kind of information entirely, > but it sets the bar pretty high, requiring that: > > When the WG considers standardizing schemas, measures or other > information that the ALTO service could provide, the following > criteria are important to ensure real feasibility. > - Can an ALTO service technically provide that information? > - Is the ALTO service willing to obtain and divulge that information? > - Is it information that some client will find useful? > - Can that client get that information without excessive privacy > concerns (e.g. by sending large lists of peers)? > - Is it information that clients cannot find easily some other way? > > Thoughts? > > -- > Ciao, > Enrico > _______________________________________________ > p2pi mailing list > p2pi@ietf.org > https://www.ietf.org/mailman/listinfo/p2pi -- Stanislav Shalunov _______________________________________________ p2pi mailing list p2pi@ietf.org https://www.ietf.org/mailman/listinfo/p2pi From p2pi-bounces@ietf.org Thu Aug 7 23:56: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 133C03A6C0C; Thu, 7 Aug 2008 23:56: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 5CE1A3A6C76 for ; Thu, 7 Aug 2008 23:56:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.601 X-Spam-Level: X-Spam-Status: No, score=-6.601 tagged_above=-999 required=5 tests=[AWL=-0.002, 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 Y2J6dd1OeT1T for ; Thu, 7 Aug 2008 23:56:33 -0700 (PDT) Received: from mgw-mx09.nokia.com (smtp.nokia.com [192.100.105.134]) by core3.amsl.com (Postfix) with ESMTP id 29A8A3A6C19 for ; Thu, 7 Aug 2008 23:56:33 -0700 (PDT) Received: from vaebh105.NOE.Nokia.com (vaebh105.europe.nokia.com [10.160.244.31]) by mgw-mx09.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id m786tcLg020624; Fri, 8 Aug 2008 01:56:05 -0500 Received: from vaebh102.NOE.Nokia.com ([10.160.244.23]) by vaebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 8 Aug 2008 09:56:01 +0300 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by vaebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 8 Aug 2008 09:55:58 +0300 Received: from net-68.nrpn.net ([10.241.184.208]) by esebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Fri, 8 Aug 2008 09:55:57 +0300 Message-Id: From: Lars Eggert To: ext Enrico Marocco In-Reply-To: <489B47A0.1050507@telecomitalia.it> Mime-Version: 1.0 (Apple Message framework v926) Date: Fri, 8 Aug 2008 09:55:44 +0300 References: <489B47A0.1050507@telecomitalia.it> X-Mailer: Apple Mail (2.926) X-OriginalArrivalTime: 08 Aug 2008 06:55:58.0913 (UTC) FILETIME=[D003A310:01C8F923] X-Nokia-AV: Clean Cc: Lisa Dusseault , "p2pi@ietf.org" Subject: Re: [p2pi] After-BoF charter X-BeenThere: p2pi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: P2P Infrastructure Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: p2pi-bounces@ietf.org Errors-To: p2pi-bounces@ietf.org Hi, I believe that the new charter text is a huge step in the right direction - thank you for not being discouraged from continuing to work on this after the BOF. I have a few comments on specific bits of text: > DRAFT CHARTER > $Id: charter.txt 71 2008-08-07 17:15:10Z enrico $ What area are you targeting for the WG? (I assume APP.) > A significant part of the Internet traffic is today generated by > peer-to-peer (P2P) applications used for file sharing, real-time > communications and live media streaming. In contrast to client/server > architectures, P2P applications access resources distributed across > the Internet (e.g. files or media relays) and exchange large amounts > of data in connections that they establish directly with nodes hosting > such resources. > > One of the advantages of P2P systems comes from the fact that the > resources they access are often made available through multiple > instances. Yet, applications have at best incomplete information > about the topology of the network. Empirical measurements of peer > communication performance help a great deal, but this is not always an > option nor does it always arrive at an optimal arrangement of peers in > a reasonable time, thus causing reduced perfomormance and excessive > cross-domain traffic. Optimizing peer selection will improve P2P > performance and lower ISP costs. The first two paragraphs are a bit wordy for an IETF charter. If we can condense this down, good, if not, not really too problematic. > The Working Group will design and specify an Application-Layer Traffic > Optimization (ALTO) service that will provide applications with > information to perform better-than-random peer selection. Hm. There are research results (Peter Key, etc.) that show that random peer selection based on observed performance over time approximates an optimal peer selection, at least for some metrics. It seems like the best ALTO could do is help P2P systems converge on a good set of peers faster (maybe much faster) that performance-based random selection over time would? > The WG will > consider BitTorrent, tracker-less P2P, and other applications, such as > content delivery networks (CDN) and mirror selection. > > The WG will focus on the following items: For each of these items, it's be good to indicate in the charter what kinds of documents (PS, Experimental, Informational, BCP) the WG is expected to produce. > - A requirements document. This document will list requirements for a > peer selection service, identifying, for example, what kind of > information P2P applications will need for optimizing their choices. > > - A request/response protocol for querying the ALTO service to obtain > information useful for peer selection, and a format for requests and > responses. I'd like to suggest that at least the initial protocol should run over TCP. > - A schema for such a protocol to communicate routing preferences to > applications, including IP ranges to prefer and avoid. Your email also talks about AS numbers (as do charter paragraphs below), but the work item above is only about IP ranges and no other work item talks about AS numbers - missing work item? > - In order to query an ALTO service, clients must first know one or > more hosts that might provide useful information. The WG will look > at service discovery mechanisms that are in use or defined elsewhere > (e.g. based on DNS SRV records or DHCP options); in case some of > them could be reused, the WG will produce a document to specify how > they may be adopted for locating such hosts. However, a new, > general-purpose service discovery mechanism is not in scope. > > Other tasks the WG may take on at lower priority than its initial > deliverables are the following: I'd like to suggest that taking on any additional work items other than the ones above require a WG rechartering. > - Defining an API mapping to the request/response protocol. > > - Other schemas, for requesting and communicating other information > from the ALTO service. > > When the WG considers standardizing schemas, measures or other > information that the ALTO service could provide, the following > criteria are important to ensure real feasibility. > > - Can an ALTO service technically provide that information? > > - Is the ALTO service willing to obtain and divulge that information? > > - Is it information that some client will find useful? > > - Can that client get that information without excessive privacy > concerns (e.g. by sending large lists of peers)? > > - Is it information that clients cannot find easily some other way? > > After these criteria are met, the generality of the data will be > considered for prioritizing standardization work, for example how many > operators and how many clients are likely to be able to provide or use > that particular data. > > This WG will focus solely on the interface exposed to applications > (both P2P and client/server) by peer selection services; if, in the > future, the IETF will consider the opportunity to work on protocols > for actually implementing such services (e.g. application-layer > protocols for Internet coordinate systems, routing protocol extensions > for ISP-based solutions), such work will be done in strict > coordination with the appropriate WGs. > > Protocols used for peer selection optimization will carry information > related to the topology and the policies of the querying peer's > network (i.e. queries on behalf of other peers are not allowed). It > is reasonable to expect that applications will use such protocols to > discover Autonomous System (AS) numbers and approximate geographic > location of peers hosting the needed resources, as well as priority > values assigned by the ALTO service, such values having been derived > from particular knowledge the service may be in possession of > (e.g. location of caches and/or network peering policies), and routing > preferences. If the WG will happen to consider additional and more > sophisticated schemas like, for example, some notion of network > distance, in some network coordinate system, such effort will be > coordinated with the proper IRTF research group. In any case, > solutions proposed in this WG will not deal with frequently changing > performance-related information, for example about traffic > congestions; instead, mechanisms addressing transport-related issues > developed in other IETF areas will be referenced whenever appropriate. > > Issues related to the content exchanged in P2P systems are also > excluded from the WG's scope, as is the issue dealing with enforcing > the legality of the content. Lars _______________________________________________ p2pi mailing list p2pi@ietf.org https://www.ietf.org/mailman/listinfo/p2pi From p2pi-bounces@ietf.org Fri Aug 8 09:17: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 9B9133A6C2D; Fri, 8 Aug 2008 09:17: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 E64E23A6C2D for ; Fri, 8 Aug 2008 09:17: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 Z-P7QzT0V4d0 for ; Fri, 8 Aug 2008 09:17:18 -0700 (PDT) Received: from mailhost.jlc.net (mailhost.jlc.net [199.201.159.9]) by core3.amsl.com (Postfix) with ESMTP id E28C63A681C for ; Fri, 8 Aug 2008 09:17:17 -0700 (PDT) Received: by mailhost.jlc.net (Postfix, from userid 104) id D03A633C38; Fri, 8 Aug 2008 12:17:10 -0400 (EDT) Date: Fri, 8 Aug 2008 12:17:10 -0400 From: John Leslie To: Lars Eggert Message-ID: <20080808161710.GA25453@verdi> References: <489B47A0.1050507@telecomitalia.it> Mime-Version: 1.0 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.1i Cc: "p2pi@ietf.org" , Lisa Dusseault Subject: Re: [p2pi] After-BoF charter X-BeenThere: p2pi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: P2P Infrastructure Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: p2pi-bounces@ietf.org Errors-To: p2pi-bounces@ietf.org Basically, I agree with Lars... Some additional notes: Lars Eggert wrote: > [ext Enrico Marocco wrote:] > > The first two paragraphs are a bit wordy for an IETF charter. If we > can condense this down, good, if not, not really too problematic. They're well-written, IMHO: I wouldn't worry about condensing them yet. >> The Working Group will design and specify an Application-Layer Traffic >> Optimization (ALTO) service that will provide applications with >> information to perform better-than-random peer selection. > > Hm. There are research results (Peter Key, etc.) that show that random > peer selection based on observed performance over time approximates an > optimal peer selection, at least for some metrics. It seems like the > best ALTO could do is help P2P systems converge on a good set of peers > faster (maybe much faster) that performance-based random selection > over time would? The speed of convergence to optimal is the critical issue: we want a "better-than-random" initial set of peers to try (and possibly an ordered list to try if they prove unsatisfactory. I think adding the word "inital" would help: " " information to perform better-than-random initial peer selection. >> The WG will focus on the following items: > > For each of these items, it's be good to indicate in the charter what > kinds of documents (PS, Experimental, Informational, BCP) the WG is > expected to produce. > >> - A requirements document. This document will list requirements for a >> peer selection service, identifying, for example, what kind of >> information P2P applications will need for optimizing their choices. >> >> - A request/response protocol for querying the ALTO service to obtain >> information useful for peer selection, and a format for requests and >> responses. > > I'd like to suggest that at least the initial protocol should run over > TCP. I agree. We might benefit from trying peers in the order received, and adding as more are received. >> - A schema for such a protocol to communicate routing preferences to >> applications, including IP ranges to prefer and avoid. > > Your email also talks about AS numbers (as do charter paragraphs > below), but the work item above is only about IP ranges and no other > work item talks about AS numbers - missing work item? In practice, the correlation of ASN to topology is spotty. I'm not sure that ASN will satisfy the "important criteria" to follow. >> Other tasks the WG may take on at lower priority than its initial >> deliverables are the following: > > I'd like to suggest that taking on any additional work items other > than the ones above require a WG rechartering. Leaving these out may be wise. >> - Defining an API mapping to the request/response protocol. >> >> - Other schemas, for requesting and communicating other information >> from the ALTO service. (Note, however, that expandability of an ALTO protocol is important.) >> When the WG considers standardizing schemas, measures or other >> information that the ALTO service could provide, the following >> criteria are important to ensure real feasibility. >> >> - Can an ALTO service technically provide that information? >> >> - Is the ALTO service willing to obtain and divulge that information? >> >> - Is it information that some client will find useful? Good criteria, but I'd suggest uniformity of the indefinite article: - "an" ALTO service technically provide - "an" ALTO service willing to obtain and divulge - "a" client will find useful >> - Can that client get that information without excessive privacy >> concerns (e.g. by sending large lists of peers)? (Clearly there are other obscuring tactics: we don't need to list them.) >> After these criteria are met, the generality of the data will be >> considered for prioritizing standardization work, for example how many >> operators and how many clients are likely to be able to provide or use >> that particular data. We should standardize what we understand now; but we shouldn't expect every ALTO server to implement everything. >> Protocols used for peer selection optimization will carry information >> related to the topology and the policies of the querying peer's >> network (i.e. queries on behalf of other peers are not allowed). We should perhaps be careful about this last prohibition. I'm not sure the obvious mechanism (matching the source IP address of a query) is wise (though I certainly wouldn't prohibit implementations from trying it). There are obvious potential benefits from letting particular trackers read an ISP's policies (by prior arrangement, usually). A blanket prohibition of this seems unnecessary. >> It is reasonable to expect that applications will use such protocols >> to discover Autonomous System (AS) numbers and approximate geographic >> location of peers hosting the needed resources, I don't even _understand_ this. Current trackers _do_ try to find these pieces of information, but IMHO they're suboptimal substitutes for information ISPs could provide. I see no reason to include such text in a charter. >> as well as priority >> values assigned by the ALTO service, such values having been derived >> from particular knowledge the service may be in possession of >> (e.g. location of caches and/or network peering policies), and routing >> preferences. These are more reasonable, but they don't seem necessary in a charter either. >> If the WG will happen to consider additional and more >> sophisticated schemas like, for example, some notion of network >> distance, in some network coordinate system, such effort will be >> coordinated with the proper IRTF research group. Folks would prefer (IMHO) that we don't even mention such work. >> In any case, solutions proposed in this WG will not deal with >> frequently changing performance-related information, for example >> about traffic congestions; Congestion is the whole issue here -- we'd better not rule it out of scope. ISPs will cooperate in this effort if it helps their congestion problems -- and probably won't if it doesn't. That said, we _should_ recognize that the p2p application is in a better position to evaluate instantaneous congestion than any ALTO server: thus asking the ALTO server for congestion level is unwise. But ISPs probably _will_ implement some variety of "penalty box" for customers that "cause" too much congestion; and IMHO we'd be well advised to allow for an ISP's ALTO server to report how close a customer is to the penalty box. (This could change from second to second, in principle.) I don't have any specific proposal -- it just seems unwise to rule this information out of scope. >> instead, mechanisms addressing transport-related issues >> developed in other IETF areas will be referenced whenever appropriate. This text is confusing. Does it really help anything to say this? >> Issues related to the content exchanged in P2P systems are also >> excluded from the WG's scope, as is the issue dealing with enforcing >> the legality of the content. I absolutely agree. -- John Leslie _______________________________________________ p2pi mailing list p2pi@ietf.org https://www.ietf.org/mailman/listinfo/p2pi From p2pi-bounces@ietf.org Fri Aug 8 09:44: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 20CD83A6CB3; Fri, 8 Aug 2008 09:44: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 7D6C03A6A7D for ; Fri, 8 Aug 2008 09:44:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.265 X-Spam-Level: X-Spam-Status: No, score=-10.265 tagged_above=-999 required=5 tests=[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 tqkkN6b1hvAV for ; Fri, 8 Aug 2008 09:44:02 -0700 (PDT) Received: from dkny.pando.com (dkny.pando.com [67.99.55.163]) by core3.amsl.com (Postfix) with ESMTP id 82A0C3A6BD6 for ; Fri, 8 Aug 2008 09:44:02 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by dkny.pando.com (Postfix) with ESMTP id 2A0ECE10B64; Fri, 8 Aug 2008 12:43:58 -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 0cW093NsHlCP; Fri, 8 Aug 2008 12:43:43 -0400 (EDT) Received: from dkny.pando.com (dkny.pando.com [10.10.60.11]) by dkny.pando.com (Postfix) with ESMTP id DBB12E10C91; Fri, 8 Aug 2008 12:43:43 -0400 (EDT) Date: Fri, 8 Aug 2008 12:43:43 -0400 (EDT) From: Laird Popkin To: John Leslie Message-ID: <1317402407.115221218213823874.JavaMail.root@dkny.pando.com> In-Reply-To: <20080808161710.GA25453@verdi> MIME-Version: 1.0 X-Originating-IP: [10.10.20.79] Cc: Lisa Dusseault , p2pi@ietf.org Subject: Re: [p2pi] After-BoF charter X-BeenThere: p2pi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: P2P Infrastructure Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: p2pi-bounces@ietf.org Errors-To: p2pi-bounces@ietf.org Comment below. - Laird Popkin, CTO, Pando Networks mobile: 646/465-0570 ----- Original Message ----- From: "John Leslie" To: "Lars Eggert" Cc: p2pi@ietf.org, "Lisa Dusseault" Sent: Friday, August 8, 2008 12:17:10 PM (GMT-0500) America/New_York Subject: Re: [p2pi] After-BoF charter Basically, I agree with Lars... Some additional notes: Lars Eggert wrote: > [ext Enrico Marocco wrote:] >> In any case, solutions proposed in this WG will not deal with >> frequently changing performance-related information, for example >> about traffic congestions; Congestion is the whole issue here -- we'd better not rule it out of scope. ISPs will cooperate in this effort if it helps their congestion problems -- and probably won't if it doesn't. That said, we _should_ recognize that the p2p application is in a better position to evaluate instantaneous congestion than any ALTO server: thus asking the ALTO server for congestion level is unwise. But ISPs probably _will_ implement some variety of "penalty box" for customers that "cause" too much congestion; and IMHO we'd be well advised to allow for an ISP's ALTO server to report how close a customer is to the penalty box. (This could change from second to second, in principle.) I don't have any specific proposal -- it just seems unwise to rule this information out of scope. [laird] The distinction is (IMO) that the ALTO server makes slow-moving recommendations, while the application can be decisions based on real-time conditions. Congestion as an example is (IMO) causing a little confusion, because it's both a real-time condition (e.g. "is the TCP stream from peer A congested right now?") and an input into slow-moving recommendations (e.g. "the link to ISP X is typically heavily congested during the day, so don't connect peers across that link"). Perhaps it would be better not to provide the congestion example in the write-up? -- 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 Fri Aug 8 10:34: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 642143A6D2E; Fri, 8 Aug 2008 10:34: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 5D8593A6924 for ; Fri, 8 Aug 2008 10:34:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.899 X-Spam-Level: X-Spam-Status: No, score=-5.899 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, SARE_BIZOP=0.7] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DWHXIeSSkXiE for ; Fri, 8 Aug 2008 10:34:53 -0700 (PDT) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by core3.amsl.com (Postfix) with ESMTP id 075573A6D2E for ; Fri, 8 Aug 2008 10:34:51 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.31,328,1215388800"; d="scan'208";a="73633646" Received: from sjc12-sbr-sw3-3f5.cisco.com (HELO imail.cisco.com) ([172.19.96.182]) by sj-iport-2.cisco.com with ESMTP; 08 Aug 2008 17:34:11 +0000 Received: from stealth-10-32-245-156.cisco.com ([10.32.245.156]) by imail.cisco.com (8.12.11/8.12.10) with ESMTP id m78HAY9R022252; Fri, 8 Aug 2008 10:10:34 -0700 Message-Id: <8438AFF1-9606-46F7-8E51-3962775D0F93@cisco.com> From: David R Oran To: Laird Popkin In-Reply-To: <1317402407.115221218213823874.JavaMail.root@dkny.pando.com> Mime-Version: 1.0 (Apple Message framework v928.1) Date: Fri, 8 Aug 2008 13:34:09 -0400 References: <1317402407.115221218213823874.JavaMail.root@dkny.pando.com> X-Mailer: Apple Mail (2.928.1) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=4255; t=1218215435; x=1219079435; c=relaxed/simple; s=oregon; h=To:Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=oran@cisco.com; z=From:=20David=20R=20Oran=20 |Subject:=20Re=3A=20[p2pi]=20After-BoF=20charter |Sender:=20 |To:=20Laird=20Popkin=20; bh=nkkb0YE9J8mOB47DWk6uv4GaJq+k6mH9TKAexkk18hY=; b=jnRa5gARr4yMApDSL5kIwgSYRwZKnF1x5sz6yCL/Gr/ES4bgzn1eYTW4G/ zIDlgCiiwUxJJHuHmWnD7Ej8tjqSCX8HlJREAuZkMID7vJTE6FkTwQt4ABRv isf68UWTQ8; Authentication-Results: imail.cisco.com; header.From=oran@cisco.com; dkim=pass ( sig from cisco.com/oregon verified; ); Cc: Lisa Dusseault , p2pi@ietf.org Subject: Re: [p2pi] After-BoF charter X-BeenThere: p2pi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: P2P Infrastructure Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: p2pi-bounces@ietf.org Errors-To: p2pi-bounces@ietf.org On Aug 8, 2008, at 12:43 PM, Laird Popkin wrote: > Comment below. > > - Laird Popkin, CTO, Pando Networks > mobile: 646/465-0570 > > ----- Original Message ----- > From: "John Leslie" > To: "Lars Eggert" > Cc: p2pi@ietf.org, "Lisa Dusseault" > Sent: Friday, August 8, 2008 12:17:10 PM (GMT-0500) America/New_York > Subject: Re: [p2pi] After-BoF charter > > Basically, I agree with Lars... Some additional notes: > > Lars Eggert wrote: >> [ext Enrico Marocco wrote:] > >>> In any case, solutions proposed in this WG will not deal with >>> frequently changing performance-related information, for example >>> about traffic congestions; > > Congestion is the whole issue here -- we'd better not rule it out of > scope. > > ISPs will cooperate in this effort if it helps their congestion > problems -- and probably won't if it doesn't. > Not necessarily. If they can increase their revenue by selling a tiered service that optimizes P2P completion times that might be the hook irrespective of congestion. It is of course desirable that ISPs cooperate and even lead the charge; on the other hand we need to make ALTO succeed in the absence of direct ISP deployment. Read: business opportunity. > That said, we _should_ recognize that the p2p application is in a > better position to evaluate instantaneous congestion than any ALTO > server: thus asking the ALTO server for congestion level is unwise. > Agree. > But ISPs probably _will_ implement some variety of "penalty box" > for customers that "cause" too much congestion; and IMHO we'd be > well advised to allow for an ISP's ALTO server to report how close > a customer is to the penalty box. (This could change from second to > second, in principle.) > I am quite un-enthusiastic about this idea, because it's not possible for the P2P application (or any individual application) to tell if it's the one causing the creep to the penalty box or if it's the 5-way video conference the customer is doing, or the HD streaming video coming in from from some OTT video service. I am even more unenthusiastic if the idea is that there is a specific penalty box for P2P applications, because that keeps us stuck in the DPI world with the customer and the ISP encouraged to engage in spy-vs- spy tactics. Plus, this doesn't help at all with penalty boxes tied to daily/weekly/ monthly data volume caps. A better way to deal with this is full-disclosure by the ISP and configurable rate shaping in the home router. > I don't have any specific proposal -- it just seems unwise to rule > this information out of scope. > I think it is wise to declare this out of scope. So, we disagree here. > [laird] The distinction is (IMO) that the ALTO server makes slow- > moving recommendations, while the application can be decisions based > on real-time conditions. I think the distinctions are greater and along more dimensions that simply the time-averaging interval. Examples: the ALTO server sees a different set of data than seen by the application; the privacy implications are different; etc. > Congestion as an example is (IMO) causing a little confusion, > because it's both a real-time condition (e.g. "is the TCP stream > from peer A congested right now?") and an input into slow-moving > recommendations (e.g. "the link to ISP X is typically heavily > congested during the day, so don't connect peers across that link"). That isn't congestion; that's traffic engineering. It's irrelevant why the ISP thinks links are good or bad; it could simply be the pricing... > Perhaps it would be better not to provide the congestion example in > the write-up? > As an example of what NOT to do it is still useful. Cheers, DaveO. > -- > John Leslie > _______________________________________________ > p2pi mailing list > p2pi@ietf.org > https://www.ietf.org/mailman/listinfo/p2pi > _______________________________________________ > p2pi mailing list > p2pi@ietf.org > https://www.ietf.org/mailman/listinfo/p2pi _______________________________________________ p2pi mailing list p2pi@ietf.org https://www.ietf.org/mailman/listinfo/p2pi From p2pi-bounces@ietf.org Fri Aug 8 13:25: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 56B483A6AC0; Fri, 8 Aug 2008 13:25: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 3806E3A69F5 for ; Fri, 8 Aug 2008 13:25:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[AWL=-0.350, BAYES_00=-2.599, SARE_BIZOP=0.7] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HLOClWjdCo8s for ; Fri, 8 Aug 2008 13:25:06 -0700 (PDT) Received: from mailhost.jlc.net (mailhost.jlc.net [199.201.159.9]) by core3.amsl.com (Postfix) with ESMTP id 3781D3A69A1 for ; Fri, 8 Aug 2008 13:25:06 -0700 (PDT) Received: by mailhost.jlc.net (Postfix, from userid 104) id 441F033C34; Fri, 8 Aug 2008 16:25:04 -0400 (EDT) Date: Fri, 8 Aug 2008 16:25:03 -0400 From: John Leslie To: David R Oran Message-ID: <20080808202503.GB25453@verdi> References: <1317402407.115221218213823874.JavaMail.root@dkny.pando.com> <8438AFF1-9606-46F7-8E51-3962775D0F93@cisco.com> Mime-Version: 1.0 Content-Disposition: inline In-Reply-To: <8438AFF1-9606-46F7-8E51-3962775D0F93@cisco.com> User-Agent: Mutt/1.4.1i Cc: Lisa Dusseault , p2pi@ietf.org Subject: Re: [p2pi] After-BoF charter X-BeenThere: p2pi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: P2P Infrastructure Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: p2pi-bounces@ietf.org Errors-To: p2pi-bounces@ietf.org David R Oran wrote: > On Aug 8, 2008, at 12:43 PM, Laird Popkin wrote: >> ["John Leslie" wrote:] >>> [ext Enrico Marocco wrote:] >>> >>>> In any case, solutions proposed in this WG will not deal with >>>> frequently changing performance-related information, for example >>>> about traffic congestions; >>> >>> Congestion is the whole issue here -- we'd better not rule it out of >>> scope. >>> >>> ISPs will cooperate in this effort if it helps their congestion >>> problems -- and probably won't if it doesn't. > > Not necessarily. If they can increase their revenue by selling a > tiered service that optimizes P2P completion times that might be the > hook irrespective of congestion. Hmm... seems kinda speculative... They may well _think_ they can sell it to content suppliers; but they haven't had many takers so far. And IMHO, they can't sell it to consumers unless they first implement some kind of "penalty box". > It is of course desirable that ISPs cooperate and even lead the > charge; on the other hand we need to make ALTO succeed in the absence > of direct ISP deployment. Read: business opportunity. With this, I entirely agree! >> That said, we _should_ recognize that the p2p application is in a >> better position to evaluate instantaneous congestion than any ALTO >> server: thus asking the ALTO server for congestion level is unwise. > > Agree. Good -- we have common ground. :^) >> But ISPs probably _will_ implement some variety of "penalty box" >> for customers that "cause" too much congestion; and IMHO we'd be >> well advised to allow for an ISP's ALTO server to report how close >> a customer is to the penalty box. (This could change from second to >> second, in principle.) > > I am quite un-enthusiastic about this idea, because it's not possible > for the P2P application (or any individual application) to tell if > it's the one causing the creep to the penalty box or if it's the 5-way > video conference the customer is doing, or the HD streaming video > coming in from from some OTT video service. True. But it _is_ in a position to notify the user; and it may be in a better position than those other apps to find an alternate path. > I am even more unenthusiastic if the idea is that there is a specific > penalty box for P2P applications, because that keeps us stuck in the > DPI world with the customer and the ISP encouraged to engage in spy-vs- > spy tactics. I don't worry about that so much... I think ISPs are too lazy to implement multiple penalty boxes (and are at least a little afraid that the FCC would slap their wrists for doing so). > Plus, this doesn't help at all with penalty boxes tied to daily/weekly/ > monthly data volume caps. Frankly, that's a lousy model for penalty boxes -- and IMHO the ISPs will learn it doesn't solve their problem. > A better way to deal with this is full-disclosure by the ISP and > configurable rate shaping in the home router. Agreed. (Are you holding your breath?) >> I don't have any specific proposal -- it just seems unwise to rule >> this information out of scope. Please understand I mean exactly that. I'd like to be able to talk about it: very likely it won't lead to anything at all in the first version of an ALTO standard. > I think it is wise to declare this out of scope. So, we disagree here. If you say so... If you mean that no extensions to an ALTO protocol should ever be able to carry penalty-box info, then I guess we do disagree. If you mean the first release shouldn't, I don't disagree very much... -- John Leslie _______________________________________________ p2pi mailing list p2pi@ietf.org https://www.ietf.org/mailman/listinfo/p2pi From p2pi-bounces@ietf.org Fri Aug 8 14:13: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 31F203A6B34; Fri, 8 Aug 2008 14:13: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 A07DA3A6C2D for ; Fri, 8 Aug 2008 14:13:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[AWL=0.350, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SbvQkZiaaB8Q for ; Fri, 8 Aug 2008 14:13:22 -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 AAEEB3A6A94 for ; Fri, 8 Aug 2008 14:13:22 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.31,329,1215388800"; d="scan'208";a="93825882" Received: from sjc12-sbr-sw3-3f5.cisco.com (HELO imail.cisco.com) ([172.19.96.182]) by sj-iport-3.cisco.com with ESMTP; 08 Aug 2008 21:13:10 +0000 Received: from stealth-10-32-245-157.cisco.com ([10.32.245.157]) by imail.cisco.com (8.12.11/8.12.10) with ESMTP id m78KnW05031020; Fri, 8 Aug 2008 13:49:33 -0700 Message-Id: From: David R Oran To: John Leslie In-Reply-To: <20080808202503.GB25453@verdi> Mime-Version: 1.0 (Apple Message framework v928.1) Date: Fri, 8 Aug 2008 17:13:08 -0400 References: <1317402407.115221218213823874.JavaMail.root@dkny.pando.com> <8438AFF1-9606-46F7-8E51-3962775D0F93@cisco.com> <20080808202503.GB25453@verdi> X-Mailer: Apple Mail (2.928.1) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=3751; t=1218228574; x=1219092574; c=relaxed/simple; s=oregon; h=To:Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=oran@cisco.com; z=From:=20David=20R=20Oran=20 |Subject:=20Re=3A=20[p2pi]=20After-BoF=20charter |Sender:=20 |To:=20John=20Leslie=20; bh=aAKwwVOFikXTs9aDY89N/t3jxC1GI02yjXnx5kS/qY0=; b=fyPBnFWKjZ6QwW4vcJhjSnQwlGVkAtaPtbEnKXR1Q/Ko1l8rhw0sKh9BaK 7A0LnzVH/CWFBLU4A+WBIfNd1IgFUCpu1stXCrqMdoW88k863Y+OObfdumfB hh9xVw0g2g; Authentication-Results: imail.cisco.com; header.From=oran@cisco.com; dkim=pass ( sig from cisco.com/oregon verified; ); Cc: Lisa Dusseault , p2pi@ietf.org Subject: Re: [p2pi] After-BoF charter X-BeenThere: p2pi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: P2P Infrastructure Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: p2pi-bounces@ietf.org Errors-To: p2pi-bounces@ietf.org On Aug 8, 2008, at 4:25 PM, John Leslie wrote: > David R Oran wrote: >> On Aug 8, 2008, at 12:43 PM, Laird Popkin wrote: >>> [snip] >>> >>> But ISPs probably _will_ implement some variety of "penalty box" >>> for customers that "cause" too much congestion; and IMHO we'd be >>> well advised to allow for an ISP's ALTO server to report how close >>> a customer is to the penalty box. (This could change from second to >>> second, in principle.) >> >> I am quite un-enthusiastic about this idea, because it's not possible >> for the P2P application (or any individual application) to tell if >> it's the one causing the creep to the penalty box or if it's the 5- >> way >> video conference the customer is doing, or the HD streaming video >> coming in from from some OTT video service. > > True. But it _is_ in a position to notify the user; and it may be > in a better position than those other apps to find an alternate path. > This seems a very good way to the ISP to convince users to throttle themselves without actually having actual capacity/congestion problems. I really don't see how this can work anywhere near as well in practice as ECN or other techniques to give congestion feedback that without dropping packets. >> I am even more unenthusiastic if the idea is that there is a specific >> penalty box for P2P applications, because that keeps us stuck in the >> DPI world with the customer and the ISP encouraged to engage in spy- >> vs- >> spy tactics. > > I don't worry about that so much... I think ISPs are too lazy to > implement multiple penalty boxes (and are at least a little afraid > that the FCC would slap their wrists for doing so). > I thought they'd be smart enough to not try to do DPI because of the inevitable arms race and the high BTU hot water generator sending TCP RSTs turned out to be. The whole thing started by the ISPs trying to differentiate applications "on behalf of" the users to "help them" keep their web browsing snappy in the presence of all that background traffic. So, I have no idea what the ISPs might or might not do here. >> Plus, this doesn't help at all with penalty boxes tied to daily/ >> weekly/ >> monthly data volume caps. > > Frankly, that's a lousy model for penalty boxes -- and IMHO the ISPs > will learn it doesn't solve their problem. > Like the cellular operators did? (not). >> A better way to deal with this is full-disclosure by the ISP and >> configurable rate shaping in the home router. > > Agreed. (Are you holding your breath?) > >>> I don't have any specific proposal -- it just seems unwise to rule >>> this information out of scope. > > Please understand I mean exactly that. I'd like to be able to talk > about it: very likely it won't lead to anything at all in the first > version of an ALTO standard. > What I'd like to rule out of scope is discussion of billing, data volume, or cap-related data in the ALTO schema, because it skirts the edge of the IETF mandate to not do billing or account control related work. This has served us fairly well in the VoIP arena, and has gotten us into trouble the times we tread too close to the line. >> I think it is wise to declare this out of scope. So, we disagree >> here. > > If you say so... > > If you mean that no extensions to an ALTO protocol should ever be > able to carry penalty-box info, then I guess we do disagree. If you > mean the first release shouldn't, I don't disagree very much... > I think it should be explicitly out until the WG chairs and area directors decides it should be in. My 2cents, FWIW... DaveO. > -- > John Leslie _______________________________________________ p2pi mailing list p2pi@ietf.org https://www.ietf.org/mailman/listinfo/p2pi From p2pi-bounces@ietf.org Fri Aug 8 16:38: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 22E983A69FE; Fri, 8 Aug 2008 16:38: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 A21A93A67B0 for ; Fri, 8 Aug 2008 16:38:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.434 X-Spam-Level: X-Spam-Status: No, score=0.434 tagged_above=-999 required=5 tests=[AWL=0.463, BAYES_05=-1.11, DNS_FROM_RFC_BOGUSMX=1.482, J_CHICKENPOX_57=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wuRodMUqtopg for ; Fri, 8 Aug 2008 16:37:55 -0700 (PDT) Received: from smtp3.smtp.bt.com (smtp3.smtp.bt.com [217.32.164.138]) by core3.amsl.com (Postfix) with ESMTP id C9C913A687A for ; Fri, 8 Aug 2008 16:37:40 -0700 (PDT) Received: from i2kc06-ukbr.domain1.systemhost.net ([193.113.197.70]) by smtp3.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 9 Aug 2008 00:37:40 +0100 Received: from cbibipnt05.iuser.iroot.adidom.com ([147.149.196.177]) by i2kc06-ukbr.domain1.systemhost.net with Microsoft SMTPSVC(6.0.3790.1830); Sat, 9 Aug 2008 00:37:40 +0100 Received: From bagheera.jungle.bt.co.uk ([132.146.168.158]) by cbibipnt05.iuser.iroot.adidom.com (WebShield SMTP v4.5 MR1a P0803.399); id 1218238524451; Sat, 9 Aug 2008 00:35:24 +0100 Received: from mut.jungle.bt.co.uk ([10.215.130.87]) by bagheera.jungle.bt.co.uk (8.13.5/8.12.8) with ESMTP id m78Nbar3026703; Sat, 9 Aug 2008 00:37:36 +0100 Message-Id: <200808082337.m78Nbar3026703@bagheera.jungle.bt.co.uk> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Sat, 09 Aug 2008 00:37:39 +0100 To: David R Oran From: Bob Briscoe In-Reply-To: References: <1317402407.115221218213823874.JavaMail.root@dkny.pando.com> <8438AFF1-9606-46F7-8E51-3962775D0F93@cisco.com> <20080808202503.GB25453@verdi> Mime-Version: 1.0 X-Scanned-By: MIMEDefang 2.56 on 132.146.168.158 X-OriginalArrivalTime: 08 Aug 2008 23:37:40.0430 (UTC) FILETIME=[BF4F56E0:01C8F9AF] Cc: Lisa Dusseault , p2pi@ietf.org Subject: Re: [p2pi] After-BoF charter X-BeenThere: p2pi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: P2P Infrastructure Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: p2pi-bounces@ietf.org Errors-To: p2pi-bounces@ietf.org At 22:13 08/08/2008, David R Oran wrote: >At 21:25 08/08/2008, John Leslie wrote: >> If you mean that no extensions to an ALTO protocol should ever be >>able to carry penalty-box info, then I guess we do disagree. If you >>mean the first release shouldn't, I don't disagree very much... >I think it should be explicitly out until the WG chairs and area >directors decides it should be in. I agree with Dave that info in how close a customer is to a penalty box should be out of scope of this charter completely. Reason: It's a different service completely. ALTO is about giving hints on initial hosts to connect to - that's a service about the network that could feasibly be operated by a 3rd party, not the ISP (perhaps gathering info from multiple ISPs and from p2p networks etc). Penalty box status is about giving the status of the ISP's retail service itself, so it can only be operated by the ISP (or an agent of the ISP). Bob ____________________________________________________________________________ Bob Briscoe, Networks Research Centre, BT Research B54/77 Adastral Park,Martlesham Heath,Ipswich,IP5 3RE,UK. +44 1473 645196 _______________________________________________ p2pi mailing list p2pi@ietf.org https://www.ietf.org/mailman/listinfo/p2pi From p2pi-bounces@ietf.org Fri Aug 8 17:40: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 C559E3A6C59; Fri, 8 Aug 2008 17:40: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 B0B4C3A6C59 for ; Fri, 8 Aug 2008 17:40:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.541 X-Spam-Level: X-Spam-Status: No, score=-0.541 tagged_above=-999 required=5 tests=[AWL=0.976, BAYES_00=-2.599, DNS_FROM_RFC_BOGUSMX=1.482, J_CHICKENPOX_57=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wFL8PjlAISE2 for ; Fri, 8 Aug 2008 17:40:25 -0700 (PDT) Received: from smtp3.smtp.bt.com (smtp3.smtp.bt.com [217.32.164.138]) by core3.amsl.com (Postfix) with ESMTP id 2C3DA3A6B99 for ; Fri, 8 Aug 2008 17:40:24 -0700 (PDT) Received: from i2kc08-ukbr.domain1.systemhost.net ([193.113.197.71]) by smtp3.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 9 Aug 2008 01:40:22 +0100 Received: from cbibipnt08.iuser.iroot.adidom.com ([147.149.100.81]) by i2kc08-ukbr.domain1.systemhost.net with Microsoft SMTPSVC(6.0.3790.1830); Sat, 9 Aug 2008 01:40:22 +0100 Received: From bagheera.jungle.bt.co.uk ([132.146.168.158]) by cbibipnt08.iuser.iroot.adidom.com (WebShield SMTP v4.5 MR1a P0803.399); id 1218242421970; Sat, 9 Aug 2008 01:40:21 +0100 Received: from mut.jungle.bt.co.uk ([10.215.130.87]) by bagheera.jungle.bt.co.uk (8.13.5/8.12.8) with ESMTP id m790eK78029921; Sat, 9 Aug 2008 01:40:20 +0100 Message-Id: <200808090040.m790eK78029921@bagheera.jungle.bt.co.uk> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Sat, 09 Aug 2008 01:40:23 +0100 To: Enrico Marocco From: Bob Briscoe In-Reply-To: <489B47A0.1050507@telecomitalia.it> References: <489B47A0.1050507@telecomitalia.it> Mime-Version: 1.0 X-Scanned-By: MIMEDefang 2.56 on 132.146.168.158 X-OriginalArrivalTime: 09 Aug 2008 00:40:22.0547 (UTC) FILETIME=[81B4D630:01C8F9B8] Cc: Lisa Dusseault , "p2pi@ietf.org" Subject: Re: [p2pi] After-BoF charter X-BeenThere: p2pi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: P2P Infrastructure Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: p2pi-bounces@ietf.org Errors-To: p2pi-bounces@ietf.org Enrico, Charter generally looks good. Generally agree with Lars, Dave's & Laird's responses so far. My additional 3 penny's worth: 1/ Server operator issues ------------------------- The charter should say that there is no assumption that the requester's ISP operates the server. But the requester needs to be able to access a server that will give info relative to the network to which she is attached. And there may be competing ALTO servers that could serve the same requester. So there is also a requirement that a requester should be able to choose the server operated by the one she prefers. There is also a requirement that the requester can authenticate the operator of the server she has accessed (otherwise a spoof server could junk an ISPs network by giving out perverse responses). 2/ Empirical measurement wordsmithing Current text: >Empirical measurements of peer communication performance help a >great deal, but this is not always an option nor does it always >arrive at an optimal arrangement of peers in a reasonable time, thus >causing reduced perfomormance and excessive cross-domain traffic. Proposed text: >Empirical measurements of peer communication performance helps a >great deal, but this does not always arrive at an optimal >arrangement of peers in a reasonable time, thus causing reduced >performance both for the peers and other network users. Reasoning: - Empirical measurement is always an option. - see next point for why I've proposed scrubbing the implication that only cross-traffic is bad. 3/ What does optimal mean, and what does better mean? The charter has hidden assumptions about what optimal is, and what better is. From whose perspective? It needs to either say what these assumptions are, or say that the w-g will define what optimal means in a w-g document. As I have to keep saying, and as Richard Woundy from ComCast has agreed, excessive cross domain traffic is much less bad than excessive local traffic. I agree that the /current/ traffic arrangement resulting from p2p has excessive cross-domain traffic. But this is the not-seeing-beyond-the-first-step problem I tried to explain at the mic in the ALTO BoF. Once traffic is sitting in an optimum arrangement (possibly bootstrapped by ALTO then optimised by e2e congestion control), the best place to add the /next/ connection will likely be cross-domain not local. Because the optimium is a /balance/ of light congestion across both. This is why the goal MUST NOT be unconditional localisation. That could eventually drive the network /beyond/ the balance, persistently trying to drive up congestion in the access and backhaul. That will be much worse than excessive cross-domain traffic. You might say it would be nice to have that problem. But if this service only does localisation, it will only be safe /if/ it is used by a minority. If the popularity of an ALTO service goes beyond a certain point, it will start to kill the ISP's local network. Of course, then less people will use it and an equilibrium might be reached. But that's what I said. Optimisation is a process, not just a first step. ALTO has to be able to move traffic out, not just in. \ \ \ /\ \ / \ ^----- <<<---goal \ / V \/ NOT \ \ \ \ <<<---goal \ \ \ \ \ \ Bob At 20:06 07/08/2008, Enrico Marocco wrote: >We have tried to collect all comments received during the meeting, in >mailing list and hallway discussions. The new version of the charter, >available as always at http://alto.tilab.com/docs/charter.txt, should >reflect at least some of them. Please take a look and comment. Feel free >to say if you don't like it -- entirely or partially -- and why; or if >you like it. And why. > >Major changes include: >+ terminology: dropped terms like "the oracle" and "best peer"; >+ scope: removed cache/TURN/whatever service discovery; >+ path selection: stressed the importance of routing preferences and > peering policies; >+ forbidden third-party queries; >+ mentioned IRTF for analysis on more sophisticated metrics. > >The current version of the charter is also more explicit about what >pieces of information will be provided by an ALTO service; I'll start a >separate thread specifically for this discussion. > >-- >Ciao, >Enrico > > >_______________________________________________ >p2pi mailing list >p2pi@ietf.org >https://www.ietf.org/mailman/listinfo/p2pi ____________________________________________________________________________ Bob Briscoe, Networks Research Centre, BT Research B54/77 Adastral Park,Martlesham Heath,Ipswich,IP5 3RE,UK. +44 1473 645196 _______________________________________________ p2pi mailing list p2pi@ietf.org https://www.ietf.org/mailman/listinfo/p2pi From p2pi-bounces@ietf.org Mon Aug 11 06:52: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 5CAD23A6C5E; Mon, 11 Aug 2008 06:52: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 85BEF3A6B59 for ; Mon, 11 Aug 2008 06:52:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.14 X-Spam-Level: X-Spam-Status: No, score=-4.14 tagged_above=-999 required=5 tests=[BAYES_20=-0.74, J_CHICKENPOX_57=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tr5dQ4DU0fKZ for ; Mon, 11 Aug 2008 06:52:26 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id DD9C93A6B5F for ; Mon, 11 Aug 2008 06:52:20 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.31,341,1215388800"; d="scan'208";a="138496912" Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-6.cisco.com with ESMTP; 11 Aug 2008 13:52:18 +0000 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id m7BDqIDg002313; Mon, 11 Aug 2008 06:52:18 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id m7BDqHuX025993; Mon, 11 Aug 2008 13:52:18 GMT Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 11 Aug 2008 06:52:12 -0700 Received: from [10.32.241.74] ([10.32.241.74]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 11 Aug 2008 06:52:12 -0700 In-Reply-To: <200808090040.m790eK78029921@bagheera.jungle.bt.co.uk> References: <489B47A0.1050507@telecomitalia.it> <200808090040.m790eK78029921@bagheera.jungle.bt.co.uk> Mime-Version: 1.0 (Apple Message framework v753.1) Message-Id: From: Bruce Davie Date: Mon, 11 Aug 2008 09:51:48 -0400 To: Bob Briscoe X-Mailer: Apple Mail (2.753.1) X-OriginalArrivalTime: 11 Aug 2008 13:52:12.0140 (UTC) FILETIME=[7474EAC0:01C8FBB9] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=5094; t=1218462738; x=1219326738; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=bdavie@cisco.com; z=From:=20Bruce=20Davie=20 |Subject:=20Re=3A=20[p2pi]=20After-BoF=20charter |Sender:=20; bh=zlUr4CB8Hm49UdlvNlOsKREMiltiz0kCxhgX3yd3iBU=; b=dKcOzcLACiiC8XlrvDcTlE7i5VR8L8pQvRUROQ5RanxTqUkWOieHaP0f+T FkUhuScapvvLBsNOKXpqqbBjEcehzaH9HQFHRGPrCnDpdmmbaAIqbHm+4HOV ckufbpM74RSxfIlFhhRdjFguWtJnFIBFqSKxHitf2jMAry+gBiPms=; Authentication-Results: sj-dkim-1; header.From=bdavie@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); Cc: "p2pi@ietf.org" , Lisa Dusseault Subject: Re: [p2pi] After-BoF charter X-BeenThere: p2pi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: P2P Infrastructure Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: p2pi-bounces@ietf.org Errors-To: p2pi-bounces@ietf.org Good points Bob, most of which I agree with. A little clarification below: On Aug 8, 2008, at 8:40 PM, Bob Briscoe wrote: > Enrico, > > Charter generally looks good. > Generally agree with Lars, Dave's & Laird's responses so far. > My additional 3 penny's worth: > [snip] > > 3/ What does optimal mean, and what does better mean? > > The charter has hidden assumptions about what optimal is, and what > better is. From whose perspective? It needs to either say what > these assumptions are, or say that the w-g will define what optimal > means in a w-g document. I would suggest that there will be different views of optimal for different providers, and the WG should work on capturing that fact and developing solutions that can deal with it. > > As I have to keep saying, and as Richard Woundy from ComCast has > agreed, excessive cross domain traffic is much less bad than > excessive local traffic. I believe you have just stated what is optimal for two providers, but I'm not convinced that the entire universe of providers agrees with you. I think the WG needs to deal with the fact that some providers will care about reducing backhaul traffic and others will care about reducing inter-domain traffic. Rather than trying to get this all nailed down in the charter, I think it would be good if the charter mentioned the problem of defining optimality from a variety of perspectives as one of its work items. I also note that the charter is ultimately intended only to specify the interface between clients and "peer selection services" - so we need to make sure that the information carried across that interface is sufficiently rich to allow for a range of different definitions of optimality. We don't need to get everyone to buy into a single definition of optimality. The rest of your email below finds me in complete agreement. Bruce > > I agree that the /current/ traffic arrangement resulting from p2p > has excessive cross-domain traffic. But this is the not-seeing- > beyond-the-first-step problem I tried to explain at the mic in the > ALTO BoF. > > Once traffic is sitting in an optimum arrangement (possibly > bootstrapped by ALTO then optimised by e2e congestion control), the > best place to add the /next/ connection will likely be cross-domain > not local. Because the optimium is a /balance/ of light congestion > across both. This is why the goal MUST NOT be unconditional > localisation. That could eventually drive the network /beyond/ the > balance, persistently trying to drive up congestion in the access > and backhaul. That will be much worse than excessive cross-domain > traffic. > > You might say it would be nice to have that problem. > > But if this service only does localisation, it will only be safe / > if/ it is used by a minority. If the popularity of an ALTO service > goes beyond a certain point, it will start to kill the ISP's local > network. Of course, then less people will use it and an equilibrium > might be reached. But that's what I said. Optimisation is a > process, not just a first step. ALTO has to be able to move traffic > out, not just in. > > \ > \ > \ /\ > \ / \ ^----- <<<---goal > \ / V > \/ > > NOT > \ > \ > \ > \ <<<---goal > \ > \ > \ > \ > \ > \ > > > Bob > > At 20:06 07/08/2008, Enrico Marocco wrote: >> We have tried to collect all comments received during the meeting, in >> mailing list and hallway discussions. The new version of the charter, >> available as always at http://alto.tilab.com/docs/charter.txt, should >> reflect at least some of them. Please take a look and comment. >> Feel free >> to say if you don't like it -- entirely or partially -- and why; >> or if >> you like it. And why. >> >> Major changes include: >> + terminology: dropped terms like "the oracle" and "best peer"; >> + scope: removed cache/TURN/whatever service discovery; >> + path selection: stressed the importance of routing preferences and >> peering policies; >> + forbidden third-party queries; >> + mentioned IRTF for analysis on more sophisticated metrics. >> >> The current version of the charter is also more explicit about what >> pieces of information will be provided by an ALTO service; I'll >> start a >> separate thread specifically for this discussion. >> >> -- >> Ciao, >> Enrico >> >> >> _______________________________________________ >> p2pi mailing list >> p2pi@ietf.org >> https://www.ietf.org/mailman/listinfo/p2pi > > ______________________________________________________________________ > ______ > Bob Briscoe, Networks Research Centre, BT > Research > B54/77 Adastral Park,Martlesham Heath,Ipswich,IP5 3RE,UK. +44 > 1473 645196 > _______________________________________________ > p2pi mailing list > p2pi@ietf.org > https://www.ietf.org/mailman/listinfo/p2pi _______________________________________________ p2pi mailing list p2pi@ietf.org https://www.ietf.org/mailman/listinfo/p2pi From p2pi-bounces@ietf.org Mon Aug 11 07:31: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 630723A6CB8; Mon, 11 Aug 2008 07:31: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 2AC743A6D65 for ; Mon, 11 Aug 2008 07:31:42 -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_57=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZaeIObO7LuLH for ; Mon, 11 Aug 2008 07:31:41 -0700 (PDT) Received: from dkny.pando.com (dkny.pando.com [67.99.55.163]) by core3.amsl.com (Postfix) with ESMTP id 96ADC3A69C1 for ; Mon, 11 Aug 2008 07:31:40 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by dkny.pando.com (Postfix) with ESMTP id D6B4CE10A82; Mon, 11 Aug 2008 10:31:36 -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 490XC6JKL+Jf; Mon, 11 Aug 2008 10:31:19 -0400 (EDT) Received: from [10.10.20.61] (unknown [10.10.20.61]) by dkny.pando.com (Postfix) with ESMTP id BB2B9E10A15; Mon, 11 Aug 2008 10:31:19 -0400 (EDT) Message-Id: <463FAC40-3A41-4F0D-9517-F6A9670B7650@pando.com> From: Laird Popkin To: Bruce Davie In-Reply-To: Mime-Version: 1.0 (Apple Message framework v928.1) Date: Mon, 11 Aug 2008 10:31:19 -0400 References: <489B47A0.1050507@telecomitalia.it> <200808090040.m790eK78029921@bagheera.jungle.bt.co.uk> X-Mailer: Apple Mail (2.928.1) Cc: Lisa Dusseault , "p2pi@ietf.org" Subject: Re: [p2pi] After-BoF charter X-BeenThere: p2pi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: P2P Infrastructure Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: p2pi-bounces@ietf.org Errors-To: p2pi-bounces@ietf.org I agree. Because every ISP has their own preferences and policies, I don't think that it's too productive to try to come up with a specific definition of 'best'. Instead we should focus on creating a sufficiently general mechanism that it allows ISPs to express a reasonable range of policies, with an extension mechanism to allow people to cover cases that we didn't think of up front. On the topic of "third party queries", can someone explain what the concern is? Third party ALTO queries seem extremely useful, and I'm having trouble thinking of a counter-example. - LP On Aug 11, 2008, at 9:51 AM, Bruce Davie wrote: > Good points Bob, most of which I agree with. A little clarification > below: > > On Aug 8, 2008, at 8:40 PM, Bob Briscoe wrote: > >> Enrico, >> >> Charter generally looks good. >> Generally agree with Lars, Dave's & Laird's responses so far. >> My additional 3 penny's worth: >> > [snip] > >> >> 3/ What does optimal mean, and what does better mean? >> >> The charter has hidden assumptions about what optimal is, and what >> better is. From whose perspective? It needs to either say what >> these assumptions are, or say that the w-g will define what optimal >> means in a w-g document. > > I would suggest that there will be different views of optimal for > different providers, and the WG should work on capturing that fact > and developing solutions that can deal with it. > >> >> As I have to keep saying, and as Richard Woundy from ComCast has >> agreed, excessive cross domain traffic is much less bad than >> excessive local traffic. > > I believe you have just stated what is optimal for two providers, > but I'm not convinced that the entire universe of providers agrees > with you. I think the WG needs to deal with the fact that some > providers will care about reducing backhaul traffic and others will > care about reducing inter-domain traffic. > > Rather than trying to get this all nailed down in the charter, I > think it would be good if the charter mentioned the problem of > defining optimality from a variety of perspectives as one of its > work items. > > I also note that the charter is ultimately intended only to specify > the interface between clients and "peer selection services" - so we > need to make sure that the information carried across that interface > is sufficiently rich to allow for a range of different definitions > of optimality. We don't need to get everyone to buy into a single > definition of optimality. > > The rest of your email below finds me in complete agreement. > > Bruce > >> >> I agree that the /current/ traffic arrangement resulting from p2p >> has excessive cross-domain traffic. But this is the not-seeing- >> beyond-the-first-step problem I tried to explain at the mic in the >> ALTO BoF. >> >> Once traffic is sitting in an optimum arrangement (possibly >> bootstrapped by ALTO then optimised by e2e congestion control), the >> best place to add the /next/ connection will likely be cross-domain >> not local. Because the optimium is a /balance/ of light congestion >> across both. This is why the goal MUST NOT be unconditional >> localisation. That could eventually drive the network /beyond/ the >> balance, persistently trying to drive up congestion in the access >> and backhaul. That will be much worse than excessive cross-domain >> traffic. >> >> You might say it would be nice to have that problem. >> >> But if this service only does localisation, it will only be safe / >> if/ it is used by a minority. If the popularity of an ALTO service >> goes beyond a certain point, it will start to kill the ISP's local >> network. Of course, then less people will use it and an equilibrium >> might be reached. But that's what I said. Optimisation is a >> process, not just a first step. ALTO has to be able to move traffic >> out, not just in. >> >> \ >> \ >> \ /\ >> \ / \ ^----- <<<---goal >> \ / V >> \/ >> >> NOT >> \ >> \ >> \ >> \ <<<---goal >> \ >> \ >> \ >> \ >> \ >> \ >> >> >> Bob >> >> At 20:06 07/08/2008, Enrico Marocco wrote: >>> We have tried to collect all comments received during the meeting, >>> in >>> mailing list and hallway discussions. The new version of the >>> charter, >>> available as always at http://alto.tilab.com/docs/charter.txt, >>> should >>> reflect at least some of them. Please take a look and comment. >>> Feel free >>> to say if you don't like it -- entirely or partially -- and why; >>> or if >>> you like it. And why. >>> >>> Major changes include: >>> + terminology: dropped terms like "the oracle" and "best peer"; >>> + scope: removed cache/TURN/whatever service discovery; >>> + path selection: stressed the importance of routing preferences and >>> peering policies; >>> + forbidden third-party queries; >>> + mentioned IRTF for analysis on more sophisticated metrics. >>> >>> The current version of the charter is also more explicit about what >>> pieces of information will be provided by an ALTO service; I'll >>> start a >>> separate thread specifically for this discussion. >>> >>> -- >>> Ciao, >>> Enrico >>> >>> >>> _______________________________________________ >>> p2pi mailing list >>> p2pi@ietf.org >>> https://www.ietf.org/mailman/listinfo/p2pi >> >> ____________________________________________________________________________ >> Bob Briscoe, Networks Research Centre, BT >> Research >> B54/77 Adastral Park,Martlesham Heath,Ipswich,IP5 3RE,UK. +44 >> 1473 645196 >> _______________________________________________ >> p2pi mailing list >> p2pi@ietf.org >> https://www.ietf.org/mailman/listinfo/p2pi > > _______________________________________________ > p2pi mailing list > p2pi@ietf.org > https://www.ietf.org/mailman/listinfo/p2pi _______________________________________________ p2pi mailing list p2pi@ietf.org https://www.ietf.org/mailman/listinfo/p2pi From p2pi-bounces@ietf.org Mon Aug 11 07:35: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 379273A6E6A; Mon, 11 Aug 2008 07:35: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 4A6E53A6E67 for ; Mon, 11 Aug 2008 07:35:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.351 X-Spam-Level: X-Spam-Status: No, score=0.351 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3txZWk0vDN8P for ; Mon, 11 Aug 2008 07:35:32 -0700 (PDT) Received: from mail.net.t-labs.tu-berlin.de (mail.net.t-labs.tu-berlin.de [130.149.220.252]) by core3.amsl.com (Postfix) with ESMTP id 11BE43A6E6B for ; Mon, 11 Aug 2008 07:35:32 -0700 (PDT) Received: from crow.net.t-labs.tu-berlin.de (crow.net.t-labs.tu-berlin.de [130.149.220.17]) by mail.net.t-labs.tu-berlin.de (Postfix) with ESMTP id DE98D705D0C4; Mon, 11 Aug 2008 16:35:31 +0200 (CEST) Received: by crow.net.t-labs.tu-berlin.de (Postfix, from userid 10007) id 6D7FF4008D97; Mon, 11 Aug 2008 16:35:31 +0200 (CEST) Date: Mon, 11 Aug 2008 16:35:31 +0200 From: Vinay Aggarwal To: Enrico Marocco Message-ID: <20080811143531.GA18911@net.t-labs.tu-berlin.de> References: <489B498B.4040804@telecomitalia.it> Mime-Version: 1.0 Content-Disposition: inline In-Reply-To: <489B498B.4040804@telecomitalia.it> User-Agent: Mutt/1.5.11 Cc: "p2pi@ietf.org" Subject: Re: [p2pi] Information in an ALTO protocol X-BeenThere: p2pi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: P2P Infrastructure Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: 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, Regarding what information the ALTO service can provide: I think an estimate of "last-hop bandwidth" can be an interesting metric of information for peer selection. It has been shown that selecting peers with high last-hop bandwidth lead to improvements in download performance. And this is information that is rather hard for peers to find out themselves. As far as I can see, it also satisfies all the bars set up by the ALTO service. Any thoughts? Thanks, Vinay. ----------------- Vinay Aggarwal Deutsche Telekom Germany. On Thu, Aug 07, 2008 at 09:14:19PM +0200, Enrico Marocco wrote: > As some people suggested, it may be useful to try to understand what > kind of information will be provided by an ALTO service. > > Current version of the charter lists four pieces of information: > + routing preferences and priority values. The network operator is > usually the only entity in possession of such information, but it is > in its interests to share at least part of it with applications, in > order to reduce traffic on critical links. On the other hand, if > following such preferences leads to better-than-random choices, it is > also in applications' interest to follow them; > + AS numbers and approximate geographic locations. Such information is > today (partially) available and, in fact, is in some cases already > used for peer selection. However, since there is no standard way to > obtain it, it is not easy for applications to switch from an > information provider to another. > > The charter does not preclude any other kind of information entirely, > but it sets the bar pretty high, requiring that: > > When the WG considers standardizing schemas, measures or other > information that the ALTO service could provide, the following > criteria are important to ensure real feasibility. > - Can an ALTO service technically provide that information? > - Is the ALTO service willing to obtain and divulge that information? > - Is it information that some client will find useful? > - Can that client get that information without excessive privacy > concerns (e.g. by sending large lists of peers)? > - Is it information that clients cannot find easily some other way? > > Thoughts? > > -- > 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 Aug 11 08:02: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 D81253A69AF; Mon, 11 Aug 2008 08:02: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 2C9E93A69AF for ; Mon, 11 Aug 2008 08:02:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.577 X-Spam-Level: X-Spam-Status: No, score=-6.577 tagged_above=-999 required=5 tests=[AWL=0.022, 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 rSS+Y1Deii4V for ; Mon, 11 Aug 2008 08:02:39 -0700 (PDT) Received: from mgw-mx03.nokia.com (smtp.nokia.com [192.100.122.230]) by core3.amsl.com (Postfix) with ESMTP id 1BC8F3A685C for ; Mon, 11 Aug 2008 08:02:38 -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 m7BF19NR005675; Mon, 11 Aug 2008 18:01:26 +0300 Received: from vaebh103.NOE.Nokia.com ([10.160.244.24]) by vaebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 11 Aug 2008 18:01:01 +0300 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by vaebh103.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 11 Aug 2008 18:00:53 +0300 Received: from net-115.nrpn.net ([10.241.184.208]) by esebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Mon, 11 Aug 2008 18:00:52 +0300 Message-Id: From: Lars Eggert To: ext Vinay Aggarwal In-Reply-To: <20080811143531.GA18911@net.t-labs.tu-berlin.de> Mime-Version: 1.0 (Apple Message framework v926) Date: Mon, 11 Aug 2008 18:00:47 +0300 References: <489B498B.4040804@telecomitalia.it> <20080811143531.GA18911@net.t-labs.tu-berlin.de> X-Mailer: Apple Mail (2.926) X-OriginalArrivalTime: 11 Aug 2008 15:00:52.0820 (UTC) FILETIME=[0C92C940:01C8FBC3] X-Nokia-AV: Clean Cc: "p2pi@ietf.org" Subject: Re: [p2pi] Information in an ALTO protocol X-BeenThere: p2pi@ietf.org 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-8-11, at 17:35, ext Vinay Aggarwal wrote: > I think an estimate of "last-hop bandwidth" can be an interesting > metric > of information for peer selection. > It has been shown that selecting peers with high last-hop bandwidth > lead > to improvements in download performance. And this is information > that is > rather hard for peers to find out themselves. As far as I can see, it > also satisfies all the bars set up by the ALTO service. Uplink or downlink bandwidth? Provisioned bandwidth (i.e., the nominal bandwidth a user is paying for) or the currently available fraction of it? The latter would be something that I doubt an ALTO box can have an accurate view of, since it changes on short timescales. Could you share a reference to papers that show that that information is beneficial? Thanks, Lars _______________________________________________ p2pi mailing list p2pi@ietf.org https://www.ietf.org/mailman/listinfo/p2pi From p2pi-bounces@ietf.org Mon Aug 11 08:11: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 94EAD3A6CFC; Mon, 11 Aug 2008 08:11: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 F33273A6CE2 for ; Mon, 11 Aug 2008 08:11:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.115 X-Spam-Level: X-Spam-Status: No, score=-10.115 tagged_above=-999 required=5 tests=[AWL=0.150, 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 sHqx9VJ+0yTT for ; Mon, 11 Aug 2008 08:11:29 -0700 (PDT) Received: from dkny.pando.com (dkny.pando.com [67.99.55.163]) by core3.amsl.com (Postfix) with ESMTP id C17013A65A6 for ; Mon, 11 Aug 2008 08:11:29 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by dkny.pando.com (Postfix) with ESMTP id DC663E10B22; Mon, 11 Aug 2008 11:11:28 -0400 (EDT) X-Virus-Scanned: amavisd-new at Received: from dkny.pando.com ([127.0.0.1]) by localhost (dkny.pando.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nt-2jPsoWBLc; Mon, 11 Aug 2008 11:11:20 -0400 (EDT) Received: from dkny.pando.com (dkny.pando.com [10.10.60.11]) by dkny.pando.com (Postfix) with ESMTP id 52A91E10AF6; Mon, 11 Aug 2008 11:11:20 -0400 (EDT) Date: Mon, 11 Aug 2008 11:11:20 -0400 (EDT) From: Laird Popkin To: Lars Eggert Message-ID: <735025520.120641218467480318.JavaMail.root@dkny.pando.com> In-Reply-To: MIME-Version: 1.0 X-Originating-IP: [10.10.20.79] Cc: p2pi@ietf.org Subject: Re: [p2pi] Information in an ALTO protocol X-BeenThere: p2pi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: P2P Infrastructure Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: 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 would certainly be value in differentiating between classes of users in terms of their nominal uplink capacity. For example, an ISP with a mix of DSL and FTTH customers would probably prefer that p2p data download from FTTH rather than DSL sources. I agree that ALTO shouldn't try to know real-time consumption rates vs. capacity. That's (IMO) a question to ask something local to the user, not from a centralized service. - Laird Popkin, CTO, Pando Networks mobile: 646/465-0570 ----- Original Message ----- From: "Lars Eggert" To: "ext Vinay Aggarwal" Cc: p2pi@ietf.org Sent: Monday, August 11, 2008 11:00:47 AM (GMT-0500) America/New_York Subject: Re: [p2pi] Information in an ALTO protocol Hi, On 2008-8-11, at 17:35, ext Vinay Aggarwal wrote: > I think an estimate of "last-hop bandwidth" can be an interesting > metric > of information for peer selection. > It has been shown that selecting peers with high last-hop bandwidth > lead > to improvements in download performance. And this is information > that is > rather hard for peers to find out themselves. As far as I can see, it > also satisfies all the bars set up by the ALTO service. Uplink or downlink bandwidth? Provisioned bandwidth (i.e., the nominal bandwidth a user is paying for) or the currently available fraction of it? The latter would be something that I doubt an ALTO box can have an accurate view of, since it changes on short timescales. Could you share a reference to papers that show that that information is beneficial? Thanks, 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 Mon Aug 11 08:37: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 139263A6E6F; Mon, 11 Aug 2008 08:37: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 72EB33A6E6F for ; Mon, 11 Aug 2008 08:37:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z1SsJXunq0cd for ; Mon, 11 Aug 2008 08:37:19 -0700 (PDT) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.237]) by core3.amsl.com (Postfix) with ESMTP id 591593A67B6 for ; Mon, 11 Aug 2008 08:37:17 -0700 (PDT) Received: by rv-out-0506.google.com with SMTP id b25so1905231rvf.49 for ; Mon, 11 Aug 2008 08:37:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type:references; bh=3oX8HEZ6V9YlugGVuAt8roYInltB5IxsYL886eK/u60=; b=wWdTCvZDPwxDtA0NBoPgvV0GEkNcMvGTIDi3KV4PZvulyOukpHB0dbNuVl/r23U6B+ tbbTKWqiRKcDBwzDuOv089LXBpIJLDyuPuQIfLRqLmmgVDakKT3ScG0+wt/Lm30xxe1+ Ix22pM2gluo+XUgrsUdwkBqgFVuyA73LP2EK4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:references; b=FbpK7OZhXrYC5kQdv017OMJemwLyp5eRZdmibWOQqZAr1xKj3afud8Pcwa48Nr+nlp ZFIfbtVp6zC2EOkd9Rk9ITguK56zizHb/xZ1DWmz3UMpngtIrWGxxHb8CYvPXHw+FNMD 5BH0BLrKwRymUtuVUN/TFOGaKTVlImdqIHbQs= Received: by 10.140.165.21 with SMTP id n21mr3586991rve.244.1218469039129; Mon, 11 Aug 2008 08:37:19 -0700 (PDT) Received: by 10.141.45.11 with HTTP; Mon, 11 Aug 2008 08:37:18 -0700 (PDT) Message-ID: Date: Mon, 11 Aug 2008 23:37:18 +0800 From: chsoft@gmail.com To: "Lars Eggert" In-Reply-To: MIME-Version: 1.0 References: <489B498B.4040804@telecomitalia.it> <20080811143531.GA18911@net.t-labs.tu-berlin.de> Cc: "p2pi@ietf.org" Subject: Re: [p2pi] Information in an ALTO protocol X-BeenThere: p2pi@ietf.org X-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="===============1749180528==" Sender: p2pi-bounces@ietf.org Errors-To: p2pi-bounces@ietf.org --===============1749180528== Content-Type: multipart/alternative; boundary="----=_Part_92215_24378100.1218469039120" ------=_Part_92215_24378100.1218469039120 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline I think Vinay may mean the last-hop upload bandwidth for the local peer to select among candidates. The we can imagine two phases. At first phase ALTO may prefer to response with remote peers with larger nominal last-hop cap. Secondly, it leaves to the local peer to probe for the real available bandwidth among them and take the best scheduling for piece retrieval. Maybe it will drop some peers with low consumption upload bandwidth. On Mon, Aug 11, 2008 at 11:00 PM, Lars Eggert wrote: > Hi, > > On 2008-8-11, at 17:35, ext Vinay Aggarwal wrote: > >> I think an estimate of "last-hop bandwidth" can be an interesting metric >> of information for peer selection. >> It has been shown that selecting peers with high last-hop bandwidth lead >> to improvements in download performance. And this is information that is >> rather hard for peers to find out themselves. As far as I can see, it >> also satisfies all the bars set up by the ALTO service. >> > > Uplink or downlink bandwidth? > > Provisioned bandwidth (i.e., the nominal bandwidth a user is paying for) or > the currently available fraction of it? The latter would be something that I > doubt an ALTO box can have an accurate view of, since it changes on short > timescales. > > Could you share a reference to papers that show that that information is > beneficial? > > Thanks, > Lars > > _______________________________________________ > p2pi mailing list > p2pi@ietf.org > https://www.ietf.org/mailman/listinfo/p2pi > ------=_Part_92215_24378100.1218469039120 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline
I think Vinay may mean the last-hop upload bandwidth for the local peer to select among candidates.
The we can imagine two phases.
At first phase ALTO may prefer to response with remote peers with larger nominal last-hop cap.
Secondly, it leaves to the local peer to probe for the real available bandwidth among them and take the best scheduling for piece retrieval.
Maybe it will drop some peers with low consumption upload bandwidth.

On Mon, Aug 11, 2008 at 11:00 PM, Lars Eggert <lars.eggert@nokia.com> wrote:
Hi,


On 2008-8-11, at 17:35, ext Vinay Aggarwal wrote:
I think an estimate of "last-hop bandwidth" can be an interesting metric
of information for peer selection.
It has been shown that selecting peers with high last-hop bandwidth lead
to improvements in download performance. And this is information that is
rather hard for peers to find out themselves. As far as I can see, it
also satisfies all the bars set up by the ALTO service.

Uplink or downlink bandwidth?

Provisioned bandwidth (i.e., the nominal bandwidth a user is paying for) or the currently available fraction of it? The latter would be something that I doubt an ALTO box can have an accurate view of, since it changes on short timescales.

Could you share a reference to papers that show that that information is beneficial?

Thanks,
Lars

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

------=_Part_92215_24378100.1218469039120-- --===============1749180528== 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 --===============1749180528==-- From p2pi-bounces@ietf.org Mon Aug 11 09:17: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 E71383A6CC4; Mon, 11 Aug 2008 09:17: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 935AE3A6CB3 for ; Mon, 11 Aug 2008 09:17:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.137 X-Spam-Level: X-Spam-Status: No, score=0.137 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, J_CHICKENPOX_57=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kbngh4CUGtkO for ; Mon, 11 Aug 2008 09:17:28 -0700 (PDT) Received: from paoakoavas10.cable.comcast.com (paoakoavas10.cable.comcast.com [208.17.35.59]) by core3.amsl.com (Postfix) with ESMTP id 0A6E43A6359 for ; Mon, 11 Aug 2008 09:17:27 -0700 (PDT) Received: from ([24.40.15.92]) by paoakoavas10.cable.comcast.com with ESMTP id KP-TDCH7.49229543; Mon, 11 Aug 2008 12:17:14 -0400 Received: from PACDCEXCMB06.cable.comcast.com ([24.40.15.22]) by PACDCEXCSMTP03.cable.comcast.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 11 Aug 2008 12:17:14 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 11 Aug 2008 12:17:13 -0400 Message-ID: <74CCBBDF76102846AFA7B29F3A98D3F60107C32A@PACDCEXCMB06.cable.comcast.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [p2pi] After-BoF charter Thread-Index: Acj7ucKtNSsc6gg9S8CS3vNlE6rRPQAE/PLh From: "Woundy, Richard" To: , X-OriginalArrivalTime: 11 Aug 2008 16:17:14.0581 (UTC) FILETIME=[B7840850:01C8FBCD] Cc: lisa@osafoundation.org, p2pi@ietf.org Subject: Re: [p2pi] After-BoF charter X-BeenThere: p2pi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: P2P Infrastructure Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: p2pi-bounces@ietf.org Errors-To: p2pi-bounces@ietf.org >I believe you have just stated what is optimal for two providers, but I'm not convinced that the entire universe of providers agrees with you. I have to agree with Bruce. I still maintain that for Comcast, access costs are much more of interest than transit / cross-ISP traffic costs. But I have heard that the relative magnitude of costs could be different for other ISPs. Some examples I am aware of: - ISPs in geographies outside of North America / Europe / East Asia, due to relative scarcity of intercontinental/international fiber trunks. - Smaller ISPs, due to their smaller geographic footprint and lower traffic commitments, leading to higher transit costs. - Universities and other 'special case' ISPs, as Henning pointed out in an earlier email on costs. -- Rich ----- Original Message ----- From: p2pi-bounces@ietf.org To: Bob Briscoe Cc: p2pi@ietf.org ; Lisa Dusseault Sent: Mon Aug 11 09:51:48 2008 Subject: Re: [p2pi] After-BoF charter Good points Bob, most of which I agree with. A little clarification below: On Aug 8, 2008, at 8:40 PM, Bob Briscoe wrote: > Enrico, > > Charter generally looks good. > Generally agree with Lars, Dave's & Laird's responses so far. > My additional 3 penny's worth: > [snip] > > 3/ What does optimal mean, and what does better mean? > > The charter has hidden assumptions about what optimal is, and what > better is. From whose perspective? It needs to either say what > these assumptions are, or say that the w-g will define what optimal > means in a w-g document. I would suggest that there will be different views of optimal for different providers, and the WG should work on capturing that fact and developing solutions that can deal with it. > > As I have to keep saying, and as Richard Woundy from ComCast has > agreed, excessive cross domain traffic is much less bad than > excessive local traffic. I believe you have just stated what is optimal for two providers, but I'm not convinced that the entire universe of providers agrees with you. I think the WG needs to deal with the fact that some providers will care about reducing backhaul traffic and others will care about reducing inter-domain traffic. Rather than trying to get this all nailed down in the charter, I think it would be good if the charter mentioned the problem of defining optimality from a variety of perspectives as one of its work items. I also note that the charter is ultimately intended only to specify the interface between clients and "peer selection services" - so we need to make sure that the information carried across that interface is sufficiently rich to allow for a range of different definitions of optimality. We don't need to get everyone to buy into a single definition of optimality. The rest of your email below finds me in complete agreement. Bruce > > I agree that the /current/ traffic arrangement resulting from p2p > has excessive cross-domain traffic. But this is the not-seeing- > beyond-the-first-step problem I tried to explain at the mic in the > ALTO BoF. > > Once traffic is sitting in an optimum arrangement (possibly > bootstrapped by ALTO then optimised by e2e congestion control), the > best place to add the /next/ connection will likely be cross-domain > not local. Because the optimium is a /balance/ of light congestion > across both. This is why the goal MUST NOT be unconditional > localisation. That could eventually drive the network /beyond/ the > balance, persistently trying to drive up congestion in the access > and backhaul. That will be much worse than excessive cross-domain > traffic. > > You might say it would be nice to have that problem. > > But if this service only does localisation, it will only be safe / > if/ it is used by a minority. If the popularity of an ALTO service > goes beyond a certain point, it will start to kill the ISP's local > network. Of course, then less people will use it and an equilibrium > might be reached. But that's what I said. Optimisation is a > process, not just a first step. ALTO has to be able to move traffic > out, not just in. > > \ > \ > \ /\ > \ / \ ^----- <<<---goal > \ / V > \/ > > NOT > \ > \ > \ > \ <<<---goal > \ > \ > \ > \ > \ > \ > > > Bob > > At 20:06 07/08/2008, Enrico Marocco wrote: >> We have tried to collect all comments received during the meeting, in >> mailing list and hallway discussions. The new version of the charter, >> available as always at http://alto.tilab.com/docs/charter.txt, should >> reflect at least some of them. Please take a look and comment. >> Feel free >> to say if you don't like it -- entirely or partially -- and why; >> or if >> you like it. And why. >> >> Major changes include: >> + terminology: dropped terms like "the oracle" and "best peer"; >> + scope: removed cache/TURN/whatever service discovery; >> + path selection: stressed the importance of routing preferences and >> peering policies; >> + forbidden third-party queries; >> + mentioned IRTF for analysis on more sophisticated metrics. >> >> The current version of the charter is also more explicit about what >> pieces of information will be provided by an ALTO service; I'll >> start a >> separate thread specifically for this discussion. >> >> -- >> Ciao, >> Enrico >> >> >> _______________________________________________ >> p2pi mailing list >> p2pi@ietf.org >> https://www.ietf.org/mailman/listinfo/p2pi > > ______________________________________________________________________ > ______ > Bob Briscoe, Networks Research Centre, BT > Research > B54/77 Adastral Park,Martlesham Heath,Ipswich,IP5 3RE,UK. +44 > 1473 645196 > _______________________________________________ > p2pi mailing list > p2pi@ietf.org > https://www.ietf.org/mailman/listinfo/p2pi _______________________________________________ p2pi mailing list p2pi@ietf.org https://www.ietf.org/mailman/listinfo/p2pi _______________________________________________ p2pi mailing list p2pi@ietf.org https://www.ietf.org/mailman/listinfo/p2pi From p2pi-bounces@ietf.org Mon Aug 11 09:55: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 6BAC63A6D70; Mon, 11 Aug 2008 09:55: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 A04A73A6D70 for ; Mon, 11 Aug 2008 09:55:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.949 X-Spam-Level: X-Spam-Status: No, score=-0.949 tagged_above=-999 required=5 tests=[AWL=1.300, BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DhQ3Pvula6qn for ; Mon, 11 Aug 2008 09:55:04 -0700 (PDT) Received: from mail.net.t-labs.tu-berlin.de (mail.net.t-labs.tu-berlin.de [130.149.220.252]) by core3.amsl.com (Postfix) with ESMTP id 1BA5A3A6D65 for ; Mon, 11 Aug 2008 09:55:04 -0700 (PDT) Received: from crow.net.t-labs.tu-berlin.de (crow.net.t-labs.tu-berlin.de [130.149.220.17]) by mail.net.t-labs.tu-berlin.de (Postfix) with ESMTP id CF67E705D0A4; Mon, 11 Aug 2008 18:54:43 +0200 (CEST) Received: by crow.net.t-labs.tu-berlin.de (Postfix, from userid 10007) id 9B3D64008D97; Mon, 11 Aug 2008 18:54:43 +0200 (CEST) Date: Mon, 11 Aug 2008 18:54:43 +0200 From: Vinay Aggarwal To: chsoft@gmail.com Message-ID: <20080811165443.GB18911@net.t-labs.tu-berlin.de> References: <489B498B.4040804@telecomitalia.it> <20080811143531.GA18911@net.t-labs.tu-berlin.de> Mime-Version: 1.0 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.11 Cc: "p2pi@ietf.org" Subject: Re: [p2pi] Information in an ALTO protocol X-BeenThere: p2pi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: P2P Infrastructure Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: 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, regarding bandwidth information, here is a paper that shows that taking last-hop bandwidth into account helps to improve the download performance of peers. In fact, bandwidth comes out to be the significant factor to improve download times. Vinay Aggarwal, Obi Akonjang, Anja Feldmann. Improving User and ISP Experience through ISP-aided P2P Locality. In Proceedings of 11th IEEE Global Internet Symposium 2008 (GI'08) The paper (and other related papers) are available at: http://www.net.t-labs.tu-berlin.de/research/isp-p2p/ It would make sense to provide information about the "uplink" bandwidth, as that is much smaller than "downlink" bandwidth, atleast in case of DSL, and is thus a limiting factor. The ALTO can consider the uplink bandwidth of peers, and use it in combination with geographic or parent AS information to sort the peers. I agree that some ISPs prefer to keep traffic within their network, while other ISPs would sometimes welcome traffic going to other ISPs. This is especially true for large ISPs, who get paid for traffic flowing to other networks, typically their customers. Depending on the circumstances, an ISP can prefer peers either with large uplink or those within its network, or better still, both! Important is that the user should experience improved performance. IMHO, considering just the actual uplink bandwidth will help a great deal. While estimating the currently "available" bandwidth would be still better, that is a lot harder to achieve. But if that is reasonably possible to do for the ALTO server, that is a much better alternative than having the peer probing for the real available bandwidth and picking the best one. Vinay. On Mon, Aug 11, 2008 at 11:37:18PM +0800, chsoft@gmail.com wrote: > I think Vinay may mean the last-hop upload bandwidth for the local peer to > select among candidates. > The we can imagine two phases. > At first phase ALTO may prefer to response with remote peers with larger > nominal last-hop cap. > Secondly, it leaves to the local peer to probe for the real available > bandwidth among them and take the best scheduling for piece retrieval. > Maybe it will drop some peers with low consumption upload bandwidth. > > On Mon, Aug 11, 2008 at 11:00 PM, Lars Eggert wrote: > > > Hi, > > > > On 2008-8-11, at 17:35, ext Vinay Aggarwal wrote: > > > >> I think an estimate of "last-hop bandwidth" can be an interesting metric > >> of information for peer selection. > >> It has been shown that selecting peers with high last-hop bandwidth lead > >> to improvements in download performance. And this is information that is > >> rather hard for peers to find out themselves. As far as I can see, it > >> also satisfies all the bars set up by the ALTO service. > >> > > > > Uplink or downlink bandwidth? > > > > Provisioned bandwidth (i.e., the nominal bandwidth a user is paying for) or > > the currently available fraction of it? The latter would be something that I > > doubt an ALTO box can have an accurate view of, since it changes on short > > timescales. > > > > Could you share a reference to papers that show that that information is > > beneficial? > > > > Thanks, > > 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 Mon Aug 11 15: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 2C0703A6CEB; Mon, 11 Aug 2008 15: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 99CA53A6CE3 for ; Mon, 11 Aug 2008 15:18:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gCWX6oGGf0Eb for ; Mon, 11 Aug 2008 15:18:53 -0700 (PDT) Received: from ihemail2.lucent.com (ihemail2.lucent.com [135.245.0.35]) by core3.amsl.com (Postfix) with ESMTP id A72CE3A6CDA for ; Mon, 11 Aug 2008 15:18:52 -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 m7BMIrEd000484 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 11 Aug 2008 17:18:53 -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 m7BMIlgv024732 for ; Mon, 11 Aug 2008 17:18:47 -0500 (CDT) Message-ID: <48A0BACC.5000507@alcatel-lucent.com> Date: Mon, 11 Aug 2008 17:18: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: "p2pi@ietf.org" X-Scanned-By: MIMEDefang 2.57 on 135.245.2.35 Subject: [p2pi] Meeting minutes uploaded X-BeenThere: p2pi@ietf.org 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 The 72nd IETF ALTO BoF session minutes have been uploaded. They are available at: http://www.ietf.org/proceedings/08jul/minutes/alto.txt A note of thanks to Jan Seedorf and Robert Sparks for taking detailed notes from which the published minutes referenced above have been distilled. Cheers, - 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 Aug 11 18:17: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 813F53A6CAE; Mon, 11 Aug 2008 18:17: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 3A8903A6E2B for ; Mon, 11 Aug 2008 18:17:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.11 X-Spam-Level: X-Spam-Status: No, score=-1.11 tagged_above=-999 required=5 tests=[BAYES_05=-1.11] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t7Z9CLkT1Irz for ; Mon, 11 Aug 2008 18:17:03 -0700 (PDT) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.227]) by core3.amsl.com (Postfix) with ESMTP id 6C7593A6889 for ; Mon, 11 Aug 2008 18:16:45 -0700 (PDT) Received: by rv-out-0506.google.com with SMTP id b25so2084926rvf.49 for ; Mon, 11 Aug 2008 18:16:46 -0700 (PDT) Received: by 10.140.127.13 with SMTP id z13mr3951014rvc.194.1218503806451; Mon, 11 Aug 2008 18:16:46 -0700 (PDT) Received: from ?10.0.1.234? ( [208.72.192.23]) by mx.google.com with ESMTPS id f21sm7031405rvb.0.2008.08.11.18.16.45 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 11 Aug 2008 18:16:45 -0700 (PDT) Message-Id: <119D7BAE-4CBB-4BCE-BB3C-594FC6234AB6@shlang.com> From: Stanislav Shalunov To: Vinay Aggarwal In-Reply-To: <20080811143531.GA18911@net.t-labs.tu-berlin.de> Mime-Version: 1.0 (Apple Message framework v926) Date: Mon, 11 Aug 2008 18:16:44 -0700 References: <489B498B.4040804@telecomitalia.it> <20080811143531.GA18911@net.t-labs.tu-berlin.de> X-Mailer: Apple Mail (2.926) Cc: p2pi@ietf.org Subject: Re: [p2pi] Information in an ALTO protocol X-BeenThere: p2pi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: P2P Infrastructure Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: p2pi-bounces@ietf.org Errors-To: p2pi-bounces@ietf.org This might be workable and interesting, but here are a few concerns: 1. For this to be useful, an ISP would need to provide an unobfuscated third-party service that will tell the world what service plan I bought. As a user, I'd have a bit of discomfort with it, but the ISP would probably be a lot more concerned about telling its competitors the fraction of its customers whom they upsold on a premium plan. I suspect this might be a real show-stopper. 2. Nominal provisioned bandwidth on DSL is only an upper bound for the actual negotiated bandwidth. The negotiation takes a few seconds after the modem starts and routinely results in lower-than-nominal rates for longer distances to CO. 3. While it's obvious that an individual peer will, in the current world, do better trading with fat-uplink partners, I'm skeptical of possibility of substantial increases in swarm throughput, which determines the average outcome. Consider the measure of swarm efficiency: total transfer rate divided by total upload capacity. I posit that swarm efficiency is usually quite high, and the only real slack is on super-fast peers in colos and such. Home connection uplinks are so narrow that it does not take much to saturate them. -- Stas On Aug 11, 2008, at 7:35 AM, Vinay Aggarwal wrote: > Hello, > > Regarding what information the ALTO service can provide: > > I think an estimate of "last-hop bandwidth" can be an interesting > metric > of information for peer selection. > It has been shown that selecting peers with high last-hop bandwidth > lead > to improvements in download performance. And this is information > that is > rather hard for peers to find out themselves. As far as I can see, it > also satisfies all the bars set up by the ALTO service. > > Any thoughts? > > Thanks, > Vinay. > > ----------------- > Vinay Aggarwal > Deutsche Telekom > Germany. > > > On Thu, Aug 07, 2008 at 09:14:19PM +0200, Enrico Marocco wrote: >> As some people suggested, it may be useful to try to understand what >> kind of information will be provided by an ALTO service. >> >> Current version of the charter lists four pieces of information: >> + routing preferences and priority values. The network operator is >> usually the only entity in possession of such information, but it is >> in its interests to share at least part of it with applications, in >> order to reduce traffic on critical links. On the other hand, if >> following such preferences leads to better-than-random choices, it >> is >> also in applications' interest to follow them; >> + AS numbers and approximate geographic locations. Such information >> is >> today (partially) available and, in fact, is in some cases already >> used for peer selection. However, since there is no standard way to >> obtain it, it is not easy for applications to switch from an >> information provider to another. >> >> The charter does not preclude any other kind of information entirely, >> but it sets the bar pretty high, requiring that: >> >> When the WG considers standardizing schemas, measures or other >> information that the ALTO service could provide, the following >> criteria are important to ensure real feasibility. >> - Can an ALTO service technically provide that information? >> - Is the ALTO service willing to obtain and divulge that >> information? >> - Is it information that some client will find useful? >> - Can that client get that information without excessive privacy >> concerns (e.g. by sending large lists of peers)? >> - Is it information that clients cannot find easily some other way? >> >> Thoughts? >> >> -- >> 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 -- Stanislav Shalunov _______________________________________________ p2pi mailing list p2pi@ietf.org https://www.ietf.org/mailman/listinfo/p2pi From p2pi-bounces@ietf.org Mon Aug 11 18:55: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 16C263A6CAE; Mon, 11 Aug 2008 18:55: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 450033A6CAE for ; Mon, 11 Aug 2008 18:55:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.554 X-Spam-Level: X-Spam-Status: No, score=-1.554 tagged_above=-999 required=5 tests=[AWL=0.445, BAYES_00=-2.599, J_CHICKENPOX_57=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nv5-YFM7uKbQ for ; Mon, 11 Aug 2008 18:55:34 -0700 (PDT) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.227]) by core3.amsl.com (Postfix) with ESMTP id 321163A6A56 for ; Mon, 11 Aug 2008 18:55:34 -0700 (PDT) Received: by rv-out-0506.google.com with SMTP id b25so2096279rvf.49 for ; Mon, 11 Aug 2008 18:54:56 -0700 (PDT) Received: by 10.140.185.1 with SMTP id i1mr3962409rvf.264.1218506096467; Mon, 11 Aug 2008 18:54:56 -0700 (PDT) Received: from ?10.0.1.234? ( [208.72.192.23]) by mx.google.com with ESMTPS id k2sm10013717rvb.4.2008.08.11.18.54.55 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 11 Aug 2008 18:54:56 -0700 (PDT) Message-Id: <4B3D810E-7CC1-4D89-B0AF-FA49E3D772BB@shlang.com> From: Stanislav Shalunov To: Bruce Davie In-Reply-To: Mime-Version: 1.0 (Apple Message framework v926) Date: Mon, 11 Aug 2008 18:54:54 -0700 References: <489B47A0.1050507@telecomitalia.it> <200808090040.m790eK78029921@bagheera.jungle.bt.co.uk> X-Mailer: Apple Mail (2.926) Cc: Lisa Dusseault , "p2pi@ietf.org" Subject: Re: [p2pi] After-BoF charter X-BeenThere: p2pi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: P2P Infrastructure Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: p2pi-bounces@ietf.org Errors-To: p2pi-bounces@ietf.org This is quite obvious, but I thought it might be worth stating in the context of this discussion: As an ISP, you can't put up a server that answers short questions with short answers or publish some information for the public or your customers and expect the amount of upload P2P capacity used by your customers to drop much below the amount of download P2P capacity. Every downloaded bit is someone's uploaded bit. For the swarm, the upload/download ratio is always 1. You can try to encourage your customers to be leeches, but that doesn't work too well, because then their download rates go down as they are chocked or snubbed by more and more people. The only way to break the 1:1 ratio is by introducing caches. While this consideration is important to keep in mind to be realistic about possible outcomes of ALTO, I agree with all the posters that that goal of ALTO should not be unconditional localization but a more general mechanism for expressing network routing preferences to the application. -- Stas On Aug 11, 2008, at 6:51 AM, Bruce Davie wrote: > Good points Bob, most of which I agree with. A little clarification > below: > > On Aug 8, 2008, at 8:40 PM, Bob Briscoe wrote: > >> Enrico, >> >> Charter generally looks good. >> Generally agree with Lars, Dave's & Laird's responses so far. >> My additional 3 penny's worth: >> > [snip] > >> >> 3/ What does optimal mean, and what does better mean? >> >> The charter has hidden assumptions about what optimal is, and what >> better is. From whose perspective? It needs to either say what >> these assumptions are, or say that the w-g will define what optimal >> means in a w-g document. > > I would suggest that there will be different views of optimal for > different providers, and the WG should work on capturing that fact > and developing solutions that can deal with it. > >> >> As I have to keep saying, and as Richard Woundy from ComCast has >> agreed, excessive cross domain traffic is much less bad than >> excessive local traffic. > > I believe you have just stated what is optimal for two providers, > but I'm not convinced that the entire universe of providers agrees > with you. I think the WG needs to deal with the fact that some > providers will care about reducing backhaul traffic and others will > care about reducing inter-domain traffic. > > Rather than trying to get this all nailed down in the charter, I > think it would be good if the charter mentioned the problem of > defining optimality from a variety of perspectives as one of its > work items. > > I also note that the charter is ultimately intended only to specify > the interface between clients and "peer selection services" - so we > need to make sure that the information carried across that interface > is sufficiently rich to allow for a range of different definitions > of optimality. We don't need to get everyone to buy into a single > definition of optimality. > > The rest of your email below finds me in complete agreement. > > Bruce > >> >> I agree that the /current/ traffic arrangement resulting from p2p >> has excessive cross-domain traffic. But this is the not-seeing- >> beyond-the-first-step problem I tried to explain at the mic in the >> ALTO BoF. >> >> Once traffic is sitting in an optimum arrangement (possibly >> bootstrapped by ALTO then optimised by e2e congestion control), the >> best place to add the /next/ connection will likely be cross-domain >> not local. Because the optimium is a /balance/ of light congestion >> across both. This is why the goal MUST NOT be unconditional >> localisation. That could eventually drive the network /beyond/ the >> balance, persistently trying to drive up congestion in the access >> and backhaul. That will be much worse than excessive cross-domain >> traffic. >> >> You might say it would be nice to have that problem. >> >> But if this service only does localisation, it will only be safe / >> if/ it is used by a minority. If the popularity of an ALTO service >> goes beyond a certain point, it will start to kill the ISP's local >> network. Of course, then less people will use it and an equilibrium >> might be reached. But that's what I said. Optimisation is a >> process, not just a first step. ALTO has to be able to move traffic >> out, not just in. >> >> \ >> \ >> \ /\ >> \ / \ ^----- <<<---goal >> \ / V >> \/ >> >> NOT >> \ >> \ >> \ >> \ <<<---goal >> \ >> \ >> \ >> \ >> \ >> \ >> >> >> Bob >> >> At 20:06 07/08/2008, Enrico Marocco wrote: >>> We have tried to collect all comments received during the meeting, >>> in >>> mailing list and hallway discussions. The new version of the >>> charter, >>> available as always at http://alto.tilab.com/docs/charter.txt, >>> should >>> reflect at least some of them. Please take a look and comment. >>> Feel free >>> to say if you don't like it -- entirely or partially -- and why; >>> or if >>> you like it. And why. >>> >>> Major changes include: >>> + terminology: dropped terms like "the oracle" and "best peer"; >>> + scope: removed cache/TURN/whatever service discovery; >>> + path selection: stressed the importance of routing preferences and >>> peering policies; >>> + forbidden third-party queries; >>> + mentioned IRTF for analysis on more sophisticated metrics. >>> >>> The current version of the charter is also more explicit about what >>> pieces of information will be provided by an ALTO service; I'll >>> start a >>> separate thread specifically for this discussion. >>> >>> -- >>> Ciao, >>> Enrico >>> >>> >>> _______________________________________________ >>> p2pi mailing list >>> p2pi@ietf.org >>> https://www.ietf.org/mailman/listinfo/p2pi >> >> ____________________________________________________________________________ >> Bob Briscoe, Networks Research Centre, BT >> Research >> B54/77 Adastral Park,Martlesham Heath,Ipswich,IP5 3RE,UK. +44 >> 1473 645196 >> _______________________________________________ >> p2pi mailing list >> p2pi@ietf.org >> https://www.ietf.org/mailman/listinfo/p2pi > > _______________________________________________ > p2pi mailing list > p2pi@ietf.org > https://www.ietf.org/mailman/listinfo/p2pi -- Stanislav Shalunov _______________________________________________ p2pi mailing list p2pi@ietf.org https://www.ietf.org/mailman/listinfo/p2pi From p2pi-bounces@ietf.org Tue Aug 12 02:03: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 554313A69B6; Tue, 12 Aug 2008 02:03: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 DB5F33A69B6 for ; Tue, 12 Aug 2008 02:03:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.867 X-Spam-Level: X-Spam-Status: No, score=-0.867 tagged_above=-999 required=5 tests=[AWL=0.650, BAYES_00=-2.599, DNS_FROM_RFC_BOGUSMX=1.482, J_CHICKENPOX_57=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0EC-e92Ih7lq for ; Tue, 12 Aug 2008 02:03:01 -0700 (PDT) Received: from smtp4.smtp.bt.com (smtp4.smtp.bt.com [217.32.164.151]) by core3.amsl.com (Postfix) with ESMTP id 100713A6937 for ; Tue, 12 Aug 2008 02:03:00 -0700 (PDT) Received: from i2kc06-ukbr.domain1.systemhost.net ([193.113.197.70]) by smtp4.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 12 Aug 2008 10:01:55 +0100 Received: from cbibipnt05.iuser.iroot.adidom.com ([147.149.196.177]) by i2kc06-ukbr.domain1.systemhost.net with Microsoft SMTPSVC(6.0.3790.1830); Tue, 12 Aug 2008 10:01:55 +0100 Received: From bagheera.jungle.bt.co.uk ([132.146.168.158]) by cbibipnt05.iuser.iroot.adidom.com (WebShield SMTP v4.5 MR1a P0803.399); id 1218531713972; Tue, 12 Aug 2008 10:01:53 +0100 Received: from mut.jungle.bt.co.uk ([10.215.130.87]) by bagheera.jungle.bt.co.uk (8.13.5/8.12.8) with ESMTP id m7C91q6H012752; Tue, 12 Aug 2008 10:01:52 +0100 Message-Id: <200808120901.m7C91q6H012752@bagheera.jungle.bt.co.uk> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Tue, 12 Aug 2008 10:01:58 +0100 To: "Woundy, Richard" From: Bob Briscoe In-Reply-To: <74CCBBDF76102846AFA7B29F3A98D3F60107C32A@PACDCEXCMB06.cabl e.comcast.com> References: <74CCBBDF76102846AFA7B29F3A98D3F60107C32A@PACDCEXCMB06.cable.comcast.com> Mime-Version: 1.0 X-Scanned-By: MIMEDefang 2.56 on 132.146.168.158 X-OriginalArrivalTime: 12 Aug 2008 09:01:55.0065 (UTC) FILETIME=[117BEE90:01C8FC5A] Cc: lisa@osafoundation.org, p2pi@ietf.org Subject: Re: [p2pi] After-BoF charter X-BeenThere: p2pi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: P2P Infrastructure Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: p2pi-bounces@ietf.org Errors-To: p2pi-bounces@ietf.org Richard, Bruce, Laird & all, Yes, of course, I agree with you all. I shouldn't have said the w-g should define what optimality means. I didn't mean that, sorry. Indeed, I originally gave counter-examples of NZ & Oz where localisation would be more important than reducing cross-domain. But I /did/ mean that the w-g should document what different parties might reasonably want optimality to mean. I want the charter to acknowledge the same old point I started with at the mic and on the list: - that unconditional localisation will not be sufficient for /any/ ISP, so the parameters that the ALTO service will have to gather are more than just the static ones: topology and policies - To avoid this being inconsistent with the other rule about not using fast changing metrics like congestion, we have to say congestion will have to be taken into account, but only long term averages in time, and probably across broad groups of paths. The first thing you teach a learner driver is how to stop. Then you teach them how to start. Similarly, before you start moving traffic in one direction, you also have to know /when/ to stop and /how/ to move it back in the other direction. Bob At 17:17 11/08/2008, Woundy, Richard wrote: > >I believe you have just stated what is optimal for two providers, > but I'm not convinced that the entire universe of providers agrees with you. > >I have to agree with Bruce. I still maintain that for Comcast, >access costs are much more of interest than transit / cross-ISP >traffic costs. But I have heard that the relative magnitude of costs >could be different for other ISPs. > >Some examples I am aware of: >- ISPs in geographies outside of North America / Europe / East Asia, >due to relative scarcity of intercontinental/international fiber trunks. >- Smaller ISPs, due to their smaller geographic footprint and lower >traffic commitments, leading to higher transit costs. >- Universities and other 'special case' ISPs, as Henning pointed out >in an earlier email on costs. > >-- Rich > > >----- Original Message ----- >From: p2pi-bounces@ietf.org >To: Bob Briscoe >Cc: p2pi@ietf.org ; Lisa Dusseault >Sent: Mon Aug 11 09:51:48 2008 >Subject: Re: [p2pi] After-BoF charter > >Good points Bob, most of which I agree with. A little clarification >below: > >On Aug 8, 2008, at 8:40 PM, Bob Briscoe wrote: > > > Enrico, > > > > Charter generally looks good. > > Generally agree with Lars, Dave's & Laird's responses so far. > > My additional 3 penny's worth: > > >[snip] > > > > > 3/ What does optimal mean, and what does better mean? > > > > The charter has hidden assumptions about what optimal is, and what > > better is. From whose perspective? It needs to either say what > > these assumptions are, or say that the w-g will define what optimal > > means in a w-g document. > >I would suggest that there will be different views of optimal for >different providers, and the WG should work on capturing that fact >and developing solutions that can deal with it. > > > > > As I have to keep saying, and as Richard Woundy from ComCast has > > agreed, excessive cross domain traffic is much less bad than > > excessive local traffic. > >I believe you have just stated what is optimal for two providers, but >I'm not convinced that the entire universe of providers agrees with >you. I think the WG needs to deal with the fact that some providers >will care about reducing backhaul traffic and others will care about >reducing inter-domain traffic. > >Rather than trying to get this all nailed down in the charter, I >think it would be good if the charter mentioned the problem of >defining optimality from a variety of perspectives as one of its work >items. > >I also note that the charter is ultimately intended only to specify >the interface between clients and "peer selection services" - so we >need to make sure that the information carried across that interface >is sufficiently rich to allow for a range of different definitions of >optimality. We don't need to get everyone to buy into a single >definition of optimality. > >The rest of your email below finds me in complete agreement. > >Bruce > > > > > I agree that the /current/ traffic arrangement resulting from p2p > > has excessive cross-domain traffic. But this is the not-seeing- > > beyond-the-first-step problem I tried to explain at the mic in the > > ALTO BoF. > > > > Once traffic is sitting in an optimum arrangement (possibly > > bootstrapped by ALTO then optimised by e2e congestion control), the > > best place to add the /next/ connection will likely be cross-domain > > not local. Because the optimium is a /balance/ of light congestion > > across both. This is why the goal MUST NOT be unconditional > > localisation. That could eventually drive the network /beyond/ the > > balance, persistently trying to drive up congestion in the access > > and backhaul. That will be much worse than excessive cross-domain > > traffic. > > > > You might say it would be nice to have that problem. > > > > But if this service only does localisation, it will only be safe / > > if/ it is used by a minority. If the popularity of an ALTO service > > goes beyond a certain point, it will start to kill the ISP's local > > network. Of course, then less people will use it and an equilibrium > > might be reached. But that's what I said. Optimisation is a > > process, not just a first step. ALTO has to be able to move traffic > > out, not just in. > > > > \ > > \ > > \ /\ > > \ / \ ^----- <<<---goal > > \ / V > > \/ > > > > NOT > > \ > > \ > > \ > > \ <<<---goal > > \ > > \ > > \ > > \ > > \ > > \ > > > > > > Bob > > > > At 20:06 07/08/2008, Enrico Marocco wrote: > >> We have tried to collect all comments received during the meeting, in > >> mailing list and hallway discussions. The new version of the charter, > >> available as always at http://alto.tilab.com/docs/charter.txt, should > >> reflect at least some of them. Please take a look and comment. > >> Feel free > >> to say if you don't like it -- entirely or partially -- and why; > >> or if > >> you like it. And why. > >> > >> Major changes include: > >> + terminology: dropped terms like "the oracle" and "best peer"; > >> + scope: removed cache/TURN/whatever service discovery; > >> + path selection: stressed the importance of routing preferences and > >> peering policies; > >> + forbidden third-party queries; > >> + mentioned IRTF for analysis on more sophisticated metrics. > >> > >> The current version of the charter is also more explicit about what > >> pieces of information will be provided by an ALTO service; I'll > >> start a > >> separate thread specifically for this discussion. > >> > >> -- > >> Ciao, > >> Enrico > >> > >> > >> _______________________________________________ > >> p2pi mailing list > >> p2pi@ietf.org > >> https://www.ietf.org/mailman/listinfo/p2pi > > > > ______________________________________________________________________ > > ______ > > Bob Briscoe, Networks Research Centre, BT > > Research > > B54/77 Adastral Park,Martlesham Heath,Ipswich,IP5 3RE,UK. +44 > > 1473 645196 > > _______________________________________________ > > p2pi mailing list > > p2pi@ietf.org > > https://www.ietf.org/mailman/listinfo/p2pi > >_______________________________________________ >p2pi mailing list >p2pi@ietf.org >https://www.ietf.org/mailman/listinfo/p2pi ____________________________________________________________________________ Bob Briscoe, Networks Research Centre, BT Research B54/77 Adastral Park,Martlesham Heath,Ipswich,IP5 3RE,UK. +44 1473 645196 _______________________________________________ p2pi mailing list p2pi@ietf.org https://www.ietf.org/mailman/listinfo/p2pi From p2pi-bounces@ietf.org Tue Aug 12 03:18: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 420133A6A5B; Tue, 12 Aug 2008 03:18: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 9F1263A69ED for ; Tue, 12 Aug 2008 03:18:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.865 X-Spam-Level: X-Spam-Status: No, score=-9.865 tagged_above=-999 required=5 tests=[AWL=-0.200, BAYES_00=-2.599, HABEAS_ACCREDITED_COI=-8, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_57=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HfkRBNloipjI for ; Tue, 12 Aug 2008 03:18:11 -0700 (PDT) Received: from dkny.pando.com (dkny.pando.com [67.99.55.163]) by core3.amsl.com (Postfix) with ESMTP id 2E5343A6A28 for ; Tue, 12 Aug 2008 03:18:11 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by dkny.pando.com (Postfix) with ESMTP id 9A6B3E10A03; Tue, 12 Aug 2008 06:16:33 -0400 (EDT) X-Virus-Scanned: amavisd-new at Received: from dkny.pando.com ([127.0.0.1]) by localhost (dkny.pando.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NEx40qS8WkAe; Tue, 12 Aug 2008 06:16:26 -0400 (EDT) Received: from dkny.pando.com (dkny.pando.com [10.10.60.11]) by dkny.pando.com (Postfix) with ESMTP id 1724AE10B4C; Tue, 12 Aug 2008 06:16:26 -0400 (EDT) Date: Tue, 12 Aug 2008 06:16:26 -0400 (EDT) From: Laird Popkin To: Bob Briscoe Message-ID: <1448753199.141981218536186065.JavaMail.root@dkny.pando.com> In-Reply-To: <200808120901.m7C91q6H012752@bagheera.jungle.bt.co.uk> MIME-Version: 1.0 X-Originating-IP: [71.187.207.81] Cc: Richard Woundy , lisa@osafoundation.org, p2pi@ietf.org Subject: Re: [p2pi] After-BoF charter X-BeenThere: p2pi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: P2P Infrastructure Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: p2pi-bounces@ietf.org Errors-To: p2pi-bounces@ietf.org I'm in violent agreement. :-) - Laird Popkin, CTO, Pando Networks mobile: 646/465-0570 ----- Original Message ----- From: "Bob Briscoe" To: "Richard Woundy" Cc: lisa@osafoundation.org, p2pi@ietf.org Sent: Tuesday, August 12, 2008 5:01:58 AM (GMT-0500) America/New_York Subject: Re: [p2pi] After-BoF charter Richard, Bruce, Laird & all, Yes, of course, I agree with you all. I shouldn't have said the w-g should define what optimality means. I didn't mean that, sorry. Indeed, I originally gave counter-examples of NZ & Oz where localisation would be more important than reducing cross-domain. But I /did/ mean that the w-g should document what different parties might reasonably want optimality to mean. I want the charter to acknowledge the same old point I started with at the mic and on the list: - that unconditional localisation will not be sufficient for /any/ ISP, so the parameters that the ALTO service will have to gather are more than just the static ones: topology and policies - To avoid this being inconsistent with the other rule about not using fast changing metrics like congestion, we have to say congestion will have to be taken into account, but only long term averages in time, and probably across broad groups of paths. The first thing you teach a learner driver is how to stop. Then you teach them how to start. Similarly, before you start moving traffic in one direction, you also have to know /when/ to stop and /how/ to move it back in the other direction. Bob At 17:17 11/08/2008, Woundy, Richard wrote: > >I believe you have just stated what is optimal for two providers, > but I'm not convinced that the entire universe of providers agrees with you. > >I have to agree with Bruce. I still maintain that for Comcast, >access costs are much more of interest than transit / cross-ISP >traffic costs. But I have heard that the relative magnitude of costs >could be different for other ISPs. > >Some examples I am aware of: >- ISPs in geographies outside of North America / Europe / East Asia, >due to relative scarcity of intercontinental/international fiber trunks. >- Smaller ISPs, due to their smaller geographic footprint and lower >traffic commitments, leading to higher transit costs. >- Universities and other 'special case' ISPs, as Henning pointed out >in an earlier email on costs. > >-- Rich > > >----- Original Message ----- >From: p2pi-bounces@ietf.org >To: Bob Briscoe >Cc: p2pi@ietf.org ; Lisa Dusseault >Sent: Mon Aug 11 09:51:48 2008 >Subject: Re: [p2pi] After-BoF charter > >Good points Bob, most of which I agree with. A little clarification >below: > >On Aug 8, 2008, at 8:40 PM, Bob Briscoe wrote: > > > Enrico, > > > > Charter generally looks good. > > Generally agree with Lars, Dave's & Laird's responses so far. > > My additional 3 penny's worth: > > >[snip] > > > > > 3/ What does optimal mean, and what does better mean? > > > > The charter has hidden assumptions about what optimal is, and what > > better is. From whose perspective? It needs to either say what > > these assumptions are, or say that the w-g will define what optimal > > means in a w-g document. > >I would suggest that there will be different views of optimal for >different providers, and the WG should work on capturing that fact >and developing solutions that can deal with it. > > > > > As I have to keep saying, and as Richard Woundy from ComCast has > > agreed, excessive cross domain traffic is much less bad than > > excessive local traffic. > >I believe you have just stated what is optimal for two providers, but >I'm not convinced that the entire universe of providers agrees with >you. I think the WG needs to deal with the fact that some providers >will care about reducing backhaul traffic and others will care about >reducing inter-domain traffic. > >Rather than trying to get this all nailed down in the charter, I >think it would be good if the charter mentioned the problem of >defining optimality from a variety of perspectives as one of its work >items. > >I also note that the charter is ultimately intended only to specify >the interface between clients and "peer selection services" - so we >need to make sure that the information carried across that interface >is sufficiently rich to allow for a range of different definitions of >optimality. We don't need to get everyone to buy into a single >definition of optimality. > >The rest of your email below finds me in complete agreement. > >Bruce > > > > > I agree that the /current/ traffic arrangement resulting from p2p > > has excessive cross-domain traffic. But this is the not-seeing- > > beyond-the-first-step problem I tried to explain at the mic in the > > ALTO BoF. > > > > Once traffic is sitting in an optimum arrangement (possibly > > bootstrapped by ALTO then optimised by e2e congestion control), the > > best place to add the /next/ connection will likely be cross-domain > > not local. Because the optimium is a /balance/ of light congestion > > across both. This is why the goal MUST NOT be unconditional > > localisation. That could eventually drive the network /beyond/ the > > balance, persistently trying to drive up congestion in the access > > and backhaul. That will be much worse than excessive cross-domain > > traffic. > > > > You might say it would be nice to have that problem. > > > > But if this service only does localisation, it will only be safe / > > if/ it is used by a minority. If the popularity of an ALTO service > > goes beyond a certain point, it will start to kill the ISP's local > > network. Of course, then less people will use it and an equilibrium > > might be reached. But that's what I said. Optimisation is a > > process, not just a first step. ALTO has to be able to move traffic > > out, not just in. > > > > \ > > \ > > \ /\ > > \ / \ ^----- <<<---goal > > \ / V > > \/ > > > > NOT > > \ > > \ > > \ > > \ <<<---goal > > \ > > \ > > \ > > \ > > \ > > \ > > > > > > Bob > > > > At 20:06 07/08/2008, Enrico Marocco wrote: > >> We have tried to collect all comments received during the meeting, in > >> mailing list and hallway discussions. The new version of the charter, > >> available as always at http://alto.tilab.com/docs/charter.txt, should > >> reflect at least some of them. Please take a look and comment. > >> Feel free > >> to say if you don't like it -- entirely or partially -- and why; > >> or if > >> you like it. And why. > >> > >> Major changes include: > >> + terminology: dropped terms like "the oracle" and "best peer"; > >> + scope: removed cache/TURN/whatever service discovery; > >> + path selection: stressed the importance of routing preferences and > >> peering policies; > >> + forbidden third-party queries; > >> + mentioned IRTF for analysis on more sophisticated metrics. > >> > >> The current version of the charter is also more explicit about what > >> pieces of information will be provided by an ALTO service; I'll > >> start a > >> separate thread specifically for this discussion. > >> > >> -- > >> Ciao, > >> Enrico > >> > >> > >> _______________________________________________ > >> p2pi mailing list > >> p2pi@ietf.org > >> https://www.ietf.org/mailman/listinfo/p2pi > > > > ______________________________________________________________________ > > ______ > > Bob Briscoe, Networks Research Centre, BT > > Research > > B54/77 Adastral Park,Martlesham Heath,Ipswich,IP5 3RE,UK. +44 > > 1473 645196 > > _______________________________________________ > > p2pi mailing list > > p2pi@ietf.org > > https://www.ietf.org/mailman/listinfo/p2pi > >_______________________________________________ >p2pi mailing list >p2pi@ietf.org >https://www.ietf.org/mailman/listinfo/p2pi ____________________________________________________________________________ Bob Briscoe, Networks Research Centre, BT Research B54/77 Adastral Park,Martlesham Heath,Ipswich,IP5 3RE,UK. +44 1473 645196 _______________________________________________ p2pi mailing list p2pi@ietf.org https://www.ietf.org/mailman/listinfo/p2pi _______________________________________________ p2pi mailing list p2pi@ietf.org https://www.ietf.org/mailman/listinfo/p2pi From p2pi-bounces@ietf.org Tue Aug 12 06:59: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 7905B3A6B12; Tue, 12 Aug 2008 06:59: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 5969C3A6B12 for ; Tue, 12 Aug 2008 06:59:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.163 X-Spam-Level: X-Spam-Status: No, score=-0.163 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eP-MKbtk8-qR for ; Tue, 12 Aug 2008 06:59:18 -0700 (PDT) Received: from pacdcimo01.cable.comcast.com (PacdcIMO01.cable.comcast.com [24.40.8.145]) by core3.amsl.com (Postfix) with ESMTP id 0313D3A6B08 for ; Tue, 12 Aug 2008 06:59:17 -0700 (PDT) Received: from ([10.52.116.30]) by pacdcimo01.cable.comcast.com with ESMTP id 5503620.10848654; Tue, 12 Aug 2008 09:58:56 -0400 Received: from PACDCEXCMB06.cable.comcast.com ([24.40.15.22]) by PAOAKEXCSMTP01.cable.comcast.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 12 Aug 2008 09:58:55 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 12 Aug 2008 09:58:55 -0400 Message-ID: <74CCBBDF76102846AFA7B29F3A98D3F60107C332@PACDCEXCMB06.cable.comcast.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [p2pi] Information in an ALTO protocol Thread-Index: Acj8GSsnZWFL/dhBTUmeCSZpQGTLaQAamP0O From: "Woundy, Richard" To: , X-OriginalArrivalTime: 12 Aug 2008 13:58:55.0953 (UTC) FILETIME=[8F8FA410:01C8FC83] Cc: p2pi@ietf.org Subject: Re: [p2pi] Information in an ALTO protocol X-BeenThere: p2pi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: P2P Infrastructure Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: p2pi-bounces@ietf.org Errors-To: p2pi-bounces@ietf.org >but the ISP would probably be a lot more concerned about telling its competitors the fraction of its customers whom they upsold on a premium plan. I see three potential problems for the ISP. First, there is the user privacy issue. I could imagine an ecommerce portal that varies its prices based on the ISP plan of the user that it dsicovers via ALTO. If this is true, this would be a certain showstopper. Second, there is the ISP marketing concern about revealing the mix of regular versus premium customers. The ISP that reveals this information would be at a competitive disadvantage to the ISP that does not; the second ISP could tune their prices, advertising messages, etc. Third, the ISP premium customers would become much more popular targets for swarm selection algorithms. That *may* serve to concentrate traffic on fewer ISP links. Probably more likely is a lot of TCP connection *attempts* to premium customers, because even premium customers have finite upstream capacity. But if there happens to be aggregate 'capacity slack' in the swarm, then there may be more traffic concentration than is desired by either the premium customer or the ISP. -- Rich ----- Original Message ----- From: p2pi-bounces@ietf.org To: Vinay Aggarwal Cc: p2pi@ietf.org Sent: Mon Aug 11 21:16:44 2008 Subject: Re: [p2pi] Information in an ALTO protocol This might be workable and interesting, but here are a few concerns: 1. For this to be useful, an ISP would need to provide an unobfuscated third-party service that will tell the world what service plan I bought. As a user, I'd have a bit of discomfort with it, but the ISP would probably be a lot more concerned about telling its competitors the fraction of its customers whom they upsold on a premium plan. I suspect this might be a real show-stopper. 2. Nominal provisioned bandwidth on DSL is only an upper bound for the actual negotiated bandwidth. The negotiation takes a few seconds after the modem starts and routinely results in lower-than-nominal rates for longer distances to CO. 3. While it's obvious that an individual peer will, in the current world, do better trading with fat-uplink partners, I'm skeptical of possibility of substantial increases in swarm throughput, which determines the average outcome. Consider the measure of swarm efficiency: total transfer rate divided by total upload capacity. I posit that swarm efficiency is usually quite high, and the only real slack is on super-fast peers in colos and such. Home connection uplinks are so narrow that it does not take much to saturate them. -- Stas On Aug 11, 2008, at 7:35 AM, Vinay Aggarwal wrote: > Hello, > > Regarding what information the ALTO service can provide: > > I think an estimate of "last-hop bandwidth" can be an interesting > metric > of information for peer selection. > It has been shown that selecting peers with high last-hop bandwidth > lead > to improvements in download performance. And this is information > that is > rather hard for peers to find out themselves. As far as I can see, it > also satisfies all the bars set up by the ALTO service. > > Any thoughts? > > Thanks, > Vinay. > > ----------------- > Vinay Aggarwal > Deutsche Telekom > Germany. > > > On Thu, Aug 07, 2008 at 09:14:19PM +0200, Enrico Marocco wrote: >> As some people suggested, it may be useful to try to understand what >> kind of information will be provided by an ALTO service. >> >> Current version of the charter lists four pieces of information: >> + routing preferences and priority values. The network operator is >> usually the only entity in possession of such information, but it is >> in its interests to share at least part of it with applications, in >> order to reduce traffic on critical links. On the other hand, if >> following such preferences leads to better-than-random choices, it >> is >> also in applications' interest to follow them; >> + AS numbers and approximate geographic locations. Such information >> is >> today (partially) available and, in fact, is in some cases already >> used for peer selection. However, since there is no standard way to >> obtain it, it is not easy for applications to switch from an >> information provider to another. >> >> The charter does not preclude any other kind of information entirely, >> but it sets the bar pretty high, requiring that: >> >> When the WG considers standardizing schemas, measures or other >> information that the ALTO service could provide, the following >> criteria are important to ensure real feasibility. >> - Can an ALTO service technically provide that information? >> - Is the ALTO service willing to obtain and divulge that >> information? >> - Is it information that some client will find useful? >> - Can that client get that information without excessive privacy >> concerns (e.g. by sending large lists of peers)? >> - Is it information that clients cannot find easily some other way? >> >> Thoughts? >> >> -- >> 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 -- Stanislav Shalunov _______________________________________________ p2pi mailing list p2pi@ietf.org https://www.ietf.org/mailman/listinfo/p2pi _______________________________________________ p2pi mailing list p2pi@ietf.org https://www.ietf.org/mailman/listinfo/p2pi From p2pi-bounces@ietf.org Tue Aug 12 07:12: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 1EF9A3A6A1C; Tue, 12 Aug 2008 07:12: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 77D603A697B for ; Tue, 12 Aug 2008 07:12:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.115 X-Spam-Level: X-Spam-Status: No, score=-10.115 tagged_above=-999 required=5 tests=[AWL=0.150, 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 mgcW-pSfgHGi for ; Tue, 12 Aug 2008 07:12:51 -0700 (PDT) Received: from dkny.pando.com (dkny.pando.com [67.99.55.163]) by core3.amsl.com (Postfix) with ESMTP id 383E23A6882 for ; Tue, 12 Aug 2008 07:12:51 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by dkny.pando.com (Postfix) with ESMTP id AE8F3E10B5D; Tue, 12 Aug 2008 10:12:31 -0400 (EDT) X-Virus-Scanned: amavisd-new at Received: from dkny.pando.com ([127.0.0.1]) by localhost (dkny.pando.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SKxLGjQe1x+i; Tue, 12 Aug 2008 10:12:24 -0400 (EDT) Received: from dkny.pando.com (dkny.pando.com [10.10.60.11]) by dkny.pando.com (Postfix) with ESMTP id 18AF1E10A1C; Tue, 12 Aug 2008 10:12:24 -0400 (EDT) Date: Tue, 12 Aug 2008 10:12:24 -0400 (EDT) From: Laird Popkin To: Richard Woundy Message-ID: <1035978800.142771218550344074.JavaMail.root@dkny.pando.com> In-Reply-To: <74CCBBDF76102846AFA7B29F3A98D3F60107C332@PACDCEXCMB06.cable.comcast.com> MIME-Version: 1.0 X-Originating-IP: [10.10.20.79] Cc: p2pi@ietf.org Subject: Re: [p2pi] Information in an ALTO protocol X-BeenThere: p2pi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: P2P Infrastructure Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: p2pi-bounces@ietf.org Errors-To: p2pi-bounces@ietf.org Interesting points. I'm not paranoid enough. :-) How about if this is exposed only to the ISP's customers? - Laird Popkin, CTO, Pando Networks mobile: 646/465-0570 ----- Original Message ----- From: "Richard Woundy" To: shalunov@shlang.com, vinay@net.t-labs.tu-berlin.de Cc: p2pi@ietf.org Sent: Tuesday, August 12, 2008 9:58:55 AM (GMT-0500) America/New_York Subject: Re: [p2pi] Information in an ALTO protocol >but the ISP would probably be a lot more concerned about telling its competitors the fraction of its customers whom they upsold on a premium plan. I see three potential problems for the ISP. First, there is the user privacy issue. I could imagine an ecommerce portal that varies its prices based on the ISP plan of the user that it dsicovers via ALTO. If this is true, this would be a certain showstopper. Second, there is the ISP marketing concern about revealing the mix of regular versus premium customers. The ISP that reveals this information would be at a competitive disadvantage to the ISP that does not; the second ISP could tune their prices, advertising messages, etc. Third, the ISP premium customers would become much more popular targets for swarm selection algorithms. That *may* serve to concentrate traffic on fewer ISP links. Probably more likely is a lot of TCP connection *attempts* to premium customers, because even premium customers have finite upstream capacity. But if there happens to be aggregate 'capacity slack' in the swarm, then there may be more traffic concentration than is desired by either the premium customer or the ISP. -- Rich ----- Original Message ----- From: p2pi-bounces@ietf.org To: Vinay Aggarwal Cc: p2pi@ietf.org Sent: Mon Aug 11 21:16:44 2008 Subject: Re: [p2pi] Information in an ALTO protocol This might be workable and interesting, but here are a few concerns: 1. For this to be useful, an ISP would need to provide an unobfuscated third-party service that will tell the world what service plan I bought. As a user, I'd have a bit of discomfort with it, but the ISP would probably be a lot more concerned about telling its competitors the fraction of its customers whom they upsold on a premium plan. I suspect this might be a real show-stopper. 2. Nominal provisioned bandwidth on DSL is only an upper bound for the actual negotiated bandwidth. The negotiation takes a few seconds after the modem starts and routinely results in lower-than-nominal rates for longer distances to CO. 3. While it's obvious that an individual peer will, in the current world, do better trading with fat-uplink partners, I'm skeptical of possibility of substantial increases in swarm throughput, which determines the average outcome. Consider the measure of swarm efficiency: total transfer rate divided by total upload capacity. I posit that swarm efficiency is usually quite high, and the only real slack is on super-fast peers in colos and such. Home connection uplinks are so narrow that it does not take much to saturate them. -- Stas On Aug 11, 2008, at 7:35 AM, Vinay Aggarwal wrote: > Hello, > > Regarding what information the ALTO service can provide: > > I think an estimate of "last-hop bandwidth" can be an interesting > metric > of information for peer selection. > It has been shown that selecting peers with high last-hop bandwidth > lead > to improvements in download performance. And this is information > that is > rather hard for peers to find out themselves. As far as I can see, it > also satisfies all the bars set up by the ALTO service. > > Any thoughts? > > Thanks, > Vinay. > > ----------------- > Vinay Aggarwal > Deutsche Telekom > Germany. > > > On Thu, Aug 07, 2008 at 09:14:19PM +0200, Enrico Marocco wrote: >> As some people suggested, it may be useful to try to understand what >> kind of information will be provided by an ALTO service. >> >> Current version of the charter lists four pieces of information: >> + routing preferences and priority values. The network operator is >> usually the only entity in possession of such information, but it is >> in its interests to share at least part of it with applications, in >> order to reduce traffic on critical links. On the other hand, if >> following such preferences leads to better-than-random choices, it >> is >> also in applications' interest to follow them; >> + AS numbers and approximate geographic locations. Such information >> is >> today (partially) available and, in fact, is in some cases already >> used for peer selection. However, since there is no standard way to >> obtain it, it is not easy for applications to switch from an >> information provider to another. >> >> The charter does not preclude any other kind of information entirely, >> but it sets the bar pretty high, requiring that: >> >> When the WG considers standardizing schemas, measures or other >> information that the ALTO service could provide, the following >> criteria are important to ensure real feasibility. >> - Can an ALTO service technically provide that information? >> - Is the ALTO service willing to obtain and divulge that >> information? >> - Is it information that some client will find useful? >> - Can that client get that information without excessive privacy >> concerns (e.g. by sending large lists of peers)? >> - Is it information that clients cannot find easily some other way? >> >> Thoughts? >> >> -- >> 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 -- Stanislav Shalunov _______________________________________________ p2pi mailing list p2pi@ietf.org https://www.ietf.org/mailman/listinfo/p2pi _______________________________________________ p2pi mailing list p2pi@ietf.org https://www.ietf.org/mailman/listinfo/p2pi _______________________________________________ p2pi mailing list p2pi@ietf.org https://www.ietf.org/mailman/listinfo/p2pi From p2pi-bounces@ietf.org Tue Aug 12 07:28: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 6FB223A68E6; Tue, 12 Aug 2008 07:28: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 433D53A68E6 for ; Tue, 12 Aug 2008 07:28:51 -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 ZHj5iin5I3j7 for ; Tue, 12 Aug 2008 07:28:50 -0700 (PDT) Received: from fruitcake.ICSI.Berkeley.EDU (fruitcake.ICSI.Berkeley.EDU [192.150.186.11]) by core3.amsl.com (Postfix) with ESMTP id 9BE573A6780 for ; Tue, 12 Aug 2008 07:28:50 -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 m7CES3hD028428; Tue, 12 Aug 2008 07:28:03 -0700 (PDT) Message-Id: From: Nicholas Weaver To: Laird Popkin In-Reply-To: <1035978800.142771218550344074.JavaMail.root@dkny.pando.com> Mime-Version: 1.0 (Apple Message framework v928.1) Date: Tue, 12 Aug 2008 07:28:03 -0700 References: <1035978800.142771218550344074.JavaMail.root@dkny.pando.com> X-Mailer: Apple Mail (2.928.1) Cc: p2pi@ietf.org, Richard Woundy , Nicholas Weaver Subject: Re: [p2pi] Information in an ALTO protocol X-BeenThere: p2pi@ietf.org 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 Aug 12, 2008, at 7:12 AM, Laird Popkin wrote: > Interesting points. I'm not paranoid enough. :-) No, you're not. Its not paranoia when they are out to get you. > How about if this is exposed only to the ISP's customers? My company-X P2P business model includes an agent I control on the user's computer, no? So if its valuable, Company-X can use company-X's customers to mine the data. This would especially be useful because you could do a direct increase in performance by feeding back the data to the tracking infrastructure. _______________________________________________ p2pi mailing list p2pi@ietf.org https://www.ietf.org/mailman/listinfo/p2pi From p2pi-bounces@ietf.org Tue Aug 12 07:46: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 0E3993A6B48; Tue, 12 Aug 2008 07:46: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 11CCC28C101 for ; Tue, 12 Aug 2008 07:46:00 -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 w3nn3FXJWlCR for ; Tue, 12 Aug 2008 07:45:58 -0700 (PDT) Received: from dkny.pando.com (dkny.pando.com [67.99.55.163]) by core3.amsl.com (Postfix) with ESMTP id 603F93A6A5F for ; Tue, 12 Aug 2008 07:45:58 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by dkny.pando.com (Postfix) with ESMTP id 6A7E9E10BFC; Tue, 12 Aug 2008 10:45:38 -0400 (EDT) X-Virus-Scanned: amavisd-new at Received: from dkny.pando.com ([127.0.0.1]) by localhost (dkny.pando.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Qvfwjx+O6zKj; Tue, 12 Aug 2008 10:45:32 -0400 (EDT) Received: from dkny.pando.com (dkny.pando.com [10.10.60.11]) by dkny.pando.com (Postfix) with ESMTP id 3CD34E10BFB; Tue, 12 Aug 2008 10:45:32 -0400 (EDT) Date: Tue, 12 Aug 2008 10:45:32 -0400 (EDT) From: Laird Popkin To: Nicholas Weaver Message-ID: <842019533.143161218552332226.JavaMail.root@dkny.pando.com> In-Reply-To: <1068782360.143081218551863052.JavaMail.root@dkny.pando.com> MIME-Version: 1.0 X-Originating-IP: [10.10.20.79] Cc: p2pi@ietf.org, Richard Woundy , Nicholas Weaver Subject: Re: [p2pi] Information in an ALTO protocol X-BeenThere: p2pi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: P2P Infrastructure Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: p2pi-bounces@ietf.org Errors-To: p2pi-bounces@ietf.org Many p2p networks already do this sort of thing, and I can't think of any way that the ISP could prevent it - any p2p app can measure throughput and report it. For example, see http://www.speedtest.net/global.php. Of course, this is only based on users that installed the agent, which may not be representative, and doesn't different between classes of users (since the agent can't tell whether they're on a DOCSIS 1/2/3 cable modem, etc.). The advantage of getting link capacity info from the ISP rather than by measurement is that it's a bit faster and more consistent, and saves a little bandwidth by not doing the test. The other alternative is to use commercial IP mapping databases (e.g. MaxMind's netspeed database), which is fast and cheap, but these databases not as accurate or precise as an ISP could be. For example, MaxMind differentiates between dial, broadband and corporate, but not between classes of broadband. - Laird Popkin, CTO, Pando Networks mobile: 646/465-0570 ----- Original Message ----- From: "Nicholas Weaver" To: "Laird Popkin" Cc: "Nicholas Weaver" , "Richard Woundy" , p2pi@ietf.org Sent: Tuesday, August 12, 2008 10:28:03 AM (GMT-0500) America/New_York Subject: Re: [p2pi] Information in an ALTO protocol On Aug 12, 2008, at 7:12 AM, Laird Popkin wrote: > Interesting points. I'm not paranoid enough. :-) No, you're not. Its not paranoia when they are out to get you. > How about if this is exposed only to the ISP's customers? My company-X P2P business model includes an agent I control on the user's computer, no? So if its valuable, Company-X can use company-X's customers to mine the data. This would especially be useful because you could do a direct increase in performance by feeding back the data to the tracking infrastructure. _______________________________________________ p2pi mailing list p2pi@ietf.org https://www.ietf.org/mailman/listinfo/p2pi From p2pi-bounces@ietf.org Tue Aug 12 09:26: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 2164D3A6B69; Tue, 12 Aug 2008 09:26: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 A82283A69C2 for ; Tue, 12 Aug 2008 09:26:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.313 X-Spam-Level: X-Spam-Status: No, score=-0.313 tagged_above=-999 required=5 tests=[AWL=0.150, 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 NAPQfeQVXBwu for ; Tue, 12 Aug 2008 09:26:55 -0700 (PDT) Received: from pacdcimo01.cable.comcast.com (PacdcIMO01.cable.comcast.com [24.40.8.145]) by core3.amsl.com (Postfix) with ESMTP id 5A34A3A6BA0 for ; Tue, 12 Aug 2008 09:26:42 -0700 (PDT) Received: from ([10.52.116.30]) by pacdcimo01.cable.comcast.com with ESMTP id 5503620.10874025; Tue, 12 Aug 2008 12:26:17 -0400 Received: from PACDCEXCMB06.cable.comcast.com ([24.40.15.22]) by PAOAKEXCSMTP01.cable.comcast.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 12 Aug 2008 12:26:15 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 12 Aug 2008 12:26:14 -0400 Message-ID: <74CCBBDF76102846AFA7B29F3A98D3F60107C335@PACDCEXCMB06.cable.comcast.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [p2pi] Information in an ALTO protocol Thread-Index: Acj8ij9hFuOMnZglSKSCHIKepvxB0gADeR2e From: "Woundy, Richard" To: , X-OriginalArrivalTime: 12 Aug 2008 16:26:15.0892 (UTC) FILETIME=[24934940:01C8FC98] Cc: p2pi@ietf.org Subject: Re: [p2pi] Information in an ALTO protocol X-BeenThere: p2pi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: P2P Infrastructure Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: 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 disagree that you can measure a user's throughput, and in fact this is necessary for certain applications that negotiate codecs, eg iChat. But with speedtest servers and application-based measurement, there is an explicit or implicit opt-in by the user. I suppose the ISP's ALTO service could also enable opt-in for the customer's provisioned speed to be reported, but I wonder how many customers would be incented to do this, and would that re-enforce any traffic concentration effects that I mentioned before (because few users opt in). I suspect that knowing the link speed doesn't really enable the application to avoid testing for the actual available bandwidth, given that other applications may be consuming bandwidth. -- Rich ----- Original Message ----- From: Laird Popkin To: Nicholas Weaver Cc: Nicholas Weaver ; Woundy, Richard; p2pi@ietf.org Sent: Tue Aug 12 10:45:32 2008 Subject: Re: [p2pi] Information in an ALTO protocol Many p2p networks already do this sort of thing, and I can't think of any way that the ISP could prevent it - any p2p app can measure throughput and report it. For example, see http://www.speedtest.net/global.php. Of course, this is only based on users that installed the agent, which may not be representative, and doesn't different between classes of users (since the agent can't tell whether they're on a DOCSIS 1/2/3 cable modem, etc.). The advantage of getting link capacity info from the ISP rather than by measurement is that it's a bit faster and more consistent, and saves a little bandwidth by not doing the test. The other alternative is to use commercial IP mapping databases (e.g. MaxMind's netspeed database), which is fast and cheap, but these databases not as accurate or precise as an ISP could be. For example, MaxMind differentiates between dial, broadband and corporate, but not between classes of broadband. - Laird Popkin, CTO, Pando Networks mobile: 646/465-0570 ----- Original Message ----- From: "Nicholas Weaver" To: "Laird Popkin" Cc: "Nicholas Weaver" , "Richard Woundy" , p2pi@ietf.org Sent: Tuesday, August 12, 2008 10:28:03 AM (GMT-0500) America/New_York Subject: Re: [p2pi] Information in an ALTO protocol On Aug 12, 2008, at 7:12 AM, Laird Popkin wrote: > Interesting points. I'm not paranoid enough. :-) No, you're not. Its not paranoia when they are out to get you. > How about if this is exposed only to the ISP's customers? My company-X P2P business model includes an agent I control on the user's computer, no? So if its valuable, Company-X can use company-X's customers to mine the data. This would especially be useful because you could do a direct increase in performance by feeding back the data to the tracking infrastructure. _______________________________________________ p2pi mailing list p2pi@ietf.org https://www.ietf.org/mailman/listinfo/p2pi From p2pi-bounces@ietf.org Thu Aug 14 07:59:30 2008 Return-Path: X-Original-To: p2pi-archive@ietf.org Delivered-To: ietfarch-p2pi-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D02453A6D42; Thu, 14 Aug 2008 07:59:30 -0700 (PDT) X-Original-To: p2pi@core3.amsl.com Delivered-To: p2pi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 90EF23A6BD1 for ; Thu, 14 Aug 2008 07:59:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mjlAe0Oxpruc for ; Thu, 14 Aug 2008 07:59:29 -0700 (PDT) Received: from smtp0.neclab.eu (smtp0.neclab.eu [195.37.70.41]) by core3.amsl.com (Postfix) with ESMTP id 4D6503A6D42 for ; Thu, 14 Aug 2008 07:59:29 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp0.neclab.eu (Postfix) with ESMTP id DDA962C00035D; Thu, 14 Aug 2008 16:59:25 +0200 (CEST) X-Virus-Scanned: Amavisd on Debian GNU/Linux (atlas2.office) Received: from smtp0.neclab.eu ([127.0.0.1]) by localhost (atlas2.office [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CMfBzX0gcO39; Thu, 14 Aug 2008 16:59:25 +0200 (CEST) Received: from VENUS.office (mx2.office [192.168.24.15]) by smtp0.neclab.eu (Postfix) with ESMTP id BC6472C000304; Thu, 14 Aug 2008 16:59:15 +0200 (CEST) Received: from foo.nw.neclab.eu ([10.1.6.208]) by VENUS.office with Microsoft SMTPSVC(6.0.3790.3959); Thu, 14 Aug 2008 16:59:14 +0200 Received: by foo.nw.neclab.eu (sSMTP sendmail emulation); Thu, 14 Aug 2008 16:59:14 +0200 Date: Thu, 14 Aug 2008 16:59:14 +0200 From: Sebastian Kiesel To: Stanislav Shalunov Message-ID: <20080814145914.GA6284@foo.nw.neclab.eu> References: <489B498B.4040804@telecomitalia.it> <20080811143531.GA18911@net.t-labs.tu-berlin.de> <119D7BAE-4CBB-4BCE-BB3C-594FC6234AB6@shlang.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <119D7BAE-4CBB-4BCE-BB3C-594FC6234AB6@shlang.com> User-Agent: Mutt/1.5.15+20070412 (2007-04-11) X-OriginalArrivalTime: 14 Aug 2008 14:59:14.0924 (UTC) FILETIME=[51764AC0:01C8FE1E] Cc: p2pi@ietf.org Subject: Re: [p2pi] Information in an ALTO protocol X-BeenThere: p2pi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: P2P Infrastructure Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: 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, "total transfer rate divided by total upload capacity" is a good measure of swarm efficiency if the application is file sharing. p2p live video streaming (an application which might gain much relevance till the time when a potential ALTO workgroup would deliver their first specifications) has differenent metrics: the system can only be stable if the video stream's bitrate is lower than the average upload capacity, i.e., not all uplinks will be saturated by this application. The interesting metric is the lag, i.e., the delay of the video stream between injection into the swarm and playout (measured individually per node or as average in the swarm). It can be reduced if nodes with higher upload capacity or shorter transport delay from the source are placed closer to the source in the logical topology. The incentive for a user to offer more upload capacity to the swarm is to get a smaller individual lag. While p2p algorithms can converge to a "good" state, ALTO guidance would be very beneficial if it could speed up that process. This is very relevant here as many users switch TV channels (streams) frequently. Any thoughts? Thanks, Sebastian On Mon, Aug 11, 2008 at 06:16:44PM -0700, Stanislav Shalunov wrote: > This might be workable and interesting, but here are a few concerns: > > 1. For this to be useful, an ISP would need to provide an unobfuscated > third-party service that will tell the world what service plan I bought. > As a user, I'd have a bit of discomfort with it, but the ISP would probably > be a lot more concerned about telling its competitors the fraction of its > customers whom they upsold on a premium plan. I suspect this might be a > real show-stopper. > > 2. Nominal provisioned bandwidth on DSL is only an upper bound for the > actual negotiated bandwidth. The negotiation takes a few seconds after the > modem starts and routinely results in lower-than-nominal rates for longer > distances to CO. > > 3. While it's obvious that an individual peer will, in the current world, > do better trading with fat-uplink partners, I'm skeptical of possibility of > substantial increases in swarm throughput, which determines the average > outcome. Consider the measure of swarm efficiency: total transfer rate > divided by total upload capacity. I posit that swarm efficiency is usually > quite high, and the only real slack is on super-fast peers in colos and > such. Home connection uplinks are so narrow that it does not take much to > saturate them. > > -- Stas -- Sebastian Kiesel mailto:sebastian.kiesel@nw.neclab.eu Network Research Division tel:+49-6221-4342-232 fax:+49-6221-4342-155 NEC Laboratories Europe Kurfuerstenanlage 36, 69115 Heidelberg, Germany -- NEC Europe Limited Registered in England 2832014 Registered Office NEC House, 1 Victoria Road, London W3 6BL _______________________________________________ p2pi mailing list p2pi@ietf.org https://www.ietf.org/mailman/listinfo/p2pi From p2pi-bounces@ietf.org Thu Aug 14 10:29: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 C32693A6AD4; Thu, 14 Aug 2008 10:29: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 63EA93A6AD4 for ; Thu, 14 Aug 2008 10:29:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.58 X-Spam-Level: X-Spam-Status: No, score=0.58 tagged_above=-999 required=5 tests=[AWL=1.299, 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 X8R6b-dBgpXs for ; Thu, 14 Aug 2008 10:29:07 -0700 (PDT) Received: from maile.telecomitalia.it (maile.telecomitalia.it [156.54.233.31]) by core3.amsl.com (Postfix) with ESMTP id A3A653A6ABC for ; Thu, 14 Aug 2008 10:29:06 -0700 (PDT) Received: from ptpxch010ba020.idc.cww.telecomitalia.it ([156.54.240.53]) by maile.telecomitalia.it with Microsoft SMTPSVC(6.0.3790.1830); Thu, 14 Aug 2008 19:29:09 +0200 Received: from grfhub701ba020.griffon.local ([10.188.101.111]) by ptpxch010ba020.idc.cww.telecomitalia.it with Microsoft SMTPSVC(6.0.3790.1830); Thu, 14 Aug 2008 19:29:08 +0200 Received: from [172.16.82.18] (163.162.180.246) by smtp.telecomitalia.it (10.188.101.114) with Microsoft SMTP Server (TLS) id 8.1.278.0; Thu, 14 Aug 2008 19:29:07 +0200 Message-ID: <48A469FF.4000105@telecomitalia.it> Date: Thu, 14 Aug 2008 19:23:11 +0200 From: Enrico Marocco User-Agent: Mozilla-Thunderbird 2.0.0.16 (X11/20080724) MIME-Version: 1.0 To: Lars Eggert References: <489B47A0.1050507@telecomitalia.it> In-Reply-To: X-OriginalArrivalTime: 14 Aug 2008 17:29:08.0838 (UTC) FILETIME=[4240A860:01C8FE33] Cc: Lisa Dusseault , "p2pi@ietf.org" Subject: Re: [p2pi] After-BoF charter X-BeenThere: p2pi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: P2P Infrastructure Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0986509593==" Sender: p2pi-bounces@ietf.org Errors-To: p2pi-bounces@ietf.org --===============0986509593== Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms030203000807000802030004" --------------ms030203000807000802030004 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Lars Eggert wrote: > I believe that the new charter text is a huge step in the right > direction - thank you for not being discouraged from continuing to > work on this after the BOF. Well, the interest shown at the BoF was actually encouraging, even if having all those people (> 240, according to bluesheets) agree is kind of a nightmare ;-) > I have a few comments on specific bits of text: > >> DRAFT CHARTER >> $Id: charter.txt 71 2008-08-07 17:15:10Z enrico $ > > What area are you targeting for the WG? (I assume APP.) The proposed WG will target APP, but probably it will need advisors from other areas as well. >> The Working Group will design and specify an Application-Layer Traffic >> Optimization (ALTO) service that will provide applications with >> information to perform better-than-random peer selection. > > Hm. There are research results (Peter Key, etc.) that show that random > peer selection based on observed performance over time approximates an > optimal peer selection, at least for some metrics. It seems like the > best ALTO could do is help P2P systems converge on a good set of peers > faster (maybe much faster) that performance-based random selection > over time would? Right. The previous paragraph says that it is a time-related issue, but probably it would be worth reaffirming it with "initial peer selection" (as John suggested). >> The WG will >> consider BitTorrent, tracker-less P2P, and other applications, such as >> content delivery networks (CDN) and mirror selection. >> >> The WG will focus on the following items: > > For each of these items, it's be good to indicate in the charter what > kinds of documents (PS, Experimental, Informational, BCP) the WG is > expected to produce. Sure, we would have specified the type in "goals and milestones". The only item we are still not sure about is the discovery mechanism, which could be either Informational, PS or BCP, depending on what it will be based on. Other documents would be informational (reqs) and standards track protocols. >> - A requirements document. This document will list requirements for a >> peer selection service, identifying, for example, what kind of >> information P2P applications will need for optimizing their choices. >> >> - A request/response protocol for querying the ALTO service to obtain >> information useful for peer selection, and a format for requests and >> responses. > > I'd like to suggest that at least the initial protocol should run over > TCP. I don't think we should say that in a charter. However, we could still say that, for example, "if, for some very good reason, the WG will decide to define a UDP-based protocol, guidelines in draft-ietf-tsvwg-udp-guidelines must be followed." >> - A schema for such a protocol to communicate routing preferences to >> applications, including IP ranges to prefer and avoid. > > Your email also talks about AS numbers (as do charter paragraphs > below), but the work item above is only about IP ranges and no other > work item talks about AS numbers - missing work item? Actually it is still not perfectly clear if ASN and geolocation information should go in the same schema (e.g. as an alternative way to express routing preferences), or in a different schema. -- Ciao, Enrico --------------ms030203000807000802030004 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 hkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wODA4MTQxNzIzMTFaMCMG CSqGSIb3DQEJBDEWBBT64MrmGy0FzbbeWtUNTwrkHhjP/TBfBgkqhkiG9w0BCQ8xUjBQMAsG CWCGSAFlAwQBAjAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAw BwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgYUGCSsGAQQBgjcQBDF4MHYwYjELMAkGA1UEBhMC WkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1Ro YXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAhAeTAANDUMJU97n0e1AWxu4MIGH BgsqhkiG9w0BCRACCzF4oHYwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25z dWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJ c3N1aW5nIENBAhAeTAANDUMJU97n0e1AWxu4MA0GCSqGSIb3DQEBAQUABIIBABsZ0TH57XkK 6G3cYWT6sFAhldN6p1QtbSuI9D3KACql5NFsAJb8NC5ujOWzZtTxeBq/PNhRlyf8Lh/aRT4G suoILmbTNkIMzMQL2dQuqoNW5rvvdHe+UY8yp/t174aXR9ALCxlmCOlAsS2+99TPdN/jmvtj nFBRJkrGD8aW9Kri9J2Sh3uKpcokL8M8W+GYFisntuHZTScvVqw5E4WitKMv3q9+AZ2nln5o Z5UmUld1bfQ433V1rLwMpuSb/fzoYMI3hjqceGE02Gv9lZXxXHFLoanizHHaZWFo2z5bfDWE 1TncnlPB48ki5oVJw1xXCtwqytCP0Uq0akA8QHLjk48AAAAAAAA= --------------ms030203000807000802030004-- --===============0986509593== 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 --===============0986509593==-- From p2pi-bounces@ietf.org Thu Aug 14 10:30: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 5809C28C16D; Thu, 14 Aug 2008 10:30: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 F06643A6C6C for ; Thu, 14 Aug 2008 10:30:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.147 X-Spam-Level: X-Spam-Status: No, score=0.147 tagged_above=-999 required=5 tests=[AWL=0.866, 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 tqCMl4RkTYMw for ; Thu, 14 Aug 2008 10:30:43 -0700 (PDT) Received: from maild.telecomitalia.it (maild.telecomitalia.it [156.54.233.30]) by core3.amsl.com (Postfix) with ESMTP id 82B813A6AF0 for ; Thu, 14 Aug 2008 10:30:42 -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, 14 Aug 2008 19:30:45 +0200 Received: from grfhub701ba020.griffon.local ([10.188.101.111]) by ptpxch009ba020.idc.cww.telecomitalia.it with Microsoft SMTPSVC(6.0.3790.1830); Thu, 14 Aug 2008 19:30:45 +0200 Received: from [172.16.82.18] (163.162.180.246) by smtp.telecomitalia.it (10.188.101.114) with Microsoft SMTP Server (TLS) id 8.1.278.0; Thu, 14 Aug 2008 19:30:44 +0200 Message-ID: <48A46A5F.4080606@telecomitalia.it> Date: Thu, 14 Aug 2008 19:24:47 +0200 From: Enrico Marocco User-Agent: Mozilla-Thunderbird 2.0.0.16 (X11/20080724) MIME-Version: 1.0 To: John Leslie References: <489B47A0.1050507@telecomitalia.it> <20080808161710.GA25453@verdi> In-Reply-To: <20080808161710.GA25453@verdi> X-OriginalArrivalTime: 14 Aug 2008 17:30:45.0229 (UTC) FILETIME=[7BB4C1D0:01C8FE33] Cc: Lisa Dusseault , "p2pi@ietf.org" Subject: Re: [p2pi] After-BoF charter X-BeenThere: p2pi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: P2P Infrastructure Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0155532447==" Sender: p2pi-bounces@ietf.org Errors-To: p2pi-bounces@ietf.org --===============0155532447== Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms040009080003000405070101" --------------ms040009080003000405070101 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit John Leslie wrote: > The speed of convergence to optimal is the critical issue: we want > a "better-than-random" initial set of peers to try (and possibly an > ordered list to try if they prove unsatisfactory. > > I think adding the word "inital" would help: > " > " information to perform better-than-random initial peer selection. Yes, that's better. >>> When the WG considers standardizing schemas, measures or other >>> information that the ALTO service could provide, the following >>> criteria are important to ensure real feasibility. >>> >>> - Can an ALTO service technically provide that information? >>> >>> - Is the ALTO service willing to obtain and divulge that information? >>> >>> - Is it information that some client will find useful? > > Good criteria, but I'd suggest uniformity of the indefinite article: > > - "an" ALTO service technically provide > - "an" ALTO service willing to obtain and divulge > - "a" client will find useful Ok. >>> Protocols used for peer selection optimization will carry information >>> related to the topology and the policies of the querying peer's >>> network (i.e. queries on behalf of other peers are not allowed). > > We should perhaps be careful about this last prohibition. I'm not > sure the obvious mechanism (matching the source IP address of a query) > is wise (though I certainly wouldn't prohibit implementations from > trying it). > > There are obvious potential benefits from letting particular > trackers read an ISP's policies (by prior arrangement, usually). A > blanket prohibition of this seems unnecessary. That's true, but, on the other hand, allowing uncontrolled third-party queries would be a privacy nightmare, for both users and ISPs. I've personally had a discussion with Stanislav, who said that having peers doing the ALTO query and passing the response back to a BitTorrent tracker would not be too much of a hassle, so, probably, given the costs that controlling third-party queries in a reasonable way would imply, it could be wise to just forbid them. However, I would really like to hear what other people think about this, especially on the P2P side. >>> It is reasonable to expect that applications will use such protocols >>> to discover Autonomous System (AS) numbers and approximate geographic >>> location of peers hosting the needed resources, > > I don't even _understand_ this. > > Current trackers _do_ try to find these pieces of information, but > IMHO they're suboptimal substitutes for information ISPs could provide. > I see no reason to include such text in a charter. Right, we have let them in exactly because that's the kind of information a third-party non-ISP ALTO service provider could provide (ip2location and "looking glass" web services already do, just in a non-standard way). We could get rid of those pieces of information, but that would probably reduce the suitability of ALTO for non-ISPs. -- Ciao, Enrico --------------ms040009080003000405070101 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 hkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wODA4MTQxNzI0NDdaMCMG CSqGSIb3DQEJBDEWBBRJIUlNOWHwmyl3h94rLJ7fzr9d4jBfBgkqhkiG9w0BCQ8xUjBQMAsG CWCGSAFlAwQBAjAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAw BwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgYUGCSsGAQQBgjcQBDF4MHYwYjELMAkGA1UEBhMC WkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1Ro YXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAhAeTAANDUMJU97n0e1AWxu4MIGH BgsqhkiG9w0BCRACCzF4oHYwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25z dWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJ c3N1aW5nIENBAhAeTAANDUMJU97n0e1AWxu4MA0GCSqGSIb3DQEBAQUABIIBAFrROmDsLyFf ol+DNTuyM1/R8uONxWGTXa9I8d9byavzHlDNtNGSuIXoemwIlbgQ45qEZpGV9WFZdT+rTkxd 6yH4McFw4DBbiP52JMPoSCvvShtMKdWgn5ubpeQ318cKo5ZfO/vHYRz+GoyO/0Qgdiayb8fd Tg56Nta8WsjB6YKf4KxULySj65bGh4Z5GnKHI7+ktv5SdM4Sp3WT+sLZr+YqBTxqOKIU6nl4 txK3GNLOQyQgNhl6Tc9l5ntGo3LedgvQA0EAMobMyD3hrAYQJQinVWROTqgHLL/ZWtK3CBIz GyogYShFf3yWhQO7F7RnglFxEumTfKEhI5YJ2EPDQkAAAAAAAAA= --------------ms040009080003000405070101-- --===============0155532447== 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 --===============0155532447==-- From p2pi-bounces@ietf.org Thu Aug 14 11:07:55 2008 Return-Path: X-Original-To: p2pi-archive@ietf.org Delivered-To: ietfarch-p2pi-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B7FDF3A6886; Thu, 14 Aug 2008 11:07: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 608FD3A6886 for ; Thu, 14 Aug 2008 11:07:55 -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 QGoAEyiyX4iZ for ; Thu, 14 Aug 2008 11:07:54 -0700 (PDT) Received: from dkny.pando.com (dkny.pando.com [67.99.55.163]) by core3.amsl.com (Postfix) with ESMTP id 315703A684E for ; Thu, 14 Aug 2008 11:07:54 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by dkny.pando.com (Postfix) with ESMTP id 69751E10B92; Thu, 14 Aug 2008 14:07: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 aA-EWk5FbDpz; Thu, 14 Aug 2008 14:07:11 -0400 (EDT) Received: from [10.10.20.61] (unknown [10.10.20.61]) by dkny.pando.com (Postfix) with ESMTP id 129FDE10B88; Thu, 14 Aug 2008 14:07:11 -0400 (EDT) Message-Id: <90CC235D-FB1F-4F59-B57B-A2E378B559DC@pando.com> From: Laird Popkin To: Enrico Marocco In-Reply-To: <48A46A5F.4080606@telecomitalia.it> Mime-Version: 1.0 (Apple Message framework v928.1) Date: Thu, 14 Aug 2008 14:07:10 -0400 References: <489B47A0.1050507@telecomitalia.it> <20080808161710.GA25453@verdi> <48A46A5F.4080606@telecomitalia.it> X-Mailer: Apple Mail (2.928.1) Cc: Lisa Dusseault , "p2pi@ietf.org" Subject: Re: [p2pi] After-BoF charter X-BeenThere: p2pi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: P2P Infrastructure Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: p2pi-bounces@ietf.org Errors-To: p2pi-bounces@ietf.org On Aug 14, 2008, at 1:24 PM, Enrico Marocco wrote: > John Leslie wrote: >> The speed of convergence to optimal is the critical issue: we want >> a "better-than-random" initial set of peers to try (and possibly an >> ordered list to try if they prove unsatisfactory. >> >> I think adding the word "inital" would help: >> " >> " information to perform better-than-random initial peer selection. > > Yes, that's better. I strongly agree - this clarifies the relationship between ALTO and P2P networks quite nicely. >>>> Protocols used for peer selection optimization will carry >>>> information >>>> related to the topology and the policies of the querying peer's >>>> network (i.e. queries on behalf of other peers are not allowed). >> >> We should perhaps be careful about this last prohibition. I'm not >> sure the obvious mechanism (matching the source IP address of a >> query) >> is wise (though I certainly wouldn't prohibit implementations from >> trying it). >> >> There are obvious potential benefits from letting particular >> trackers read an ISP's policies (by prior arrangement, usually). A >> blanket prohibition of this seems unnecessary. > > That's true, but, on the other hand, allowing uncontrolled third-party > queries would be a privacy nightmare, for both users and ISPs. I've > personally had a discussion with Stanislav, who said that having peers > doing the ALTO query and passing the response back to a BitTorrent > tracker would not be too much of a hassle, so, probably, given the > costs > that controlling third-party queries in a reasonable way would > imply, it > could be wise to just forbid them. However, I would really like to > hear > what other people think about this, especially on the P2P side. A p2p network can query ALTO information through clients, of course. If ALTO is used by Trackers to decide which peers to connect, then it's a matter of getting the right info to the Tracker. IMO ALTO should allow the expression of an ISP policy that applies more broadly than a single client. For example, if a client can get the ALTO guidance that "for all of my customers (defined by an IP prefix list), please do p2p transfers with the FTTH users (defined by an IP prefix list) before other users.") then the p2p service can apply that policy to all peers without them all having to individually ask the ALTO server. If ALTO were limited to telling each client what policy to apply to its p2p connections, then every p2p client would have to make an ALTO query, then pass the response back to the Tracker to analyze and apply. This seems like more work all around, so I hope that we don't restrict ALTO to this case. >>>> It is reasonable to expect that applications will use such >>>> protocols >>>> to discover Autonomous System (AS) numbers and approximate >>>> geographic >>>> location of peers hosting the needed resources, >> >> I don't even _understand_ this. >> >> Current trackers _do_ try to find these pieces of information, but >> IMHO they're suboptimal substitutes for information ISPs could >> provide. >> I see no reason to include such text in a charter. > > Right, we have let them in exactly because that's the kind of > information a third-party non-ISP ALTO service provider could provide > (ip2location and "looking glass" web services already do, just in a > non-standard way). We could get rid of those pieces of information, > but > that would probably reduce the suitability of ALTO for non-ISPs. The IP to ASN lookup services are proprietary and somewhat inaccurate. If ISPs can provide a standard, precise mechanism for determining which users are within their network, that would probably be better. Of course, for other ISPs p2p networks would continue to use the existing mechanisms, so this isn't a matter of doing something impossible, but more a matter of introducing a more precise, efficient mechanism to do what is done now. > > -- > 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 Thu Aug 14 12:29: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 1606F3A6886; Thu, 14 Aug 2008 12:29: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 497713A6822 for ; Thu, 14 Aug 2008 12:29:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e8I9f7DK5PIt for ; Thu, 14 Aug 2008 12:29:01 -0700 (PDT) Received: from ihemail2.lucent.com (ihemail2.lucent.com [135.245.0.35]) by core3.amsl.com (Postfix) with ESMTP id 180B43A68BF for ; Thu, 14 Aug 2008 12:29:00 -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 m7EJSx5u020494 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 14 Aug 2008 14:29:00 -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 m7EJSpxc011569; Thu, 14 Aug 2008 14:28:53 -0500 (CDT) Message-ID: <48A48779.60507@alcatel-lucent.com> Date: Thu, 14 Aug 2008 14:28:57 -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: rbriscoe@jungle.bt.co.uk References: <74CCBBDF76102846AFA7B29F3A98D3F60107C32A@PACDCEXCMB06.cable.comcast.com> <200808120901.m7C91q6H012752@bagheera.jungle.bt.co.uk> In-Reply-To: <200808120901.m7C91q6H012752@bagheera.jungle.bt.co.uk> X-Scanned-By: MIMEDefang 2.57 on 135.245.2.35 Cc: "p2pi@ietf.org" Subject: Re: [p2pi] Information in an ALTO protocol X-BeenThere: p2pi@ietf.org 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 Bob Briscoe wrote: > I want the charter to acknowledge the same old point I started with at > the mic and on the list: > - that unconditional localisation will not be sufficient for /any/ ISP, Bob: It is my belief that the post-BoF charter acknowledges this (please see http://alto.tilab.com/docs/charter.txt). That said ... > so the parameters that the ALTO service will have to gather are more > than just the static ones: topology and policies I think that which parameters to gather will turn out to be an interesting topic to nail down. Enrico had sent an email out last week to try and gather this information; there was some discussion and the issue got sidetracked. So, I'd like to refocus on that issue. At present, we have the following discrete pieces of information mentioned in the post-BoF charter: (1) Routing preferences (2) Priority values (3) AS numbers (4) Geographic location Add to this the two more: (5) Policies (6) Topology 1, 2, and 5 are something that the network operator is in possession of. 3 and 4 can be gleaned in some manner (probably not using any standardized APIs but well known services, nonetheless.) 6 can be provided by the network operator or approximated using synthetic coordinate systems and the like. Information that has been deemed out of scope based on list discussion is: (1) Last hop bandwidth (reason: too much uncertainty -- are we talking about upload or download bandwidth? Provisioned band- width or current snapshot? User privacy concerns, ISP marketing concerns, etc. In short, while this is a good research problem, it may not be a good piece of information to be provided by ALTO.) What other sort of information should be a focus of ALTO? Thanks, - vijay -- Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent 2701 Lucent Lane, Rm. 9F-546, Lisle, Illinois 60532 (USA) Email: vkg@{alcatel-lucent.com,bell-labs.com,acm.org} WWW: http://www.alcatel-lucent.com/bell-labs _______________________________________________ p2pi mailing list p2pi@ietf.org https://www.ietf.org/mailman/listinfo/p2pi From p2pi-bounces@ietf.org Thu Aug 14 13:43: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 254F53A693C; Thu, 14 Aug 2008 13:43: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 B5EA43A67B7 for ; Thu, 14 Aug 2008 13:43:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.686 X-Spam-Level: X-Spam-Status: No, score=-2.686 tagged_above=-999 required=5 tests=[AWL=-0.087, 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 H54lIbRqqoBm for ; Thu, 14 Aug 2008 13:43:19 -0700 (PDT) Received: from mailhost.jlc.net (mailhost.jlc.net [199.201.159.9]) by core3.amsl.com (Postfix) with ESMTP id 92C493A6996 for ; Thu, 14 Aug 2008 13:43:19 -0700 (PDT) Received: by mailhost.jlc.net (Postfix, from userid 104) id 1477733C2C; Thu, 14 Aug 2008 16:42:50 -0400 (EDT) Date: Thu, 14 Aug 2008 16:42:49 -0400 From: John Leslie To: "Vijay K. Gurbani" Message-ID: <20080814204249.GS25453@verdi> References: <74CCBBDF76102846AFA7B29F3A98D3F60107C32A@PACDCEXCMB06.cable.comcast.com> <200808120901.m7C91q6H012752@bagheera.jungle.bt.co.uk> <48A48779.60507@alcatel-lucent.com> Mime-Version: 1.0 Content-Disposition: inline In-Reply-To: <48A48779.60507@alcatel-lucent.com> User-Agent: Mutt/1.4.1i Cc: "p2pi@ietf.org" Subject: Re: [p2pi] Information in an ALTO protocol X-BeenThere: p2pi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: P2P Infrastructure Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: p2pi-bounces@ietf.org Errors-To: p2pi-bounces@ietf.org Vijay K. Gurbani wrote: > > I think that which parameters to gather will turn out to be an > interesting topic to nail down. Interesting, certainly; but IMHO unwise to nail down too tightly. > At present, we have the following discrete pieces of information > mentioned in the post-BoF charter: > > (1) Routing preferences > (2) Priority values These are a bit amorphous... > (3) AS numbers Sometimes very useful; sometimes not... > (4) Geographic location Often wildly inaccurate, and even more often quite unrelated to network topology. Would be _very_ useful in an alternate universe where routing found next-hops _physically_ closer to the destination... > Add to this the two more: > > (5) Policies Clearly potentially useful > (6) Topology Useful, but hard to use without latency measurments (and IMHO also indicators of congestion). > 1, 2, and 5 are something that the network operator is in possession > of. Each BGP router will have these, very likely reflecting configuration choices of the ISP. But I'm not convinced they're useful unless you know you'll pass through that router. Even then, what you actually experience is the aggregate of all routers you pass through... > 3 and 4 can be gleaned in some manner (probably not using > any standardized APIs but well known services, nonetheless.) AS numbers are reasonably accurately gleaned; geographic location is not nearly as accurate. > 6 can be provided by the network operator or approximated using > synthetic coordinate systems and the like. Actual topology is likely to change without warning; so you should be prepared for it to prove wildly inaccurate. More often than not, it turns out to be only roughly approximated or hopelessly optimistic. > Information that has been deemed out of scope based on list > discussion is: > > (1) Last hop bandwidth The most useful number yet listed, _if_ folks will give it to us and we interpret it correctly... > (reason: too much uncertainty -- are we talking about upload or > download bandwidth? Both, of course (though too often the upstream dominates). > Provisioned band-width or current snapshot? Provisioned, of course (though it would be good to know penalty-box bandwidth too) > User privacy concerns, ISP marketing concerns, etc. These are by no means limited to last-hop bandwidth. _Any_ question we might ask might generate a "none of your business" reply -- we need to allow for that. Besides, last-hop bandwidth (provisioned) can't really be hidden. If the ISP doesn't want to provide it, a third party can... > In short, while this is a good research problem, it may not be a > good piece of information to be provided by ALTO.) We'd be foolish to design a protocol which _isn't_ also good as a research tool. _Every_ content supplier will want research done. IMHO, ruling out anything except content-IDs (if insufficiently obfuscated to be of no interest to DCMA lawyers) is unwise. OTOH, expecting _any_ particular query to always receive a useful reply is naive. > What other sort of information should be a focus of ALTO? It would be rather useful to have "characteristics that indicate congestion" on a path. The applications are going to have to judge instantaneous congestion anyway, and basing that judgment on known characteristics rather than guesswork should speed progress towards an optimal mix. Jitter in the latency will be of interest to certain applications. -- John Leslie _______________________________________________ p2pi mailing list p2pi@ietf.org https://www.ietf.org/mailman/listinfo/p2pi From p2pi-bounces@ietf.org Thu Aug 14 14:10: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 034563A685C; Thu, 14 Aug 2008 14:10: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 918A23A67E7 for ; Thu, 14 Aug 2008 14:10:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.179 X-Spam-Level: X-Spam-Status: No, score=-10.179 tagged_above=-999 required=5 tests=[AWL=0.086, 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 ZdBLvokN8vw7 for ; Thu, 14 Aug 2008 14:10:12 -0700 (PDT) Received: from dkny.pando.com (dkny.pando.com [67.99.55.163]) by core3.amsl.com (Postfix) with ESMTP id 9BD243A6801 for ; Thu, 14 Aug 2008 14:10:12 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by dkny.pando.com (Postfix) with ESMTP id DB2EEE10A97; Thu, 14 Aug 2008 17:10:16 -0400 (EDT) X-Virus-Scanned: amavisd-new at Received: from dkny.pando.com ([127.0.0.1]) by localhost (dkny.pando.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MmfF9b3PT5Td; Thu, 14 Aug 2008 17:10:04 -0400 (EDT) Received: from dkny.pando.com (dkny.pando.com [10.10.60.11]) by dkny.pando.com (Postfix) with ESMTP id 819C6E10BA5; Thu, 14 Aug 2008 17:10:04 -0400 (EDT) Date: Thu, 14 Aug 2008 17:10:04 -0400 (EDT) From: Laird Popkin To: John Leslie Message-ID: <326422674.153451218748204493.JavaMail.root@dkny.pando.com> In-Reply-To: <20080814204249.GS25453@verdi> MIME-Version: 1.0 X-Originating-IP: [69.38.142.83] Cc: p2pi@ietf.org Subject: Re: [p2pi] Information in an ALTO protocol X-BeenThere: p2pi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: P2P Infrastructure Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: 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 very good discussion. Responding to the comment that topology is "Useful, but hard to use without latency measurments (and IMHO also indicators of congestion)." I would agree that a realtime, detailed topology would be very hard to provide. But even a broad, static topology has a lot of value, and that's easier to provide. That is, if an ISP can provide a list of IP prefixes that identify users in a metro area, and adjacent metro areas, we can connect people based on that and improve performance and efficiency, without knowing anything about the physical network or individual link status. Also keep in mind that ALTO only guides initial peer selection (i.e. the endpoints of the streams). The transport layer (BGP, etc.) guides the actual routing of the data, and the applications adapt based on observed throughput. So ALTO doesn't have to solve everything (congestion, real-time conditions) to be useful - it just has to be better than not knowing anything. - Laird Popkin, CTO, Pando Networks mobile: 646/465-0570 ----- Original Message ----- From: "John Leslie" To: "Vijay K. Gurbani" Cc: p2pi@ietf.org Sent: Thursday, August 14, 2008 1:42:49 PM (GMT-0800) America/Los_Angeles Subject: Re: [p2pi] Information in an ALTO protocol Vijay K. Gurbani wrote: > > I think that which parameters to gather will turn out to be an > interesting topic to nail down. Interesting, certainly; but IMHO unwise to nail down too tightly. > At present, we have the following discrete pieces of information > mentioned in the post-BoF charter: > > (1) Routing preferences > (2) Priority values These are a bit amorphous... > (3) AS numbers Sometimes very useful; sometimes not... > (4) Geographic location Often wildly inaccurate, and even more often quite unrelated to network topology. Would be _very_ useful in an alternate universe where routing found next-hops _physically_ closer to the destination... > Add to this the two more: > > (5) Policies Clearly potentially useful > (6) Topology Useful, but hard to use without latency measurments (and IMHO also indicators of congestion). > 1, 2, and 5 are something that the network operator is in possession > of. Each BGP router will have these, very likely reflecting configuration choices of the ISP. But I'm not convinced they're useful unless you know you'll pass through that router. Even then, what you actually experience is the aggregate of all routers you pass through... > 3 and 4 can be gleaned in some manner (probably not using > any standardized APIs but well known services, nonetheless.) AS numbers are reasonably accurately gleaned; geographic location is not nearly as accurate. > 6 can be provided by the network operator or approximated using > synthetic coordinate systems and the like. Actual topology is likely to change without warning; so you should be prepared for it to prove wildly inaccurate. More often than not, it turns out to be only roughly approximated or hopelessly optimistic. > Information that has been deemed out of scope based on list > discussion is: > > (1) Last hop bandwidth The most useful number yet listed, _if_ folks will give it to us and we interpret it correctly... > (reason: too much uncertainty -- are we talking about upload or > download bandwidth? Both, of course (though too often the upstream dominates). > Provisioned band-width or current snapshot? Provisioned, of course (though it would be good to know penalty-box bandwidth too) > User privacy concerns, ISP marketing concerns, etc. These are by no means limited to last-hop bandwidth. _Any_ question we might ask might generate a "none of your business" reply -- we need to allow for that. Besides, last-hop bandwidth (provisioned) can't really be hidden. If the ISP doesn't want to provide it, a third party can... > In short, while this is a good research problem, it may not be a > good piece of information to be provided by ALTO.) We'd be foolish to design a protocol which _isn't_ also good as a research tool. _Every_ content supplier will want research done. IMHO, ruling out anything except content-IDs (if insufficiently obfuscated to be of no interest to DCMA lawyers) is unwise. OTOH, expecting _any_ particular query to always receive a useful reply is naive. > What other sort of information should be a focus of ALTO? It would be rather useful to have "characteristics that indicate congestion" on a path. The applications are going to have to judge instantaneous congestion anyway, and basing that judgment on known characteristics rather than guesswork should speed progress towards an optimal mix. Jitter in the latency will be of interest to certain applications. -- 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 Sun Aug 17 21:31: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 E86C33A6AC0; Sun, 17 Aug 2008 21:31: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 51FC73A6AC0 for ; Sun, 17 Aug 2008 21:31:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.053 X-Spam-Level: X-Spam-Status: No, score=0.053 tagged_above=-999 required=5 tests=[AWL=0.052, 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 5hPucqKz42ck for ; Sun, 17 Aug 2008 21:31:29 -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 633C23A6A70 for ; Sun, 17 Aug 2008 21:31:29 -0700 (PDT) Received: by wf-out-1314.google.com with SMTP id 27so2011072wfd.31 for ; Sun, 17 Aug 2008 21:31:36 -0700 (PDT) Received: by 10.142.49.4 with SMTP id w4mr1893022wfw.201.1219033895615; Sun, 17 Aug 2008 21:31:35 -0700 (PDT) Received: from ?192.168.1.100? ( [67.188.243.194]) by mx.google.com with ESMTPS id 30sm3557560wfc.5.2008.08.17.21.31.34 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sun, 17 Aug 2008 21:31:35 -0700 (PDT) Message-Id: <050C2347-3540-44CB-BB25-8A9EA7CB314A@shlang.com> From: Stanislav Shalunov To: Sebastian Kiesel In-Reply-To: <20080814145914.GA6284@foo.nw.neclab.eu> Mime-Version: 1.0 (Apple Message framework v926) Date: Sun, 17 Aug 2008 21:31:32 -0700 References: <489B498B.4040804@telecomitalia.it> <20080811143531.GA18911@net.t-labs.tu-berlin.de> <119D7BAE-4CBB-4BCE-BB3C-594FC6234AB6@shlang.com> <20080814145914.GA6284@foo.nw.neclab.eu> X-Mailer: Apple Mail (2.926) Cc: p2pi@ietf.org Subject: Re: [p2pi] Information in an ALTO protocol X-BeenThere: p2pi@ietf.org 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 Live P2P video streaming is an interesting research problem, so far not solved. The business case has also not been proven, with different companies targeting very different uses, from UGC to TV distribution to screencasting. Improving the efficiency of an application that does not yet exist should probably not be in scope for ALTO. As a side note, I don't think the metric of lag is particularly interesting to optimize, and, therefore, I'll be happy to have our competitors use it. The two right metrics are in different units. But let's not go too far down the path of discussing an interesting research topic. -- Stas On Aug 14, 2008, at 7:59 AM, Sebastian Kiesel wrote: > Hi, > > "total transfer rate divided by total upload capacity" is a good > measure > of swarm efficiency if the application is file sharing. > > p2p live video streaming (an application which might gain much > relevance > till the time when a potential ALTO workgroup would deliver their > first > specifications) has differenent metrics: the system can only be stable > if the video stream's bitrate is lower than the average upload > capacity, > i.e., not all uplinks will be saturated by this application. > > The interesting metric is the lag, i.e., the delay of the video stream > between injection into the swarm and playout (measured individually > per > node or as average in the swarm). It can be reduced if nodes with > higher > upload capacity or shorter transport delay from the source are placed > closer to the source in the logical topology. The incentive for a user > to offer more upload capacity to the swarm is to get a smaller > individual lag. > > While p2p algorithms can converge to a "good" state, ALTO guidance > would > be very beneficial if it could speed up that process. This is very > relevant here as many users switch TV channels (streams) frequently. > > Any thoughts? > > Thanks, > Sebastian > > > On Mon, Aug 11, 2008 at 06:16:44PM -0700, Stanislav Shalunov wrote: >> This might be workable and interesting, but here are a few concerns: >> >> 1. For this to be useful, an ISP would need to provide an >> unobfuscated >> third-party service that will tell the world what service plan I >> bought. >> As a user, I'd have a bit of discomfort with it, but the ISP would >> probably >> be a lot more concerned about telling its competitors the fraction >> of its >> customers whom they upsold on a premium plan. I suspect this might >> be a >> real show-stopper. >> >> 2. Nominal provisioned bandwidth on DSL is only an upper bound for >> the >> actual negotiated bandwidth. The negotiation takes a few seconds >> after the >> modem starts and routinely results in lower-than-nominal rates for >> longer >> distances to CO. >> >> 3. While it's obvious that an individual peer will, in the current >> world, >> do better trading with fat-uplink partners, I'm skeptical of >> possibility of >> substantial increases in swarm throughput, which determines the >> average >> outcome. Consider the measure of swarm efficiency: total transfer >> rate >> divided by total upload capacity. I posit that swarm efficiency is >> usually >> quite high, and the only real slack is on super-fast peers in colos >> and >> such. Home connection uplinks are so narrow that it does not take >> much to >> saturate them. >> >> -- Stas > > > > > > -- > Sebastian Kiesel mailto:sebastian.kiesel@nw.neclab.eu > Network Research Division tel:+49-6221-4342-232 fax: > +49-6221-4342-155 > NEC Laboratories Europe Kurfuerstenanlage 36, 69115 Heidelberg, > Germany > -- > NEC Europe Limited Registered in England 2832014 > Registered Office NEC House, 1 Victoria Road, London W3 6BL -- Stanislav Shalunov _______________________________________________ p2pi mailing list p2pi@ietf.org https://www.ietf.org/mailman/listinfo/p2pi From p2pi-bounces@ietf.org Mon Aug 18 01:08: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 EB8803A6990; Mon, 18 Aug 2008 01:08: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 888E328C0E0 for ; Mon, 18 Aug 2008 01:08:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.002 X-Spam-Level: X-Spam-Status: No, score=0.002 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Hagnwq1KNTjT for ; Mon, 18 Aug 2008 01:08:31 -0700 (PDT) Received: from mout.perfora.net (mout.perfora.net [74.208.4.194]) by core3.amsl.com (Postfix) with ESMTP id D91B33A6843 for ; Mon, 18 Aug 2008 01:08:30 -0700 (PDT) Received: from viceroy (c-24-130-57-189.hsd1.ca.comcast.net [24.130.57.189]) by mrelay.perfora.net (node=mrus0) with ESMTP (Nemesis) id 0MKp8S-1KUzmK0jfC-0003gs; Mon, 18 Aug 2008 04:08:01 -0400 From: "Stas Khirman" To: , Date: Mon, 18 Aug 2008 01:07:50 -0700 Message-ID: <004601c90109$844b9890$6500a8c0@viceroy> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0047_01C900CE.D7ECC090" X-Mailer: Microsoft Office Outlook 11 Thread-Index: AckBCYHpAk/nXoimStKiXtQgM06R5w== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 X-Provags-ID: V01U2FsdGVkX19zLxKAMG2wAhzeyg2KXtCC7vmk+hcbIZIAHyn fadMOipqa83T3T5lDM1FOs1CwmSiUeuRYyyeAJlqtJhQlNky+P R9b20lk9dDC3otHoTiJSA== Subject: [p2pi] Real life torrent statistics X-BeenThere: p2pi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: P2P Infrastructure Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: p2pi-bounces@ietf.org Errors-To: p2pi-bounces@ietf.org This is a multi-part message in MIME format. ------=_NextPart_000_0047_01C900CE.D7ECC090 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0048_01C900CE.D7ECC090" ------=_NextPart_001_0048_01C900CE.D7ECC090 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To estimate a feasibility of ALTO/P4P for real life torrents , I collected information for peers from one of the most popular "PirateBay" torrents ( almost 20k peers) and maped their IPs to corresponded ASs. Please find attached my working notes with some interesting statistics. In short - for such kind of swarm (20k peers), almost half of peers belong to ASs with 100 or more peers, almost 2/3 of peers belong to ASs with 50 or more peers. Less then 15% of peers belong to ASs with 10 or less "neighbors". US broadband ISPs (Road Runner, Comcast, AT&T) have about 2-3% of total peers each. Also, I find it surprising geo distribution of the peers - majority were in UK , not in US (probably because content is available in US theaters). Places 3-5 taken by Sweden, Poland and Canada (in total - more peers then in US). Certainly, observed "heavy" neighboring of peers is a function of swarm size. I intend to investigate a few medium/small size swarms to have a multi-point picture for any future discussions. I would appreciate comments, corrections and additional ideas on data collection and analysis. ------=_NextPart_001_0048_01C900CE.D7ECC090 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

To estimate a feasibility of ALTO/P4P for real life = torrents , I collected <ip,port> information for peers from one of the most popular “PirateBay” torrents ( almost 20k peers) and maped = their IPs to corresponded ASs. Please find attached my working notes with some interesting statistics.

 

In short – for such kind of swarm (20k peers), = almost half of peers belong to ASs with 100 or more peers, almost 2/3 of peers = belong to ASs with 50 or more peers. Less then 15% of peers belong to ASs with = 10 or less “neighbors”.

 

US broadband ISPs (Road Runner, Comcast, AT&T) = have about 2-3% of total peers each.

 

Also, I find it surprising geo distribution of the = peers – majority were in UK , not in US (probably because content is available in US theaters). =  Places 3-5 taken by Sweden, Poland and Canada (in total – = more peers then in US).

 

Certainly, observed “heavy” neighboring = of peers is a function of swarm size. I intend to investigate a few medium/small = size swarms to have a multi-point picture for any future = discussions.

 

I would appreciate comments, corrections and = additional ideas on data collection and analysis.

------=_NextPart_001_0048_01C900CE.D7ECC090-- ------=_NextPart_000_0047_01C900CE.D7ECC090 Content-Type: application/msword; name="torrent_distribution.doc" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="torrent_distribution.doc" 0M8R4KGxGuEAAAAAAAAAAAAAAAAAAAAAPgADAP7/CQAGAAAAAAAAAAAAAAADAAAATAEAAAAAAAAA EAAATgEAAAEAAAD+////AAAAAEkBAABKAQAASwEAAP////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////s pcEAJWAJBAAA+BK/AAAAAAAAEAAAAAAABgAAnh8AAA4AYmpiaq71rvUAAAAAAAAAAAAAAAAAAAAA AAAJBBYALvgAAMyfAADMnwAAnhcAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAD//w8AAAAA AAAAAAD//w8AAAAAAAAAAAD//w8AAAAAAAAAAAAAAAAAAAAAAKQAAAAAAEwEAAAAAAAATAQAAEwE AAAAAAAATAQAAAAAAABMBAAAAAAAAEwEAAAAAAAATAQAABQAAAAAAAAAAAAAAGAEAAAAAAAAiIgA AAAAAACIiAAAAAAAAIiIAAAAAAAAiIgAACwAAAC0iAAANAMAAGAEAAAAAAAAVaoAAA4BAAD0iwAA AAAAAPSLAAAAAAAA9IsAAAAAAAD0iwAAAAAAAPSLAAAAAAAAz4wAAEIAAAARjQAAHAAAAC2NAAAQ AAAA1KkAAAIAAADWqQAAAAAAANapAAAAAAAA1qkAAAAAAADWqQAAAAAAANapAAAAAAAA1qkAACQA AABjqwAAaAIAAMutAAB2AAAA+qkAABUAAAAAAAAAAAAAAAAAAAAAAAAATAQAAAAAAABukQAAAAAA AAAAAAAAAAAAAAAAAAAAAADPjAAAAAAAAM+MAAAAAAAAbpEAAAAAAABukQAAAAAAAPqpAAAAAAAA AAAAAAAAAABMBAAAAAAAAEwEAAAAAAAA9IsAAAAAAAAAAAAAAAAAAPSLAADbAAAAD6oAABYAAABI lwAAAAAAAEiXAAAAAAAASJcAAAAAAABukQAAbgIAAEwEAAAAAAAA9IsAAAAAAABMBAAAAAAAAPSL AAAAAAAA1KkAAAAAAAAAAAAAAAAAAEiXAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAbpEAAAAAAADUqQAAAAAAAAAAAAAAAAAASJcAAAAAAAAAAAAA AAAAAEiXAAAAAAAATAQAAAAAAABMBAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAASJcAAAAAAAD0iwAAAAAAAOiLAAAMAAAAEFmIrQgB yQEAAAAAAAAAAIiIAAAAAAAA3JMAAKYAAABIlwAAAAAAAAAAAAAAAAAA6JkAAOwPAAAlqgAAMAAA AFWqAAAAAAAASJcAAAAAAABBrgAAAAAAAIKUAABWAgAAQa4AAAAAAABIlwAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABI lwAApAAAAEGuAAAAAAAAAAAAAAAAAABMBAAAAAAAAOyXAAD8AQAAPY0AAFYBAACTjgAA9AAAAEiX AAAAAAAAh48AAMQAAABLkAAAIwEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAPY0A AAAAAAA9jQAAAAAAAD2NAAAAAAAA+qkAAAAAAAD6qQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAA2JYAAHAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAD2NAAAA AAAAPY0AAAAAAAA9jQAAAAAAAFWqAAAAAAAAbpEAAAAAAABukQAAAAAAAG6RAAAAAAAAbpEAAAAA AAAAAAAAAAAAAGAEAAAAAAAAYAQAAAAAAABgBAAA5EMAAERIAABEQAAAYAQAAAAAAABgBAAAAAAA AGAEAAAAAAAAREgAAAAAAABgBAAAAAAAAGAEAAAAAAAAYAQAAAAAAABMBAAAAAAAAEwEAAAAAAAA TAQAAAAAAABMBAAAAAAAAEwEAAAAAAAATAQAAAAAAAD/////AAAAAAIADAEAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA1Db2xs ZWN0ZWQgZGF0YS4NDVRvcnJlbnQHSGVsbGJveS4yLlRoZS5Hb2xkZW4uQXJteS5SNS5MSU5FLlhW aUQtUFVLS0EudG9ycmVudAcHSW5mb19oYXNoBzIyYTkzNWZjYzVkY2IwMjQ1Nzc3ODFjNmY2MWNm MzRjNzNlZjIzNTQHB01lYXN1cmVtZW50IHRha2VuIGJldHdlZW4HMjAwOC8wOC8xNiAxNTo0NTox MCBVVEMgYW5kCzIwMDgvMDgvMTYgMTk6NDU6NDQgVVRDBwdTd2FybSBwZWVycyByZXBvcnRlZCBi eSB0cmFja2VyIGF0IHRoZSBlbmQgb2YgbWVhc3VyZW1lbnQgcGVyaW9kOgdMZWNoZXJzIC0gMTAz MzUgDVNlZWRlcnMgliA4OTk0DVRvdGFsIC0gMTkzMjkHB1BlZXJzIGNvbGxlY3RlZCAodW5pcXVl IGlwOnBvcnQpBzE5MzMzBwcNDVRoaXMgdG9ycmVudCByZXByZXNlbnRzIGJvb3RsZWdnZWQgY29w eSBvZiAgIG1vdmllIHJlbGVhc2VkIEp1bHkgMTEgLCAyMDA4IGZvciBzY3JlZW5pbmcgaW4gVVMg YW5kIENhbmFkYSwgYnV0IG5vdCB5ZXQgbGVnYWxseSBhdmFpbGFibGUgaW4gb3RoZXIgY291bnRy aWVzDQ2TSVAgdG8gZ2VvlCBhbmQgk0lQIHRvIEFTlCBtYXBwaW5nIGhhZCBiZWVuIHBlcmZvcm1l ZCB1c2luZyBXSE9JUyBzZXJ2aWNlIGZyb20gd2hvaXMuY3ltcnUuY29tIC4gDQ1UQkQ6IFNvbWUg c21hbGwgbnVtYmVyIG9mIHBlZXJzIGJlbG9uZyB0byCTcGlyYWN5IHRyYWNraW5nlCBjb21wYW5p ZXMgYW5kIG5lZWQgdG8gYmUgcmVtb3ZlZCBpbiB0aGUgZnV0dXJlIGFuYWx5c2lzIC4NDUdlbyBk aXN0cmlidXRpb24uDQ0xMCBjb3VudHJpZXMgd2l0aCBhIGxhcmdlc3QgbnVtYmVyIG9mIHBlZXJz DQ1jb3VudHJ5B1BlZXJzByUgb2YgdG90YWwHB0dCIAczODkyBzIwLjEHB1VTIAcyODMwBzE0LjYH B1NFIAcxMTQ1BzUuOQcHUEwgBzEwNTIHNS40BwdDQSAHOTExBzQuNwcHQlIgBzg0Mwc0LjMHB0FV IAc4MTcHNC4yBwdOTyAHNjM5BzMuMwcHTkwgBzU2MQcyLjkHB0ZJIAczNzMHMS45BwcNDSBJdCBp cyBlYXN5IHRvIGV4cGxhaW4gd2h5IEdCIGhhcyBtb3JlIHBlZXJzIHRoZW4gVVMgliBtb3ZpZSBp cyB3aWRlbHkgYXZhaWxhYmxlIGluIFVTIG1vdmllIHRoZWF0ZXJzICwgYnV0IEdCIHB1YmxpYyB0 byB3YWl0IGEgZmV3IG1vbnRocyB1bnRpbCBvZmZpY2lhbCByZWxlYXNlIGluIHRoZWlyIGNvdW50 cnkuIEhvd2V2ZXIsIGl0IGhhcmQgdG8gZXhwbGFpbiB1bnVzdWFsbHkgaGlnaCBwb3B1bGFyaXR5 IG9mIHRoaXMgbW92aWUgaW4gU3dlZGVuIGFuZCBQb2xhbmQuDQ1UQkQ6IGNhbGN1bGF0ZSBudW1i ZXIgb2YgcGVlcnMgYXMgcGVyY2VudGFnZSBvZiCTYnJvYWRiYW5klCBwb3B1bGF0aW9uIGluIHRo ZSBjb3JyZXNwb25kaW5nIGNvdW50cmllcy4NDUFTIGRpc3RyaWJ1dGlvbg0NMjAgbW9zdCBwb3B1 bGFyIEF1dG9ub21vdXMgU3lzdGVtcw1hc24HY291bnRyeQdpc3AHcGVlcnMHJSBvZiB0b3RhbAcH Mjg1NgdHQiAHQlQtVUstQVMgQlRuZXQgVUsgUmVnaW9uYWwgbmV0d29yawc3NjIHMy45Bwc1MDg5 B0dCIAdOVEwgTlRMIEdyb3VwIExpbWl0ZWQHNzM2BzMuOAcHNTQ2MgdHQiAHQ0FCTEVJTkVUIFRl bGV3ZXN0IEJyb2FkYmFuZAc1NjcHMi45BwcyMTE5B05PIAdURUxFTk9SLU5FWFRFTCBULm5ldAc1 MzAHMi43Bwc0NTg5B0dCIAdFQVNZTkVUIEVhc3luZXQgR3JvdXAgUGxjBzUyNAcyLjcHBzU2MTcH UEwgB1RQTkVUIFBvbGlzaCBUZWxlY29tX3MgY29tbWVyY2lhbCBJUCBuZXR3b3JrBzQyMwcyLjIH BzcxMzIHVVMgB1NCSVMtQVMgLSBBVCZUIEludGVybmV0IFNlcnZpY2VzBzM5MAcyLjAHBzQzMjM0 B0dCIAdDUFdCQlNFUlYtQVMgQ2FycGhvbmUgV2FyZWhvdXNlIEJyb2FkYmFuZCBTZXJ2aWNlcwcz NDIHMS44BwczMzAxB1NFIAdURUxJQU5FVC1TV0VERU4gVGVsaWFOZXQgU3dlZGVuBzMzNAcxLjcH BzEzMjg1B0dCIAdPUEFMVEVMRUNPTS1BUyBPcGFsIFRlbGVjb20HMjY3BzEuNAcHOTEwNQdHQiAH VElTQ0FMSS1VSyBUaXNjYWxpIFVLBzI1NgcxLjMHBzE5MjYyB1VTIAdWWkdOSS1UUkFOU0lUIC0g VmVyaXpvbiBJbnRlcm5ldCBTZXJ2aWNlcyBJbmMuBzI0MQcxLjIHBzY4MzAHTkwgB1VQQyBVUEMg QnJvYWRiYW5kBzIzOQcxLjIHBzQ3ODgHTVkgB1RNTkVULUFTLUFQIFRNIE5ldCwgSW50ZXJuZXQg U2VydmljZSBQcm92aWRlcgcyMzgHMS4yBwc3NzM4B0JSIAdUZWxlY29tdW5pY2Fjb2VzIGRhIEJh aGlhIFMuQS4HMjIzBzEuMgcHMzk2NTEHU0UgB0NPTUhFTS1TV0VERU4gQ29tIEhlbSBTd2VkZW4H MjIzBzEuMgcHNjMyNwdDQSAHU0hBVyAtIFNoYXcgQ29tbXVuaWNhdGlvbnMgSW5jLgcxOTYHMS4w BwczMjkyB0ZJIAdUREMgVERDIERhdGEgTmV0d29ya3MHMTgyBzAuOQcHODEyB0NBIAdST0dFUlMt Q0FCTEUgLSBSb2dlcnMgQ2FibGUgQ29tbXVuaWNhdGlvbnMgSW5jLgcxNzcHMC45Bwc0ODA0B0FV IAdNUFgtQVMgTWljcm9wbGV4IFBUWSBMVEQHMTczBzAuOQcHDTIwIG1vc3QgcG9wdWxhciBBU3Mg aW4gVVNBDWFzbgdjb3VudHJ5B2lzcAdwZWVycwclIG9mIHRvdGFsBwc3MTMyB1VTIAdTQklTLUFT IC0gQVQmVCBJbnRlcm5ldCBTZXJ2aWNlcwczOTAHMi4wBwcxOTI2MgdVUyAHVlpHTkktVFJBTlNJ VCAtIFZlcml6b24gSW50ZXJuZXQgU2VydmljZXMgSW5jLgcyNDEHMS4yBwcyMjc3MwdVUyAHQ0NJ TkVULTIgLSBDb3ggQ29tbXVuaWNhdGlvbnMgSW5jLgc5MQcwLjUHBzYzODkHVVMgB0JFTExTT1VU SC1ORVQtQkxLIC0gQmVsbFNvdXRoLm5ldCBJbmMuBzkxBzAuNQcHMzMyODcHVVMgB0RORU8tT1NQ NCAtIENvbWNhc3QgQ2FibGUgQ29tbXVuaWNhdGlvbnMsIEluYy4HNzQHMC40BwcyMDExNQdVUyAH Q0hBUlRFUi1ORVQtSEtZLU5DIC0gQ2hhcnRlciBDb21tdW5pY2F0aW9ucwc3NAcwLjQHBzMzNjUx B1VTIAdETkVPLU9TUDcgLSBDb21jYXN0IENhYmxlIENvbW11bmljYXRpb25zLCBJbmMuBzcxBzAu NAcHMjA5B1VTIAdBU04tUVdFU1QgLSBRd2VzdAc2NAcwLjMHBzExNDI3B1VTIAdTQ1JSLTExNDI3 IC0gUm9hZCBSdW5uZXIgSG9sZENvIExMQwc2NAcwLjMHBzIwMjE0B1VTIAdDQ0NILUFTNiAtIENv bWNhc3QgQ2FibGUgQ29tbXVuaWNhdGlvbnMgSG9sZGluZ3MsIEluYwc2MwcwLjMHBzMzNDkxB1VT IAdETkVPLU9TUDcgLSBDb21jYXN0IENhYmxlIENvbW11bmljYXRpb25zLCBJbmMuBzYwBzAuMwcH NjEyOAdVUyAHQ0FCTEUtTkVULTEgLSBDYWJsZXZpc2lvbiBTeXN0ZW1zIENvcnAuBzU2BzAuMwcH MTE0MjYHVVMgB1NDUlItMTE0MjYgLSBSb2FkIFJ1bm5lciBIb2xkQ28gTExDBzU0BzAuMwcHNzAx NQdVUyAHQ0NDSC1BUzIgLSBDb21jYXN0IENhYmxlIENvbW11bmljYXRpb25zIEhvbGRpbmdzLCBJ bmMHNTIHMC4zBwcxMzM0MwdVUyAHU0NSUi0xMzM0MyAtIFJvYWQgUnVubmVyIEhvbGRDbyBMTEMH NTEHMC4zBwczMzY1MAdVUyAHRE5FTy1PU1A3IC0gQ29tY2FzdCBDYWJsZSBDb21tdW5pY2F0aW9u cywgSW5jLgc0OAcwLjIHBzE5MTA4B1VTIAdTVURERU5MSU5LLUNPTU1VTklDQVRJT05TIC0gU3Vk ZGVubGluayBDb21tdW5pY2F0aW9ucwc0NgcwLjIHBzEyMjcxB1VTIAdTQ1JSLTEyMjcxIC0gUm9h ZCBSdW5uZXIgSG9sZENvIExMQwc0NgcwLjIHBzIwMDAxB1VTIAdST0FEUlVOTkVSLVdFU1QgLSBS b2FkIFJ1bm5lciBIb2xkQ28gTExDBzQ0BzAuMgcHDQ1Tb21lIElTUHMgaGFzIG11bHRpcGxlIEFT cyAuIFRoZSBmb2xsb3dpbmcgYWdncmVnYXRlZCB0YWJsZXMgdXNlIJNuYW1llCBhdHRyaWJ1dGUg b2YgQVMgbmFtZSB0byBncm91cCBwZWVycyBwZXIgYSBjb21tb24gSVNQLiBOb3RlOiBzb21lIElT UHMgbWF5IGhhdmUgbXVsdGlwbGUgbmFtZXMgaW4gQVMgYXNzaWdubWVudCB0YWJsZXMuIEZvciBl eGFtcGxlLCBDb21jYXN0IHJlcHJlc2VudGVkIGJ5IJNDb21jYXN0IENhYmxlIENvbW11bmljYXRp b25zLCBJbmMulCBhbmQgk0NvbWNhc3QgQ2FibGUgQ29tbXVuaWNhdGlvbnMgSG9sZGluZ3MsIElu Y5QuIEN1cnJlbnRseSBJIGhhdmUgbm8gaW5mb3JtYXRpb24gaWYgdGhvc2UgQVNzIHJlcHJlc2Vu dCB0aGUgc2FtZSBraW5kIG9mIG5ldHdvcmsgb3Igc29tZSBtYXkgYmVsb25nIHRvIHJlbnRlZC1v dXQgc2VnbWVudCBhbmQgc28gb26FIA0NMjAgbW9zdCBwb3B1bGFyIElTUHMgd29ybGR3aWRlDWNv dW50cnkHbmFtZQdwZWVyByVvZiB0b3RhbAcHR0IgB0FTIEJUbmV0IFVLIFJlZ2lvbmFsIG5ldHdv cmsHNzYyBzMuOTM5BwdHQiAHTlRMIE5UTCBHcm91cCBMaW1pdGVkBzczNgczLjgwNDYHB0dCIAdD QUJMRUlORVQgVGVsZXdlc3QgQnJvYWRiYW5kBzU2NwcyLjkzMQcHTk8gB05FWFRFTCBULm5ldAc1 MzAHMi43Mzk3BwdHQiAHRUFTWU5FVCBFYXN5bmV0IEdyb3VwIFBsYwc1MjQHMi43MDg3BwdVUyAH IFJvYWQgUnVubmVyIEhvbGRDbyBMTEMHNDU0BzIuMzQ2OQcHVVMgByBDb21jYXN0IENhYmxlIENv bW11bmljYXRpb25zLCBJbmMuBzQ0OQcyLjMyMQcHUEwgB1RQTkVUIFBvbGlzaCBUZWxlY29tX3Mg Y29tbWVyY2lhbCBJUCBuZXR3b3JrBzQyMwcyLjE4NjYHB1VTIAcgQVQmVCBJbnRlcm5ldCBTZXJ2 aWNlcwczOTAHMi4wMTYHB0dCIAdBUyBDYXJwaG9uZSBXYXJlaG91c2UgQnJvYWRiYW5kIFNlcnZp Y2VzBzM0MgcxLjc2NzkHB1NFIAdTV0VERU4gVGVsaWFOZXQgU3dlZGVuBzMzNAcxLjcyNjUHB0dC IAdBUyBPcGFsIFRlbGVjb20HMjY3BzEuMzgwMgcHR0IgB1VLIFRpc2NhbGkgVUsHMjU2BzEuMzIz MwcHVVMgByBWZXJpem9uIEludGVybmV0IFNlcnZpY2VzIEluYy4HMjQxBzEuMjQ1OAcHTkwgB1VQ QyBVUEMgQnJvYWRiYW5kBzIzOQcxLjIzNTUHB01ZIAdBUCBUTSBOZXQsIEludGVybmV0IFNlcnZp Y2UgUHJvdmlkZXIHMjM4BzEuMjMwMwcHU0UgB1NXRURFTiBDb20gSGVtIFN3ZWRlbgcyMjMHMS4x NTI4BwdCUiAHVGVsZWNvbXVuaWNhY29lcyBkYSBCYWhpYSBTLkEuBzIyMwcxLjE1MjgHB1VTIAcg Q29tY2FzdCBDYWJsZSBDb21tdW5pY2F0aW9ucyBIb2xkaW5ncywgSW5jBzIyMgcxLjE0NzYHBw0N MjAgbW9zdCBwb3B1bGFyIElTUHMgaW4gVVNBDW5hbWUHcGVlcnMHJSBvZiB0b3RhbAcHIFJvYWQg UnVubmVyIEhvbGRDbyBMTEMHNDU0BzIuMzQ2OQcHIENvbWNhc3QgQ2FibGUgQ29tbXVuaWNhdGlv bnMsIEluYy4HNDQ5BzIuMzIxBwcgQVQmVCBJbnRlcm5ldCBTZXJ2aWNlcwczOTAHMi4wMTYHByBW ZXJpem9uIEludGVybmV0IFNlcnZpY2VzIEluYy4HMjQxBzEuMjQ1OAcHIENvbWNhc3QgQ2FibGUg Q29tbXVuaWNhdGlvbnMgSG9sZGluZ3MsIEluYwcyMjIHMS4xNDc2BwcgQ294IENvbW11bmljYXRp b25zIEluYy4HMTI1BzAuNjQ2MgcHIENoYXJ0ZXIgQ29tbXVuaWNhdGlvbnMHMTA5BzAuNTYzNQcH IEJlbGxTb3V0aC5uZXQgSW5jLgc5NAcwLjQ4NTkHByBRd2VzdAc2NAcwLjMzMDgHByBDYWJsZXZp c2lvbiBTeXN0ZW1zIENvcnAuBzU2BzAuMjg5NQcHIFN1ZGRlbmxpbmsgQ29tbXVuaWNhdGlvbnMH NDYHMC4yMzc4BwcgQVQmVCBXb3JsZE5ldCBTZXJ2aWNlcwc0NQcwLjIzMjYHByBFbWJhcnEgQ29y cG9yYXRpb24HMzQHMC4xNzU4BwcgV2luZHN0cmVhbSBDb21tdW5pY2F0aW9ucyBJbmMHMjkHMC4x NDk5BwcgQ2VudHVyeVRlbCBJbnRlcm5ldCBIb2xkaW5ncywgSW5jLgcxOAcwLjA5MwcHIEJlbGxT b3V0aCBOZXR3b3JrIFNvbHV0aW9ucywgSW5jBzE4BzAuMDkzBwcgSU5TSUdIVCBDT01NVU5JQ0FU SU9OUyBDT01QQU5ZLCBMLlAuBzE3BzAuMDg3OQcHIEZyb250aWVyIENvbW11bmljYXRpb25zIG9m IEFtZXJpY2EsIEluYy4HMTYHMC4wODI3BwcgU3ByaW50IFBlcnNvbmFsIENvbW11bmljYXRpb25z IFN5c3RlbXMHMTYHMC4wODI3BwcgUkNOIENvcnBvcmF0aW9uBzE0BzAuMDcyNAcHDQ1Ib3cgbWFu eSBwZWVycyByZXNpZGUgaW4gk3BvcHVsYXKUIEFTcyA/DQENDQdDdW11bGF0aXZlIG51bWJlciBv ZiBwZWVycwcHUGVlcnMgaW4gQVNzIHdpdGggMTAwIG9yIG1vcmUgcGVlcnMHNDYuOTYgJSBvZiB0 b3RhbAcHUGVlcnMgaW4gQVNzIHdpdGggNTAgb3IgbW9yZSBwZWVycwc2NC40NyAlIG9mIHRvdGFs BwdQZWVycyBpbiBBU3Mgd2l0aCAxMCBvciBtb3JlIHBlZXJzBzg2LjAzICUgb2YgdG90YWwHBw0A AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAGAAABCAAAEAgAABEIAAAS CAAAGggAAE4IAABaCAAAgggAAJ4IAACiCAAAowgAAKUIAACmCAAAqAgAAKkIAACrCAAArAgAAK4I AACvCAAAsQgAALoIAAC+CAAAvwgAAMEIAADCCAAAxAgAAMUIAADHCAAAyAgAAMoIAADLCAAAzQgA ANEIAADSCAAAHwkAACQJAAAwCQAANAkAAD0JAABDCQAAZQkAAGsJAAB5CQAAmgkAAJsJAABaCgAA aQoAAGwKAABtCgAAbgoAAOQKAADlCgAA9woAACULAAAtCwAALgsAAD4LAAD89+/86+Tr5Ovd693r 3evd693r3evd693r3evd693r3evd693r3evd693r2evZzMjB2b3ZtcinmacAAAAAAAAAAAAAAAAA AAAAABoWaIMzJABDShQAT0oCAFFKAgBeSgIAYUoUAAAaFmgHLiQAQ0oUAE9KAgBRSgIAXkoCAGFK FAAADxVoBy4kABZoH0fcADUIgQYWaIMzJAAADBVoBy4kABZoH0fcAAAGFmgHLiQAABgVaAcuJAAW aAcuJAA+KgFCKglwaAAAgAAABhZoH0fcAAAMFWiHIDUAFmiHIDUAAAwVaDBk9wAWaIcgNQAABhZo hyA1AAAPFWgHLiQAFmgwZPcANQiBCRZoBy4kADUIgQYWaDBk9wA5AAYAAAEIAAARCAAAEggAABoI AABPCAAAUAgAAFoIAACDCAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA 9wAAAAAAAAAAAAAAAPcAAAAAAAAAAAAAAAB5AAAAAAAAAAAAAAAA9wAAAAAAAAAAAAAAAPcAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAfQAA a2QAAAAAFiQBFyQBSWYBAAAAApZsAAXWGAQBAAAEAQAABAEAAAQBAAAEAQAABAEAAAjWMAAClP+8 BywiAAYoCAAAAAAAAAAAAAAAAAAAAAAABnAaAAAAAAAAAAAAAAAAAAAAAAp0AADgARPWMAAAAP8E AQAAAAAA/wQBAAAAAAD/BAEAAAAAAP8EAQAAAAAA/wQBAAAAAAD/BAEAABT2AQAAFTYBF/YDAAAY 9gMAABrWCAAAAP8AAAD/G9YIAAAA/wAAAP8c1ggAAAD/AAAA/x3WCAAAAP8AAAD/NNYGAAEFAwAA NNYGAAEKA2wAYfYDAAB5dIcgNQAGAAAWJAFJZgEAAAAAAQAAAAgABgAAnh8AAP4AAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAgEBAYMIAACECAAAnggAANIIAACBAAAA AAAAAAAAAAAAewAAAAAAAAAAAAAAAHsAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAYA ABYkAUlmAQAAAAB9AABrZGUAAAAWJAEXJAFJZgEAAAAClmwABdYYBAEAAAQBAAAEAQAABAEAAAQB AAAEAQAACNYwAAKU/7wHLCIABigIAAAAAAAAAAAAAAAAAAAAAAAGcBoAAAAAAAAAAAAAAAAAAAAA CnQAAOABE9YwAAAA/wQBAAAAAAD/BAEAAAAAAP8EAQAAAAAA/wQBAAAAAAD/BAEAAAAAAP8EAQAA FPYBAAAVNgEX9gMAABj2AwAAGtYIAAAA/wAAAP8b1ggAAAD/AAAA/xzWCAAAAP8AAAD/HdYIAAAA /wAAAP801gYAAQUDAAA01gYAAQoDbABh9gMAAHl0hyA1AAAD0ggAANMIAAAVCQAAJgkAADUJAABD CQAAgQAAAAAAAAAAAAAAAHsAAAAAAAAAAAAAAAB7AAAAAAAAAAAAAAAAewAAAAAAAAAAAAAAAHsA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABgAA FiQBSWYBAAAAAH0AAGtkygAAABYkARckAUlmAQAAAAKWbAAF1hgEAQAABAEAAAQBAAAEAQAABAEA AAQBAAAI1jAAApT/vAcsIgAGKAgAAAAAAAAAAAAAAAAAAAAAAAZwGgAAAAAAAAAAAAAAAAAAAAAK dAAA4AET1jAAAAD/BAEAAAAAAP8EAQAAAAAA/wQBAAAAAAD/BAEAAAAAAP8EAQAAAAAA/wQBAAAU 9gEAABU2ARf2AwAAGPYDAAAa1ggAAAD/AAAA/xvWCAAAAP8AAAD/HNYIAAAA/wAAAP8d1ggAAAD/ AAAA/zTWBgABBQMAADTWBgABCgNsAGH2AwAAeXSHIDUAAAVDCQAARAkAAGUJAABrCQAAgQAAAAAA AAAAAAAAAHsAAAAAAAAAAAAAAAB7AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAGAAAW JAFJZgEAAAAAfQAAa2QvAQAAFiQBFyQBSWYBAAAAApZsAAXWGAQBAAAEAQAABAEAAAQBAAAEAQAA BAEAAAjWMAAClP+8BywiAAYoCAAAAAAAAAAAAAAAAAAAAAAABnAaAAAAAAAAAAAAAAAAAAAAAAp0 AADgARPWMAAAAP8EAQAAAAAA/wQBAAAAAAD/BAEAAAAAAP8EAQAAAAAA/wQBAAAAAAD/BAEAABT2 AQAAFTYBF/YDAAAY9gMAABrWCAAAAP8AAAD/G9YIAAAA/wAAAP8c1ggAAAD/AAAA/x3WCAAAAP8A AAD/NNYGAAEFAwAANNYGAAEKA2wAYfYDAAB5dIcgNQAAA2sJAABsCQAAbQkAAG4JAAAKCgAACwoA AG0KAABuCgAA5AoAAOUKAAD3CgAA+AoAACQLAAAlCwAALQsAAIEAAAAAAAAAAAAAAAB/AAAAAAAA AAAAAAAAfwAAAAAAAAAAAAAAAH8AAAAAAAAAAAAAAAB/AAAAAAAAAAAAAAAAfwAAAAAAAAAAAAAA AH8AAAAAAAAAAAAAAAB/AAAAAAAAAAAAAAAAfwAAAAAAAAAAAAAAAH8AAAAAAAAAAAAAAAB/AAAA AAAAAAAAAAAAfwAAAAAAAAAAAAAAAH8AAAAAAAAAAAAAAAB5AAAAAAAAAAAAAAAABgAAFiQBSWYB AAAAAAEAAAB9AABrZJQBAAAWJAEXJAFJZgEAAAAClmwABdYYBAEAAAQBAAAEAQAABAEAAAQBAAAE AQAACNYwAAKU/7wHLCIABigIAAAAAAAAAAAAAAAAAAAAAAAGcBoAAAAAAAAAAAAAAAAAAAAACnQA AOABE9YwAAAA/wQBAAAAAAD/BAEAAAAAAP8EAQAAAAAA/wQBAAAAAAD/BAEAAAAAAP8EAQAAFPYB AAAVNgEX9gMAABj2AwAAGtYIAAAA/wAAAP8b1ggAAAD/AAAA/xzWCAAAAP8AAAD/HdYIAAAA/wAA AP801gYAAQUDAAA01gYAAQoDbABh9gMAAHl0hyA1AAAOLQsAADMLAAA+CwAAPwsAAEMLAABICwAA TQsAAPkAAAAAAAAAAAAAAAD5AAAAAAAAAAAAAAAAgAAAAAAAAAAAAAAAAPkAAAAAAAAAAAAAAAB3 AAAAAAAAAAAAAAAAdwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAkAAAMkAhYkAUlmAQAA AGEkAnkAAGtk+QEAABYkARckAUlmAQAAAAKWbAAHlAgBCNZGAAP0/4wITAwgEwAnmAj///////// ////////////ACfAA/////////////////////8AJ9QG/////////////////////xT2AywTFTYB F/YDAAAY9gMAABrWDP///////////////xvWDP///////////////xzWDP///////////////x3W DP///////////////zTWBgABBQMAADTWBgABCgNsAGH2A2AAcNYeAAAA/wAAAP8AAAAAAP8AAAD/ AAAAAAD/AAAA/wAAeXQHLiQABgAAFiQBSWYBAAAAAAY+CwAAPwsAAE0LAABOCwAAXAsAAF0LAABq CwAAawsAAHgLAAB5CwAAhQsAAIYLAACSCwAAkwsAAJ8LAACgCwAArAsAAK0LAAC5CwAAugsAAMYL AADHCwAAyQsAAMoLAACZDAAAowwAAMoMAADWDAAA1wwAAEANAABQDQAAUQ0AAHQNAACVDQAAlg0A AMoNAADLDQAA8g0AAPMNAAAhDgAAIg4AAEgOAABJDgAAdA4AAHUOAACzDgAAtA4AAOYOAADnDgAA LA8AAC0PAABeDwAAXw8AAI0PAACODwAAtQ8AALYPAAD3DwAA+A8AABsQAAAcEAAAWxAAAFwQAABl EAAAhBAAAPjq+Or46vjq+Or46vjq+Or46vjq+Obi5t7m3tre0t7OwLjAuMC4wLjAuMC4wLjAuMC4 wLjAuMC4wLjAuMC4wKMAACgVaEkM2wAWaEkM2wBDShQAT0oCAFFKAgBeSgIAYUoUAG1ICgxzSAoM AA4WaEkM2wBDShQAYUoUAAAaFmhJDNsAQ0oUAE9KAgBRSgIAXkoCAGFKFAAABhZoSQzbAAAPFWiD MyQAFmiDMyQANQiBBhZohyA1AAAGFmiDMyQAAAYWaB9H3AAABhZoBy4kAAAaFmgHLiQAQ0oUAE9K AgBRSgIAXkoCAGFKFAAADhZoBy4kAENKFABhShQAQE0LAABOCwAAUgsAAFcLAABcCwAAhgAAAAAA AAAAAAAAAIAAAAAAAAAAAAAAAAB3AAAAAAAAAAAAAAAAdwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAJAAADJAIWJAFJZgEAAABh JAIGAAAWJAFJZgEAAAB5AABrZLICAAAWJAEXJAFJZgEAAAAClmwAB5QIAQjWRgAD9P+MCEwMIBMA J5gI/////////////////////wAnwAP/////////////////////ACfUBv////////////////// //8U9gMsExU2ARf2AwAAGPYDAAAa1gz///////////////8b1gz///////////////8c1gz///// //////////8d1gz///////////////801gYAAQUDAAA01gYAAQoDbABh9gNgAHDWHgAAAP8AAAD/ AAAAAAD/AAAA/wAAAAAA/wAAAP8AAHl0By4kAAAEXAsAAF0LAABhCwAAZgsAAGoLAACGAAAAAAAA AAAAAAAAgAAAAAAAAAAAAAAAAHcAAAAAAAAAAAAAAAB3AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAkAAAMkAhYkAUlmAQAAAGEk AgYAABYkAUlmAQAAAHkAAGtkawMAABYkARckAUlmAQAAAAKWbAAHlAgBCNZGAAP0/4wITAwgEwAn mAj/////////////////////ACfAA/////////////////////8AJ9QG//////////////////// /xT2AywTFTYBF/YDAAAY9gMAABrWDP///////////////xvWDP///////////////xzWDP////// /////////x3WDP///////////////zTWBgABBQMAADTWBgABCgNsAGH2A2AAcNYeAAAA/wAAAP8A AAAAAP8AAAD/AAAAAAD/AAAA/wAAeXQHLiQAAARqCwAAawsAAG8LAAB0CwAAeAsAAIYAAAAAAAAA AAAAAACAAAAAAAAAAAAAAAAAdwAAAAAAAAAAAAAAAHcAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACQAAAyQCFiQBSWYBAAAAYSQC BgAAFiQBSWYBAAAAeQAAa2QkBAAAFiQBFyQBSWYBAAAAApZsAAeUCAEI1kYAA/T/jAhMDCATACeY CP////////////////////8AJ8AD/////////////////////wAn1Ab///////////////////// FPYDLBMVNgEX9gMAABj2AwAAGtYM////////////////G9YM////////////////HNYM//////// ////////HdYM////////////////NNYGAAEFAwAANNYGAAEKA2wAYfYDYABw1h4AAAD/AAAA/wAA AAAA/wAAAP8AAAAAAP8AAAD/AAB5dAcuJAAABHgLAAB5CwAAfQsAAIELAACFCwAAhgAAAAAAAAAA AAAAAIAAAAAAAAAAAAAAAAB3AAAAAAAAAAAAAAAAdwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAJAAADJAIWJAFJZgEAAABhJAIG AAAWJAFJZgEAAAB5AABrZN0EAAAWJAEXJAFJZgEAAAAClmwAB5QIAQjWRgAD9P+MCEwMIBMAJ5gI /////////////////////wAnwAP/////////////////////ACfUBv////////////////////8U 9gMsExU2ARf2AwAAGPYDAAAa1gz///////////////8b1gz///////////////8c1gz///////// //////8d1gz///////////////801gYAAQUDAAA01gYAAQoDbABh9gNgAHDWHgAAAP8AAAD/AAAA AAD/AAAA/wAAAAAA/wAAAP8AAHl0By4kAAAEhQsAAIYLAACKCwAAjgsAAJILAACGAAAAAAAAAAAA AAAAgAAAAAAAAAAAAAAAAHcAAAAAAAAAAAAAAAB3AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAkAAAMkAhYkAUlmAQAAAGEkAgYA ABYkAUlmAQAAAHkAAGtklgUAABYkARckAUlmAQAAAAKWbAAHlAgBCNZGAAP0/4wITAwgEwAnmAj/ ////////////////////ACfAA/////////////////////8AJ9QG/////////////////////xT2 AywTFTYBF/YDAAAY9gMAABrWDP///////////////xvWDP///////////////xzWDP////////// /////x3WDP///////////////zTWBgABBQMAADTWBgABCgNsAGH2A2AAcNYeAAAA/wAAAP8AAAAA AP8AAAD/AAAAAAD/AAAA/wAAeXQHLiQAAASSCwAAkwsAAJcLAACbCwAAnwsAAIYAAAAAAAAAAAAA AACAAAAAAAAAAAAAAAAAdwAAAAAAAAAAAAAAAHcAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACQAAAyQCFiQBSWYBAAAAYSQCBgAA FiQBSWYBAAAAeQAAa2RPBgAAFiQBFyQBSWYBAAAAApZsAAeUCAEI1kYAA/T/jAhMDCATACeYCP// //////////////////8AJ8AD/////////////////////wAn1Ab/////////////////////FPYD LBMVNgEX9gMAABj2AwAAGtYM////////////////G9YM////////////////HNYM//////////// ////HdYM////////////////NNYGAAEFAwAANNYGAAEKA2wAYfYDYABw1h4AAAD/AAAA/wAAAAAA /wAAAP8AAAAAAP8AAAD/AAB5dAcuJAAABJ8LAACgCwAApAsAAKgLAACsCwAAhgAAAAAAAAAAAAAA AIAAAAAAAAAAAAAAAAB3AAAAAAAAAAAAAAAAdwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAJAAADJAIWJAFJZgEAAABhJAIGAAAW JAFJZgEAAAB5AABrZAgHAAAWJAEXJAFJZgEAAAAClmwAB5QIAQjWRgAD9P+MCEwMIBMAJ5gI//// /////////////////wAnwAP/////////////////////ACfUBv////////////////////8U9gMs ExU2ARf2AwAAGPYDAAAa1gz///////////////8b1gz///////////////8c1gz///////////// //8d1gz///////////////801gYAAQUDAAA01gYAAQoDbABh9gNgAHDWHgAAAP8AAAD/AAAAAAD/ AAAA/wAAAAAA/wAAAP8AAHl0By4kAAAErAsAAK0LAACxCwAAtQsAALkLAACGAAAAAAAAAAAAAAAA gAAAAAAAAAAAAAAAAHcAAAAAAAAAAAAAAAB3AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAkAAAMkAhYkAUlmAQAAAGEkAgYAABYk AUlmAQAAAHkAAGtkwQcAABYkARckAUlmAQAAAAKWbAAHlAgBCNZGAAP0/4wITAwgEwAnmAj///// ////////////////ACfAA/////////////////////8AJ9QG/////////////////////xT2AywT FTYBF/YDAAAY9gMAABrWDP///////////////xvWDP///////////////xzWDP////////////// /x3WDP///////////////zTWBgABBQMAADTWBgABCgNsAGH2A2AAcNYeAAAA/wAAAP8AAAAAAP8A AAD/AAAAAAD/AAAA/wAAeXQHLiQAAAS5CwAAugsAAL4LAADCCwAAxgsAAIYAAAAAAAAAAAAAAACA AAAAAAAAAAAAAAAAdwAAAAAAAAAAAAAAAHcAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACQAAAyQCFiQBSWYBAAAAYSQCBgAAFiQB SWYBAAAAeQAAa2R6CAAAFiQBFyQBSWYBAAAAApZsAAeUCAEI1kYAA/T/jAhMDCATACeYCP////// //////////////8AJ8AD/////////////////////wAn1Ab/////////////////////FPYDLBMV NgEX9gMAABj2AwAAGtYM////////////////G9YM////////////////HNYM//////////////// HdYM////////////////NNYGAAEFAwAANNYGAAEKA2wAYfYDYABw1h4AAAD/AAAA/wAAAAAA/wAA AP8AAAAAAP8AAAD/AAB5dAcuJAAABMYLAADHCwAAyAsAAMkLAADXDAAA2AwAAD8NAABADQAAUA0A AFENAAB0DQAAeA0AAIANAACEDQAAig0AAIYAAAAAAAAAAAAAAACEAAAAAAAAAAAAAAAAhAAAAAAA AAAAAAAAAIQAAAAAAAAAAAAAAACEAAAAAAAAAAAAAAAAhAAAAAAAAAAAAAAAAIQAAAAAAAAAAAAA AACEAAAAAAAAAAAAAAAAhAAAAAAAAAAAAAAAAIQAAAAAAAAAAAAAAAB+AAAAAAAAAAAAAAAAfgAA AAAAAAAAAAAAAH4AAAAAAAAAAAAAAAB+AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAYAABYkAUlmAQAA AAABAAB5AABrZDMJAAAWJAEXJAFJZgEAAAAClmwAB5QIAQjWRgAD9P+MCEwMIBMAJ5gI//////// /////////////wAnwAP/////////////////////ACfUBv////////////////////8U9gMsExU2 ARf2AwAAGPYDAAAa1gz///////////////8b1gz///////////////8c1gz///////////////8d 1gz///////////////801gYAAQUDAAA01gYAAQoDbABh9gNgAHDWHgAAAP8AAAD/AAAAAAD/AAAA /wAAAAAA/wAAAP8AAHl0By4kAAAOig0AAJUNAACWDQAAmw0AAJ8NAADCDQAAxg0AAMoNAAD5AAAA AAAAAAAAAAAAUAAAAAAAAAAAAAAAAEcAAAAAAAAAAAAAAAD5AAAAAAAAAAAAAAAA+QAAAAAAAAAA AAAAAEcAAAAAAAAAAAAAAABHAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAkAAAMkAhYk AUlmAQAAAGEkAqkAAGtk7AkAABYkARckAUlmAQAAAAKWbAAHlAgBCNZyAAX0//kCCAffGTwe8yEA JwUD/////////////////////wAnDwT/////////////////////ACfXEv////////////////// //8AJ10E/////////////////////wAntwP/////////////////////FPYD/yEVNgEX9gMAABj2 AwAAGtYU//////////////////////////8b1hT//////////////////////////xzWFP////// ////////////////////HdYU//////////////////////////801gYAAQUDAAA01gYAAQoDbABh 9gNgAHDWMgAAAP8AAAD/AAAAAAD/AAAA/wAAAAAA/wAAAP8AAAAAAP8AAAD/AAAAAAD/AAAA/wAA eXRJDNsABgAAFiQBSWYBAAAAAAfKDQAAyw0AANANAADUDQAA6g0AAO4NAADyDQAAVgAAAAAAAAAA AAAAAE0AAAAAAAAAAAAAAABHAAAAAAAAAAAAAAAARwAAAAAAAAAAAAAAAE0AAAAAAAAAAAAAAABN AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABgAAFiQBSWYB AAAACQAAAyQCFiQBSWYBAAAAYSQCqQAAa2TlCgAAFiQBFyQBSWYBAAAAApZsAAeUCAEI1nIABfT/ +QIIB98ZPB7zIQAnBQP/////////////////////ACcPBP////////////////////8AJ9cS//// /////////////////wAnXQT/////////////////////ACe3A/////////////////////8U9gP/ IRU2ARf2AwAAGPYDAAAa1hT//////////////////////////xvWFP////////////////////// ////HNYU//////////////////////////8d1hT//////////////////////////zTWBgABBQMA ADTWBgABCgNsAGH2A2AAcNYyAAAA/wAAAP8AAAAAAP8AAAD/AAAAAAD/AAAA/wAAAAAA/wAAAP8A AAAAAP8AAAD/AAB5dEkM2wAABvINAADzDQAA+A0AAPwNAAAZDgAAHQ4AACEOAABWAAAAAAAAAAAA AAAATQAAAAAAAAAAAAAAAEcAAAAAAAAAAAAAAABHAAAAAAAAAAAAAAAATQAAAAAAAAAAAAAAAE0A AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAGAAAWJAFJZgEA AAAJAAADJAIWJAFJZgEAAABhJAKpAABrZN4LAAAWJAEXJAFJZgEAAAAClmwAB5QIAQjWcgAF9P/5 AggH3xk8HvMhACcFA/////////////////////8AJw8E/////////////////////wAn1xL///// ////////////////ACddBP////////////////////8AJ7cD/////////////////////xT2A/8h FTYBF/YDAAAY9gMAABrWFP//////////////////////////G9YU//////////////////////// //8c1hT//////////////////////////x3WFP//////////////////////////NNYGAAEFAwAA NNYGAAEKA2wAYfYDYABw1jIAAAD/AAAA/wAAAAAA/wAAAP8AAAAAAP8AAAD/AAAAAAD/AAAA/wAA AAAA/wAAAP8AAHl0SQzbAAAGIQ4AACIOAAAnDgAAKw4AAEAOAABEDgAASA4AAFYAAAAAAAAAAAAA AABNAAAAAAAAAAAAAAAARwAAAAAAAAAAAAAAAEcAAAAAAAAAAAAAAABNAAAAAAAAAAAAAAAATQAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAYAABYkAUlmAQAA AAkAAAMkAhYkAUlmAQAAAGEkAqkAAGtk1wwAABYkARckAUlmAQAAAAKWbAAHlAgBCNZyAAX0//kC CAffGTwe8yEAJwUD/////////////////////wAnDwT/////////////////////ACfXEv////// //////////////8AJ10E/////////////////////wAntwP/////////////////////FPYD/yEV NgEX9gMAABj2AwAAGtYU//////////////////////////8b1hT///////////////////////// /xzWFP//////////////////////////HdYU//////////////////////////801gYAAQUDAAA0 1gYAAQoDbABh9gNgAHDWMgAAAP8AAAD/AAAAAAD/AAAA/wAAAAAA/wAAAP8AAAAAAP8AAAD/AAAA AAD/AAAA/wAAeXRJDNsAAAZIDgAASQ4AAE4OAABSDgAAbA4AAHAOAAB0DgAAVgAAAAAAAAAAAAAA AE0AAAAAAAAAAAAAAABHAAAAAAAAAAAAAAAARwAAAAAAAAAAAAAAAE0AAAAAAAAAAAAAAABNAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABgAAFiQBSWYBAAAA CQAAAyQCFiQBSWYBAAAAYSQCqQAAa2TQDQAAFiQBFyQBSWYBAAAAApZsAAeUCAEI1nIABfT/+QII B98ZPB7zIQAnBQP/////////////////////ACcPBP////////////////////8AJ9cS//////// /////////////wAnXQT/////////////////////ACe3A/////////////////////8U9gP/IRU2 ARf2AwAAGPYDAAAa1hT//////////////////////////xvWFP////////////////////////// HNYU//////////////////////////8d1hT//////////////////////////zTWBgABBQMAADTW BgABCgNsAGH2A2AAcNYyAAAA/wAAAP8AAAAAAP8AAAD/AAAAAAD/AAAA/wAAAAAA/wAAAP8AAAAA AP8AAAD/AAB5dEkM2wAABnQOAAB1DgAAeg4AAH4OAACrDgAArw4AALMOAABWAAAAAAAAAAAAAAAA TQAAAAAAAAAAAAAAAEcAAAAAAAAAAAAAAABHAAAAAAAAAAAAAAAATQAAAAAAAAAAAAAAAE0AAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAGAAAWJAFJZgEAAAAJ AAADJAIWJAFJZgEAAABhJAKpAABrZMkOAAAWJAEXJAFJZgEAAAAClmwAB5QIAQjWcgAF9P/5AggH 3xk8HvMhACcFA/////////////////////8AJw8E/////////////////////wAn1xL///////// ////////////ACddBP////////////////////8AJ7cD/////////////////////xT2A/8hFTYB F/YDAAAY9gMAABrWFP//////////////////////////G9YU//////////////////////////8c 1hT//////////////////////////x3WFP//////////////////////////NNYGAAEFAwAANNYG AAEKA2wAYfYDYABw1jIAAAD/AAAA/wAAAAAA/wAAAP8AAAAAAP8AAAD/AAAAAAD/AAAA/wAAAAAA /wAAAP8AAHl0SQzbAAAGsw4AALQOAAC5DgAAvQ4AAN4OAADiDgAA5g4AAFYAAAAAAAAAAAAAAABN AAAAAAAAAAAAAAAARwAAAAAAAAAAAAAAAEcAAAAAAAAAAAAAAABNAAAAAAAAAAAAAAAATQAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAYAABYkAUlmAQAAAAkA AAMkAhYkAUlmAQAAAGEkAqkAAGtkwg8AABYkARckAUlmAQAAAAKWbAAHlAgBCNZyAAX0//kCCAff GTwe8yEAJwUD/////////////////////wAnDwT/////////////////////ACfXEv////////// //////////8AJ10E/////////////////////wAntwP/////////////////////FPYD/yEVNgEX 9gMAABj2AwAAGtYU//////////////////////////8b1hT//////////////////////////xzW FP//////////////////////////HdYU//////////////////////////801gYAAQUDAAA01gYA AQoDbABh9gNgAHDWMgAAAP8AAAD/AAAAAAD/AAAA/wAAAAAA/wAAAP8AAAAAAP8AAAD/AAAAAAD/ AAAA/wAAeXRJDNsAAAbmDgAA5w4AAO0OAADxDgAAJA8AACgPAAAsDwAAVgAAAAAAAAAAAAAAAE0A AAAAAAAAAAAAAABHAAAAAAAAAAAAAAAARwAAAAAAAAAAAAAAAE0AAAAAAAAAAAAAAABNAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABgAAFiQBSWYBAAAACQAA AyQCFiQBSWYBAAAAYSQCqQAAa2S7EAAAFiQBFyQBSWYBAAAAApZsAAeUCAEI1nIABfT/+QIIB98Z PB7zIQAnBQP/////////////////////ACcPBP////////////////////8AJ9cS//////////// /////////wAnXQT/////////////////////ACe3A/////////////////////8U9gP/IRU2ARf2 AwAAGPYDAAAa1hT//////////////////////////xvWFP//////////////////////////HNYU //////////////////////////8d1hT//////////////////////////zTWBgABBQMAADTWBgAB CgNsAGH2A2AAcNYyAAAA/wAAAP8AAAAAAP8AAAD/AAAAAAD/AAAA/wAAAAAA/wAAAP8AAAAAAP8A AAD/AAB5dEkM2wAABiwPAAAtDwAAMg8AADYPAABWDwAAWg8AAF4PAABWAAAAAAAAAAAAAAAATQAA AAAAAAAAAAAAAEcAAAAAAAAAAAAAAABHAAAAAAAAAAAAAAAATQAAAAAAAAAAAAAAAE0AAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAGAAAWJAFJZgEAAAAJAAAD JAIWJAFJZgEAAABhJAKpAABrZLQRAAAWJAEXJAFJZgEAAAAClmwAB5QIAQjWcgAF9P/5AggH3xk8 HvMhACcFA/////////////////////8AJw8E/////////////////////wAn1xL///////////// ////////ACddBP////////////////////8AJ7cD/////////////////////xT2A/8hFTYBF/YD AAAY9gMAABrWFP//////////////////////////G9YU//////////////////////////8c1hT/ /////////////////////////x3WFP//////////////////////////NNYGAAEFAwAANNYGAAEK A2wAYfYDYABw1jIAAAD/AAAA/wAAAAAA/wAAAP8AAAAAAP8AAAD/AAAAAAD/AAAA/wAAAAAA/wAA AP8AAHl0SQzbAAAGXg8AAF8PAABlDwAAaQ8AAIUPAACJDwAAjQ8AAFYAAAAAAAAAAAAAAABNAAAA AAAAAAAAAAAARwAAAAAAAAAAAAAAAEcAAAAAAAAAAAAAAABNAAAAAAAAAAAAAAAATQAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAYAABYkAUlmAQAAAAkAAAMk AhYkAUlmAQAAAGEkAqkAAGtkrRIAABYkARckAUlmAQAAAAKWbAAHlAgBCNZyAAX0//kCCAffGTwe 8yEAJwUD/////////////////////wAnDwT/////////////////////ACfXEv////////////// //////8AJ10E/////////////////////wAntwP/////////////////////FPYD/yEVNgEX9gMA ABj2AwAAGtYU//////////////////////////8b1hT//////////////////////////xzWFP// ////////////////////////HdYU//////////////////////////801gYAAQUDAAA01gYAAQoD bABh9gNgAHDWMgAAAP8AAAD/AAAAAAD/AAAA/wAAAAAA/wAAAP8AAAAAAP8AAAD/AAAAAAD/AAAA /wAAeXRJDNsAAAaNDwAAjg8AAJMPAACXDwAArQ8AALEPAAC1DwAAVgAAAAAAAAAAAAAAAE0AAAAA AAAAAAAAAABHAAAAAAAAAAAAAAAARwAAAAAAAAAAAAAAAE0AAAAAAAAAAAAAAABNAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABgAAFiQBSWYBAAAACQAAAyQC FiQBSWYBAAAAYSQCqQAAa2SmEwAAFiQBFyQBSWYBAAAAApZsAAeUCAEI1nIABfT/+QIIB98ZPB7z IQAnBQP/////////////////////ACcPBP////////////////////8AJ9cS//////////////// /////wAnXQT/////////////////////ACe3A/////////////////////8U9gP/IRU2ARf2AwAA GPYDAAAa1hT//////////////////////////xvWFP//////////////////////////HNYU//// //////////////////////8d1hT//////////////////////////zTWBgABBQMAADTWBgABCgNs AGH2A2AAcNYyAAAA/wAAAP8AAAAAAP8AAAD/AAAAAAD/AAAA/wAAAAAA/wAAAP8AAAAAAP8AAAD/ AAB5dEkM2wAABrUPAAC2DwAAvA8AAMAPAADvDwAA8w8AAPcPAABWAAAAAAAAAAAAAAAATQAAAAAA AAAAAAAAAEcAAAAAAAAAAAAAAABHAAAAAAAAAAAAAAAATQAAAAAAAAAAAAAAAE0AAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAGAAAWJAFJZgEAAAAJAAADJAIW JAFJZgEAAABhJAKpAABrZJ8UAAAWJAEXJAFJZgEAAAAClmwAB5QIAQjWcgAF9P/5AggH3xk8HvMh ACcFA/////////////////////8AJw8E/////////////////////wAn1xL///////////////// ////ACddBP////////////////////8AJ7cD/////////////////////xT2A/8hFTYBF/YDAAAY 9gMAABrWFP//////////////////////////G9YU//////////////////////////8c1hT///// /////////////////////x3WFP//////////////////////////NNYGAAEFAwAANNYGAAEKA2wA YfYDYABw1jIAAAD/AAAA/wAAAAAA/wAAAP8AAAAAAP8AAAD/AAAAAAD/AAAA/wAAAAAA/wAAAP8A AHl0SQzbAAAG9w8AAPgPAAD9DwAAARAAABMQAAAXEAAAGxAAAFYAAAAAAAAAAAAAAABNAAAAAAAA AAAAAAAARwAAAAAAAAAAAAAAAEcAAAAAAAAAAAAAAABNAAAAAAAAAAAAAAAATQAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAYAABYkAUlmAQAAAAkAAAMkAhYk AUlmAQAAAGEkAqkAAGtkmBUAABYkARckAUlmAQAAAAKWbAAHlAgBCNZyAAX0//kCCAffGTwe8yEA JwUD/////////////////////wAnDwT/////////////////////ACfXEv////////////////// //8AJ10E/////////////////////wAntwP/////////////////////FPYD/yEVNgEX9gMAABj2 AwAAGtYU//////////////////////////8b1hT//////////////////////////xzWFP////// ////////////////////HdYU//////////////////////////801gYAAQUDAAA01gYAAQoDbABh 9gNgAHDWMgAAAP8AAAD/AAAAAAD/AAAA/wAAAAAA/wAAAP8AAAAAAP8AAAD/AAAAAAD/AAAA/wAA eXRJDNsAAAYbEAAAHBAAACEQAAAlEAAAUxAAAFcQAABbEAAAVgAAAAAAAAAAAAAAAE0AAAAAAAAA AAAAAABHAAAAAAAAAAAAAAAARwAAAAAAAAAAAAAAAE0AAAAAAAAAAAAAAABNAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABgAAFiQBSWYBAAAACQAAAyQCFiQB SWYBAAAAYSQCqQAAa2SRFgAAFiQBFyQBSWYBAAAAApZsAAeUCAEI1nIABfT/+QIIB98ZPB7zIQAn BQP/////////////////////ACcPBP////////////////////8AJ9cS//////////////////// /wAnXQT/////////////////////ACe3A/////////////////////8U9gP/IRU2ARf2AwAAGPYD AAAa1hT//////////////////////////xvWFP//////////////////////////HNYU//////// //////////////////8d1hT//////////////////////////zTWBgABBQMAADTWBgABCgNsAGH2 A2AAcNYyAAAA/wAAAP8AAAAAAP8AAAD/AAAAAAD/AAAA/wAAAAAA/wAAAP8AAAAAAP8AAAD/AAB5 dEkM2wAABlsQAABcEAAAYRAAAGUQAACEEAAAiBAAAIwQAABWAAAAAAAAAAAAAAAATQAAAAAAAAAA AAAAAEcAAAAAAAAAAAAAAABHAAAAAAAAAAAAAAAATQAAAAAAAAAAAAAAAE0AAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAGAAAWJAFJZgEAAAAJAAADJAIWJAFJ ZgEAAABhJAKpAABrZIoXAAAWJAEXJAFJZgEAAAAClmwAB5QIAQjWcgAF9P/5AggH3xk8HvMhACcF A/////////////////////8AJw8E/////////////////////wAn1xL///////////////////// ACddBP////////////////////8AJ7cD/////////////////////xT2A/8hFTYBF/YDAAAY9gMA ABrWFP//////////////////////////G9YU//////////////////////////8c1hT///////// /////////////////x3WFP//////////////////////////NNYGAAEFAwAANNYGAAEKA2wAYfYD YABw1jIAAAD/AAAA/wAAAAAA/wAAAP8AAAAAAP8AAAD/AAAAAAD/AAAA/wAAAAAA/wAAAP8AAHl0 SQzbAAAGhBAAAIwQAACNEAAAvBAAAL0QAADuEAAA7xAAABYRAAAXEQAAVxEAAFgRAACCEQAAgxEA AIQRAACfEQAAwBEAAMERAADzEQAA9BEAADUSAAA2EgAAahIAAGsSAACiEgAAoxIAAOMSAADkEgAA IRMAACITAABiEwAAYxMAAIQTAACFEwAAuhMAALsTAAACFAAAAxQAAEMUAABEFAAAfBQAAH0UAACy FAAAsxQAAPkUAAD6FAAALxUAADAVAABwFQAAcRUAALgVAAC5FQAA7hUAAO8VAAApFgAAKhYAACsW AAAPFwAAEBcAADIXAAA5FwAAYxcAAOoXAADrFwAACxgAACcYAADy6vLq8ury6vLq8urm4tTM1MzU zNTM1MzUzNTM1MzUzNTM1MzUzNTM1MzUzNTM1MzUzNTM1MziyMS9xL3EtsioAAAAAAAAAAAAAAAA GhZoVEPhAENKFABPSgIAUUoCAF5KAgBhShQAAAwVaBNdiAAWaFRD4QAADBVoE12IABZoE12IAAAG FmgTXYgAAAYWaFRD4QAADhZoGTTnAENKFABhShQAABoWaBk05wBDShQAT0oCAFFKAgBeSgIAYUoU AAAGFmgZNOcAAAYWaIMzJAAADhZoSQzbAENKFABhShQAABoWaEkM2wBDShQAT0oCAFFKAgBeSgIA YUoUAECMEAAAjRAAAJMQAACXEAAAtBAAALgQAAC8EAAAVgAAAAAAAAAAAAAAAE0AAAAAAAAAAAAA AABHAAAAAAAAAAAAAAAARwAAAAAAAAAAAAAAAE0AAAAAAAAAAAAAAABNAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABgAAFiQBSWYBAAAACQAAAyQCFiQBSWYB AAAAYSQCqQAAa2SDGAAAFiQBFyQBSWYBAAAAApZsAAeUCAEI1nIABfT/+QIIB98ZPB7zIQAnBQP/ ////////////////////ACcPBP////////////////////8AJ9cS/////////////////////wAn XQT/////////////////////ACe3A/////////////////////8U9gP/IRU2ARf2AwAAGPYDAAAa 1hT//////////////////////////xvWFP//////////////////////////HNYU//////////// //////////////8d1hT//////////////////////////zTWBgABBQMAADTWBgABCgNsAGH2A2AA cNYyAAAA/wAAAP8AAAAAAP8AAAD/AAAAAAD/AAAA/wAAAAAA/wAAAP8AAAAAAP8AAAD/AAB5dEkM 2wAABrwQAAC9EAAAwhAAAMYQAADmEAAA6hAAAO4QAABWAAAAAAAAAAAAAAAATQAAAAAAAAAAAAAA AEcAAAAAAAAAAAAAAABHAAAAAAAAAAAAAAAATQAAAAAAAAAAAAAAAE0AAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAGAAAWJAFJZgEAAAAJAAADJAIWJAFJZgEA AABhJAKpAABrZHwZAAAWJAEXJAFJZgEAAAAClmwAB5QIAQjWcgAF9P/5AggH3xk8HvMhACcFA/// //////////////////8AJw8E/////////////////////wAn1xL/////////////////////ACdd BP////////////////////8AJ7cD/////////////////////xT2A/8hFTYBF/YDAAAY9gMAABrW FP//////////////////////////G9YU//////////////////////////8c1hT///////////// /////////////x3WFP//////////////////////////NNYGAAEFAwAANNYGAAEKA2wAYfYDYABw 1jIAAAD/AAAA/wAAAAAA/wAAAP8AAAAAAP8AAAD/AAAAAAD/AAAA/wAAAAAA/wAAAP8AAHl0SQzb AAAG7hAAAO8QAAD0EAAA+BAAAA4RAAASEQAAFhEAAFYAAAAAAAAAAAAAAABNAAAAAAAAAAAAAAAA RwAAAAAAAAAAAAAAAEcAAAAAAAAAAAAAAABNAAAAAAAAAAAAAAAATQAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAYAABYkAUlmAQAAAAkAAAMkAhYkAUlmAQAA AGEkAqkAAGtkdRoAABYkARckAUlmAQAAAAKWbAAHlAgBCNZyAAX0//kCCAffGTwe8yEAJwUD//// /////////////////wAnDwT/////////////////////ACfXEv////////////////////8AJ10E /////////////////////wAntwP/////////////////////FPYD/yEVNgEX9gMAABj2AwAAGtYU //////////////////////////8b1hT//////////////////////////xzWFP////////////// ////////////HdYU//////////////////////////801gYAAQUDAAA01gYAAQoDbABh9gNgAHDW MgAAAP8AAAD/AAAAAAD/AAAA/wAAAAAA/wAAAP8AAAAAAP8AAAD/AAAAAAD/AAAA/wAAeXRJDNsA AAYWEQAAFxEAABsRAAAfEQAATxEAAFMRAABXEQAAVgAAAAAAAAAAAAAAAE0AAAAAAAAAAAAAAABH AAAAAAAAAAAAAAAARwAAAAAAAAAAAAAAAE0AAAAAAAAAAAAAAABNAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABgAAFiQBSWYBAAAACQAAAyQCFiQBSWYBAAAA YSQCqQAAa2RuGwAAFiQBFyQBSWYBAAAAApZsAAeUCAEI1nIABfT/+QIIB98ZPB7zIQAnBQP///// ////////////////ACcPBP////////////////////8AJ9cS/////////////////////wAnXQT/ ////////////////////ACe3A/////////////////////8U9gP/IRU2ARf2AwAAGPYDAAAa1hT/ /////////////////////////xvWFP//////////////////////////HNYU//////////////// //////////8d1hT//////////////////////////zTWBgABBQMAADTWBgABCgNsAGH2A2AAcNYy AAAA/wAAAP8AAAAAAP8AAAD/AAAAAAD/AAAA/wAAAAAA/wAAAP8AAAAAAP8AAAD/AAB5dEkM2wAA BlcRAABYEQAAXREAAGERAAB6EQAAfhEAAIIRAABWAAAAAAAAAAAAAAAATQAAAAAAAAAAAAAAAEcA AAAAAAAAAAAAAABHAAAAAAAAAAAAAAAATQAAAAAAAAAAAAAAAE0AAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAGAAAWJAFJZgEAAAAJAAADJAIWJAFJZgEAAABh JAKpAABrZGccAAAWJAEXJAFJZgEAAAAClmwAB5QIAQjWcgAF9P/5AggH3xk8HvMhACcFA/////// //////////////8AJw8E/////////////////////wAn1xL/////////////////////ACddBP// //////////////////8AJ7cD/////////////////////xT2A/8hFTYBF/YDAAAY9gMAABrWFP// ////////////////////////G9YU//////////////////////////8c1hT///////////////// /////////x3WFP//////////////////////////NNYGAAEFAwAANNYGAAEKA2wAYfYDYABw1jIA AAD/AAAA/wAAAAAA/wAAAP8AAAAAAP8AAAD/AAAAAAD/AAAA/wAAAAAA/wAAAP8AAHl0SQzbAAAG ghEAAIMRAACEEQAAnxEAAKMRAACrEQAArxEAALURAADAEQAAVgAAAAAAAAAAAAAAAFQAAAAAAAAA AAAAAABUAAAAAAAAAAAAAAAATgAAAAAAAAAAAAAAAE4AAAAAAAAAAAAAAABOAAAAAAAAAAAAAAAA TgAAAAAAAAAAAAAAAE4AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABgAAFiQBSWYBAAAAAAEA AKkAAGtkYB0AABYkARckAUlmAQAAAAKWbAAHlAgBCNZyAAX0//kCCAffGTwe8yEAJwUD//////// /////////////wAnDwT/////////////////////ACfXEv////////////////////8AJ10E//// /////////////////wAntwP/////////////////////FPYD/yEVNgEX9gMAABj2AwAAGtYU//// //////////////////////8b1hT//////////////////////////xzWFP////////////////// ////////HdYU//////////////////////////801gYAAQUDAAA01gYAAQoDbABh9gNgAHDWMgAA AP8AAAD/AAAAAAD/AAAA/wAAAAAA/wAAAP8AAAAAAP8AAAD/AAAAAAD/AAAA/wAAeXRJDNsAAAjA EQAAwREAAMYRAADKEQAA6xEAAO8RAADzEQAAVgAAAAAAAAAAAAAAAE0AAAAAAAAAAAAAAABHAAAA AAAAAAAAAAAARwAAAAAAAAAAAAAAAE0AAAAAAAAAAAAAAABNAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABgAAFiQBSWYBAAAACQAAAyQCFiQBSWYBAAAAYSQC qQAAa2RZHgAAFiQBFyQBSWYBAAAAApZsAAeUCAEI1nIABfT/+QIIByAc8B4XIgAnBQP///////// ////////////ACcPBP////////////////////8AJxgV/////////////////////wAn0AL///// ////////////////ACcnA/////////////////////8U9gMjIhU2ARf2AwAAGPYDAAAa1hT///// /////////////////////xvWFP//////////////////////////HNYU//////////////////// //////8d1hT//////////////////////////zTWBgABBQMAADTWBgABCgNsAGH2A2AAcNYyAAAA /wAAAP8AAAAAAP8AAAD/AAAAAAD/AAAA/wAAAAAA/wAAAP8AAAAAAP8AAAD/AAB5dBk05wAABvMR AAD0EQAA+hEAAP4RAAAtEgAAMRIAADUSAABWAAAAAAAAAAAAAAAATQAAAAAAAAAAAAAAAEcAAAAA AAAAAAAAAABHAAAAAAAAAAAAAAAATQAAAAAAAAAAAAAAAE0AAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAGAAAWJAFJZgEAAAAJAAADJAIWJAFJZgEAAABhJAKp AABrZFIfAAAWJAEXJAFJZgEAAAAClmwAB5QIAQjWcgAF9P/5AggHIBzwHhciACcFA/////////// //////////8AJw8E/////////////////////wAnGBX/////////////////////ACfQAv////// //////////////8AJycD/////////////////////xT2AyMiFTYBF/YDAAAY9gMAABrWFP////// ////////////////////G9YU//////////////////////////8c1hT///////////////////// /////x3WFP//////////////////////////NNYGAAEFAwAANNYGAAEKA2wAYfYDYABw1jIAAAD/ AAAA/wAAAAAA/wAAAP8AAAAAAP8AAAD/AAAAAAD/AAAA/wAAAAAA/wAAAP8AAHl0GTTnAAAGNRIA ADYSAAA8EgAAQBIAAGMSAABmEgAAahIAAFYAAAAAAAAAAAAAAABNAAAAAAAAAAAAAAAARwAAAAAA AAAAAAAAAEcAAAAAAAAAAAAAAABNAAAAAAAAAAAAAAAATQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAYAABYkAUlmAQAAAAkAAAMkAhYkAUlmAQAAAGEkAqkA AGtkSyAAABYkARckAUlmAQAAAAKWbAAHlAgBCNZyAAX0//kCCAcgHPAeFyIAJwUD//////////// /////////wAnDwT/////////////////////ACcYFf////////////////////8AJ9AC//////// /////////////wAnJwP/////////////////////FPYDIyIVNgEX9gMAABj2AwAAGtYU//////// //////////////////8b1hT//////////////////////////xzWFP////////////////////// ////HdYU//////////////////////////801gYAAQUDAAA01gYAAQoDbABh9gNgAHDWMgAAAP8A AAD/AAAAAAD/AAAA/wAAAAAA/wAAAP8AAAAAAP8AAAD/AAAAAAD/AAAA/wAAeXQZNOcAAAZqEgAA axIAAHASAAB0EgAAmxIAAJ4SAACiEgAAVgAAAAAAAAAAAAAAAE0AAAAAAAAAAAAAAABHAAAAAAAA AAAAAAAARwAAAAAAAAAAAAAAAE0AAAAAAAAAAAAAAABNAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABgAAFiQBSWYBAAAACQAAAyQCFiQBSWYBAAAAYSQCqQAA a2REIQAAFiQBFyQBSWYBAAAAApZsAAeUCAEI1nIABfT/+QIIByAc8B4XIgAnBQP///////////// ////////ACcPBP////////////////////8AJxgV/////////////////////wAn0AL///////// ////////////ACcnA/////////////////////8U9gMjIhU2ARf2AwAAGPYDAAAa1hT///////// /////////////////xvWFP//////////////////////////HNYU//////////////////////// //8d1hT//////////////////////////zTWBgABBQMAADTWBgABCgNsAGH2A2AAcNYyAAAA/wAA AP8AAAAAAP8AAAD/AAAAAAD/AAAA/wAAAAAA/wAAAP8AAAAAAP8AAAD/AAB5dBk05wAABqISAACj EgAAqRIAAK0SAADcEgAA3xIAAOMSAABWAAAAAAAAAAAAAAAATQAAAAAAAAAAAAAAAEcAAAAAAAAA AAAAAABHAAAAAAAAAAAAAAAATQAAAAAAAAAAAAAAAE0AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAGAAAWJAFJZgEAAAAJAAADJAIWJAFJZgEAAABhJAKpAABr ZD0iAAAWJAEXJAFJZgEAAAAClmwAB5QIAQjWcgAF9P/5AggHIBzwHhciACcFA/////////////// //////8AJw8E/////////////////////wAnGBX/////////////////////ACfQAv////////// //////////8AJycD/////////////////////xT2AyMiFTYBF/YDAAAY9gMAABrWFP////////// ////////////////G9YU//////////////////////////8c1hT///////////////////////// /x3WFP//////////////////////////NNYGAAEFAwAANNYGAAEKA2wAYfYDYABw1jIAAAD/AAAA /wAAAAAA/wAAAP8AAAAAAP8AAAD/AAAAAAD/AAAA/wAAAAAA/wAAAP8AAHl0GTTnAAAG4xIAAOQS AADqEgAA7hIAABoTAAAdEwAAIRMAAFYAAAAAAAAAAAAAAABNAAAAAAAAAAAAAAAARwAAAAAAAAAA AAAAAEcAAAAAAAAAAAAAAABNAAAAAAAAAAAAAAAATQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAYAABYkAUlmAQAAAAkAAAMkAhYkAUlmAQAAAGEkAqkAAGtk NiMAABYkARckAUlmAQAAAAKWbAAHlAgBCNZyAAX0//kCCAcgHPAeFyIAJwUD//////////////// /////wAnDwT/////////////////////ACcYFf////////////////////8AJ9AC//////////// /////////wAnJwP/////////////////////FPYDIyIVNgEX9gMAABj2AwAAGtYU//////////// //////////////8b1hT//////////////////////////xzWFP////////////////////////// HdYU//////////////////////////801gYAAQUDAAA01gYAAQoDbABh9gNgAHDWMgAAAP8AAAD/ AAAAAAD/AAAA/wAAAAAA/wAAAP8AAAAAAP8AAAD/AAAAAAD/AAAA/wAAeXQZNOcAAAYhEwAAIhMA ACgTAAAsEwAAWxMAAF4TAABiEwAAVgAAAAAAAAAAAAAAAE0AAAAAAAAAAAAAAABHAAAAAAAAAAAA AAAARwAAAAAAAAAAAAAAAE0AAAAAAAAAAAAAAABNAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAABgAAFiQBSWYBAAAACQAAAyQCFiQBSWYBAAAAYSQCqQAAa2Qv JAAAFiQBFyQBSWYBAAAAApZsAAeUCAEI1nIABfT/+QIIByAc8B4XIgAnBQP///////////////// ////ACcPBP////////////////////8AJxgV/////////////////////wAn0AL///////////// ////////ACcnA/////////////////////8U9gMjIhU2ARf2AwAAGPYDAAAa1hT///////////// /////////////xvWFP//////////////////////////HNYU//////////////////////////8d 1hT//////////////////////////zTWBgABBQMAADTWBgABCgNsAGH2A2AAcNYyAAAA/wAAAP8A AAAAAP8AAAD/AAAAAAD/AAAA/wAAAAAA/wAAAP8AAAAAAP8AAAD/AAB5dBk05wAABmITAABjEwAA ZxMAAGsTAAB9EwAAgBMAAIQTAABWAAAAAAAAAAAAAAAATQAAAAAAAAAAAAAAAEcAAAAAAAAAAAAA AABHAAAAAAAAAAAAAAAATQAAAAAAAAAAAAAAAE0AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAGAAAWJAFJZgEAAAAJAAADJAIWJAFJZgEAAABhJAKpAABrZCgl AAAWJAEXJAFJZgEAAAAClmwAB5QIAQjWcgAF9P/5AggHIBzwHhciACcFA/////////////////// //8AJw8E/////////////////////wAnGBX/////////////////////ACfQAv////////////// //////8AJycD/////////////////////xT2AyMiFTYBF/YDAAAY9gMAABrWFP////////////// ////////////G9YU//////////////////////////8c1hT//////////////////////////x3W FP//////////////////////////NNYGAAEFAwAANNYGAAEKA2wAYfYDYABw1jIAAAD/AAAA/wAA AAAA/wAAAP8AAAAAAP8AAAD/AAAAAAD/AAAA/wAAAAAA/wAAAP8AAHl0GTTnAAAGhBMAAIUTAACL EwAAjxMAALMTAAC2EwAAuhMAAFYAAAAAAAAAAAAAAABNAAAAAAAAAAAAAAAARwAAAAAAAAAAAAAA AEcAAAAAAAAAAAAAAABNAAAAAAAAAAAAAAAATQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAYAABYkAUlmAQAAAAkAAAMkAhYkAUlmAQAAAGEkAqkAAGtkISYA ABYkARckAUlmAQAAAAKWbAAHlAgBCNZyAAX0//kCCAcgHPAeFyIAJwUD//////////////////// /wAnDwT/////////////////////ACcYFf////////////////////8AJ9AC//////////////// /////wAnJwP/////////////////////FPYDIyIVNgEX9gMAABj2AwAAGtYU//////////////// //////////8b1hT//////////////////////////xzWFP//////////////////////////HdYU //////////////////////////801gYAAQUDAAA01gYAAQoDbABh9gNgAHDWMgAAAP8AAAD/AAAA AAD/AAAA/wAAAAAA/wAAAP8AAAAAAP8AAAD/AAAAAAD/AAAA/wAAeXQZNOcAAAa6EwAAuxMAAMET AADFEwAA+xMAAP4TAAACFAAAVgAAAAAAAAAAAAAAAE0AAAAAAAAAAAAAAABHAAAAAAAAAAAAAAAA RwAAAAAAAAAAAAAAAE0AAAAAAAAAAAAAAABNAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAABgAAFiQBSWYBAAAACQAAAyQCFiQBSWYBAAAAYSQCqQAAa2QaJwAA FiQBFyQBSWYBAAAAApZsAAeUCAEI1nIABfT/+QIIByAc8B4XIgAnBQP///////////////////// ACcPBP////////////////////8AJxgV/////////////////////wAn0AL///////////////// ////ACcnA/////////////////////8U9gMjIhU2ARf2AwAAGPYDAAAa1hT///////////////// /////////xvWFP//////////////////////////HNYU//////////////////////////8d1hT/ /////////////////////////zTWBgABBQMAADTWBgABCgNsAGH2A2AAcNYyAAAA/wAAAP8AAAAA AP8AAAD/AAAAAAD/AAAA/wAAAAAA/wAAAP8AAAAAAP8AAAD/AAB5dBk05wAABgIUAAADFAAACRQA AA0UAAA8FAAAPxQAAEMUAABWAAAAAAAAAAAAAAAATQAAAAAAAAAAAAAAAEcAAAAAAAAAAAAAAABH AAAAAAAAAAAAAAAATQAAAAAAAAAAAAAAAE0AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAGAAAWJAFJZgEAAAAJAAADJAIWJAFJZgEAAABhJAKpAABrZBMoAAAW JAEXJAFJZgEAAAAClmwAB5QIAQjWcgAF9P/5AggHIBzwHhciACcFA/////////////////////8A Jw8E/////////////////////wAnGBX/////////////////////ACfQAv////////////////// //8AJycD/////////////////////xT2AyMiFTYBF/YDAAAY9gMAABrWFP////////////////// ////////G9YU//////////////////////////8c1hT//////////////////////////x3WFP// ////////////////////////NNYGAAEFAwAANNYGAAEKA2wAYfYDYABw1jIAAAD/AAAA/wAAAAAA /wAAAP8AAAAAAP8AAAD/AAAAAAD/AAAA/wAAAAAA/wAAAP8AAHl0GTTnAAAGQxQAAEQUAABJFAAA TRQAAHUUAAB4FAAAfBQAAFYAAAAAAAAAAAAAAABNAAAAAAAAAAAAAAAARwAAAAAAAAAAAAAAAEcA AAAAAAAAAAAAAABNAAAAAAAAAAAAAAAATQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAYAABYkAUlmAQAAAAkAAAMkAhYkAUlmAQAAAGEkAqkAAGtkDCkAABYk ARckAUlmAQAAAAKWbAAHlAgBCNZyAAX0//kCCAcgHPAeFyIAJwUD/////////////////////wAn DwT/////////////////////ACcYFf////////////////////8AJ9AC//////////////////// /wAnJwP/////////////////////FPYDIyIVNgEX9gMAABj2AwAAGtYU//////////////////// //////8b1hT//////////////////////////xzWFP//////////////////////////HdYU//// //////////////////////801gYAAQUDAAA01gYAAQoDbABh9gNgAHDWMgAAAP8AAAD/AAAAAAD/ AAAA/wAAAAAA/wAAAP8AAAAAAP8AAAD/AAAAAAD/AAAA/wAAeXQZNOcAAAZ8FAAAfRQAAIMUAACH FAAAqxQAAK4UAACyFAAAVgAAAAAAAAAAAAAAAE0AAAAAAAAAAAAAAABHAAAAAAAAAAAAAAAARwAA AAAAAAAAAAAAAE0AAAAAAAAAAAAAAABNAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAABgAAFiQBSWYBAAAACQAAAyQCFiQBSWYBAAAAYSQCqQAAa2QFKgAAFiQB FyQBSWYBAAAAApZsAAeUCAEI1nIABfT/+QIIByAc8B4XIgAnBQP/////////////////////ACcP BP////////////////////8AJxgV/////////////////////wAn0AL///////////////////// ACcnA/////////////////////8U9gMjIhU2ARf2AwAAGPYDAAAa1hT///////////////////// /////xvWFP//////////////////////////HNYU//////////////////////////8d1hT///// /////////////////////zTWBgABBQMAADTWBgABCgNsAGH2A2AAcNYyAAAA/wAAAP8AAAAAAP8A AAD/AAAAAAD/AAAA/wAAAAAA/wAAAP8AAAAAAP8AAAD/AAB5dBk05wAABrIUAACzFAAAuBQAALwU AADyFAAA9RQAAPkUAABWAAAAAAAAAAAAAAAATQAAAAAAAAAAAAAAAEcAAAAAAAAAAAAAAABHAAAA AAAAAAAAAAAATQAAAAAAAAAAAAAAAE0AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAGAAAWJAFJZgEAAAAJAAADJAIWJAFJZgEAAABhJAKpAABrZP4qAAAWJAEX JAFJZgEAAAAClmwAB5QIAQjWcgAF9P/5AggHIBzwHhciACcFA/////////////////////8AJw8E /////////////////////wAnGBX/////////////////////ACfQAv////////////////////8A JycD/////////////////////xT2AyMiFTYBF/YDAAAY9gMAABrWFP////////////////////// ////G9YU//////////////////////////8c1hT//////////////////////////x3WFP////// ////////////////////NNYGAAEFAwAANNYGAAEKA2wAYfYDYABw1jIAAAD/AAAA/wAAAAAA/wAA AP8AAAAAAP8AAAD/AAAAAAD/AAAA/wAAAAAA/wAAAP8AAHl0GTTnAAAG+RQAAPoUAAAAFQAABBUA ACgVAAArFQAALxUAAFYAAAAAAAAAAAAAAABNAAAAAAAAAAAAAAAARwAAAAAAAAAAAAAAAEcAAAAA AAAAAAAAAABNAAAAAAAAAAAAAAAATQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAYAABYkAUlmAQAAAAkAAAMkAhYkAUlmAQAAAGEkAqkAAGtk9ysAABYkARck AUlmAQAAAAKWbAAHlAgBCNZyAAX0//kCCAcgHPAeFyIAJwUD/////////////////////wAnDwT/ ////////////////////ACcYFf////////////////////8AJ9AC/////////////////////wAn JwP/////////////////////FPYDIyIVNgEX9gMAABj2AwAAGtYU//////////////////////// //8b1hT//////////////////////////xzWFP//////////////////////////HdYU//////// //////////////////801gYAAQUDAAA01gYAAQoDbABh9gNgAHDWMgAAAP8AAAD/AAAAAAD/AAAA /wAAAAAA/wAAAP8AAAAAAP8AAAD/AAAAAAD/AAAA/wAAeXQZNOcAAAYvFQAAMBUAADYVAAA6FQAA aRUAAGwVAABwFQAAVgAAAAAAAAAAAAAAAE0AAAAAAAAAAAAAAABHAAAAAAAAAAAAAAAARwAAAAAA AAAAAAAAAE0AAAAAAAAAAAAAAABNAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAABgAAFiQBSWYBAAAACQAAAyQCFiQBSWYBAAAAYSQCqQAAa2TwLAAAFiQBFyQB SWYBAAAAApZsAAeUCAEI1nIABfT/+QIIByAc8B4XIgAnBQP/////////////////////ACcPBP// //////////////////8AJxgV/////////////////////wAn0AL/////////////////////ACcn A/////////////////////8U9gMjIhU2ARf2AwAAGPYDAAAa1hT///////////////////////// /xvWFP//////////////////////////HNYU//////////////////////////8d1hT///////// /////////////////zTWBgABBQMAADTWBgABCgNsAGH2A2AAcNYyAAAA/wAAAP8AAAAAAP8AAAD/ AAAAAAD/AAAA/wAAAAAA/wAAAP8AAAAAAP8AAAD/AAB5dBk05wAABnAVAABxFQAAdxUAAHsVAACx FQAAtBUAALgVAABWAAAAAAAAAAAAAAAATQAAAAAAAAAAAAAAAEcAAAAAAAAAAAAAAABHAAAAAAAA AAAAAAAATQAAAAAAAAAAAAAAAE0AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAGAAAWJAFJZgEAAAAJAAADJAIWJAFJZgEAAABhJAKpAABrZOktAAAWJAEXJAFJ ZgEAAAAClmwAB5QIAQjWcgAF9P/5AggHIBzwHhciACcFA/////////////////////8AJw8E//// /////////////////wAnGBX/////////////////////ACfQAv////////////////////8AJycD /////////////////////xT2AyMiFTYBF/YDAAAY9gMAABrWFP////////////////////////// G9YU//////////////////////////8c1hT//////////////////////////x3WFP////////// ////////////////NNYGAAEFAwAANNYGAAEKA2wAYfYDYABw1jIAAAD/AAAA/wAAAAAA/wAAAP8A AAAAAP8AAAD/AAAAAAD/AAAA/wAAAAAA/wAAAP8AAHl0GTTnAAAGuBUAALkVAAC/FQAAwxUAAOcV AADqFQAA7hUAAFYAAAAAAAAAAAAAAABNAAAAAAAAAAAAAAAARwAAAAAAAAAAAAAAAEcAAAAAAAAA AAAAAABNAAAAAAAAAAAAAAAATQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAYAABYkAUlmAQAAAAkAAAMkAhYkAUlmAQAAAGEkAqkAAGtk4i4AABYkARckAUlm AQAAAAKWbAAHlAgBCNZyAAX0//kCCAcgHPAeFyIAJwUD/////////////////////wAnDwT///// ////////////////ACcYFf////////////////////8AJ9AC/////////////////////wAnJwP/ ////////////////////FPYDIyIVNgEX9gMAABj2AwAAGtYU//////////////////////////8b 1hT//////////////////////////xzWFP//////////////////////////HdYU//////////// //////////////801gYAAQUDAAA01gYAAQoDbABh9gNgAHDWMgAAAP8AAAD/AAAAAAD/AAAA/wAA AAAA/wAAAP8AAAAAAP8AAAD/AAAAAAD/AAAA/wAAeXQZNOcAAAbuFQAA7xUAAPUVAAD5FQAAIhYA ACUWAAApFgAAVgAAAAAAAAAAAAAAAE0AAAAAAAAAAAAAAABHAAAAAAAAAAAAAAAARwAAAAAAAAAA AAAAAE0AAAAAAAAAAAAAAABNAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAABgAAFiQBSWYBAAAACQAAAyQCFiQBSWYBAAAAYSQCqQAAa2TbLwAAFiQBFyQBSWYB AAAAApZsAAeUCAEI1nIABfT/+QIIByAc8B4XIgAnBQP/////////////////////ACcPBP////// //////////////8AJxgV/////////////////////wAn0AL/////////////////////ACcnA/// //////////////////8U9gMjIhU2ARf2AwAAGPYDAAAa1hT//////////////////////////xvW FP//////////////////////////HNYU//////////////////////////8d1hT///////////// /////////////zTWBgABBQMAADTWBgABCgNsAGH2A2AAcNYyAAAA/wAAAP8AAAAAAP8AAAD/AAAA AAD/AAAA/wAAAAAA/wAAAP8AAAAAAP8AAAD/AAB5dBk05wAABikWAAAqFgAAKxYAACwWAADrFwAA 7BcAAAsYAAATGAAAGBgAAFYAAAAAAAAAAAAAAABUAAAAAAAAAAAAAAAAVAAAAAAAAAAAAAAAAFQA AAAAAAAAAAAAAABUAAAAAAAAAAAAAAAAVAAAAAAAAAAAAAAAAE4AAAAAAAAAAAAAAABOAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAYAABYkAUlmAQAAAAABAACpAABrZNQwAAAWJAEXJAFJZgEA AAAClmwAB5QIAQjWcgAF9P/5AggHIBzwHhciACcFA/////////////////////8AJw8E//////// /////////////wAnGBX/////////////////////ACfQAv////////////////////8AJycD//// /////////////////xT2AyMiFTYBF/YDAAAY9gMAABrWFP//////////////////////////G9YU //////////////////////////8c1hT//////////////////////////x3WFP////////////// ////////////NNYGAAEFAwAANNYGAAEKA2wAYfYDYABw1jIAAAD/AAAA/wAAAAAA/wAAAP8AAAAA AP8AAAD/AAAAAAD/AAAA/wAAAAAA/wAAAP8AAHl0GTTnAAAIGBgAAB0YAAAnGAAAKBgAACwYAABJ GAAATRgAAFMYAAD5AAAAAAAAAAAAAAAA+QAAAAAAAAAAAAAAAGgAAAAAAAAAAAAAAAD5AAAAAAAA AAAAAAAA+QAAAAAAAAAAAAAAAF8AAAAAAAAAAAAAAABfAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAkA AAMkAhYkAUlmAQAAAGEkApEAAGtkzTEAABYkARckAUlmAQAAAAKWbAAHlAgBCNZcAAT0//YH8Bdv G8whACcCCP////////////////////8AJ/oP/////////////////////wAnfwP///////////// ////////ACddBv////////////////////8U9gPYIRU2ARf2AwAAGPYDAAAa1hD///////////// ////////G9YQ/////////////////////xzWEP////////////////////8d1hD///////////// ////////NNYGAAEFAwAANNYGAAEKA2wAYfYDYABw1igAAAD/AAAA/wAAAAAA/wAAAP8AAAAAAP8A AAD/AAAAAAD/AAAA/wAAeXRUQ+EABgAAFiQBSWYBAAAAAAcnGAAAKBgAAFMYAABUGAAAeRgAAHoY AAClGAAAphgAAMIYAADDGAAA7BgAAO0YAAAUGQAAFRkAAEcZAABIGQAAhBkAAIUZAACrGQAArBkA AOQZAADlGQAACxoAAAwaAAArGgAALBoAAEkaAABKGgAAeRoAAHoaAACbGgAAnBoAANAaAADRGgAA 9hoAAPcaAAD7GgAAGhsAACUbAAAmGwAAYRsAAGIbAACAGwAAlhsAAJcbAAC6GwAAuxsAAOkbAADq GwAADBwAAA0cAAA4HAAAORwAAHAcAABxHAAAlRwAAJYcAAC5HAAAuhwAANgcAADZHAAA6hwAAOsc AAAQHQAAER0AADYdAAA3HQAAWR0AAFodAAB4HQAAeR0AAKIdAACjHQAA0B0AANEdAAD8HQAA/R0A AC0eAAAuHgAAYh4AAGMeAACVHgAAlh4AAPjq+Or46vjq+Or46vjq+Or46vjq+Or46vjq+Or46vjq +Or46tXq+Or40er46vjq+Or46vjq+Or46vjq+Or46vjq+Or46vjq+Or46vjq+Or46vgAAAAABhZo VEPhAAAoFWhUQ+EAFmhUQ+EAQ0oUAE9KAgBRSgIAXkoCAGFKFABtSAoMc0gKDAAaFmhUQ+EAQ0oU AE9KAgBRSgIAXkoCAGFKFAAADhZoVEPhAENKFABhShQAUlMYAABUGAAAWBgAAG4YAAByGAAAeRgA AG4AAAAAAAAAAAAAAABoAAAAAAAAAAAAAAAAaAAAAAAAAAAAAAAAAF8AAAAAAAAAAAAAAABfAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAJAAAD JAIWJAFJZgEAAABhJAIGAAAWJAFJZgEAAACRAABrZKYyAAAWJAEXJAFJZgEAAAAClmwAB5QIAQjW XAAE9P/2B/AXbxvMIQAnAgj/////////////////////ACf6D/////////////////////8AJ38D /////////////////////wAnXQb/////////////////////FPYD2CEVNgEX9gMAABj2AwAAGtYQ /////////////////////xvWEP////////////////////8c1hD/////////////////////HdYQ /////////////////////zTWBgABBQMAADTWBgABCgNsAGH2A2AAcNYoAAAA/wAAAP8AAAAAAP8A AAD/AAAAAAD/AAAA/wAAAAAA/wAAAP8AAHl0VEPhAAAFeRgAAHoYAAB+GAAAmxgAAJ8YAAClGAAA bgAAAAAAAAAAAAAAAGgAAAAAAAAAAAAAAABoAAAAAAAAAAAAAAAAXwAAAAAAAAAAAAAAAF8AAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAkAAAMk AhYkAUlmAQAAAGEkAgYAABYkAUlmAQAAAJEAAGtkfzMAABYkARckAUlmAQAAAAKWbAAHlAgBCNZc AAT0//YH8BdvG8whACcCCP////////////////////8AJ/oP/////////////////////wAnfwP/ ////////////////////ACddBv////////////////////8U9gPYIRU2ARf2AwAAGPYDAAAa1hD/ ////////////////////G9YQ/////////////////////xzWEP////////////////////8d1hD/ ////////////////////NNYGAAEFAwAANNYGAAEKA2wAYfYDYABw1igAAAD/AAAA/wAAAAAA/wAA AP8AAAAAAP8AAAD/AAAAAAD/AAAA/wAAeXRUQ+EAAAWlGAAAphgAAKoYAAC3GAAAuxgAAMIYAABu AAAAAAAAAAAAAAAAaAAAAAAAAAAAAAAAAGgAAAAAAAAAAAAAAABfAAAAAAAAAAAAAAAAXwAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACQAAAyQC FiQBSWYBAAAAYSQCBgAAFiQBSWYBAAAAkQAAa2RYNAAAFiQBFyQBSWYBAAAAApZsAAeUCAEI1lwA BPT/9gfwF28bzCEAJwII/////////////////////wAn+g//////////////////////ACd/A/// //////////////////8AJ10G/////////////////////xT2A9ghFTYBF/YDAAAY9gMAABrWEP// //////////////////8b1hD/////////////////////HNYQ/////////////////////x3WEP// //////////////////801gYAAQUDAAA01gYAAQoDbABh9gNgAHDWKAAAAP8AAAD/AAAAAAD/AAAA /wAAAAAA/wAAAP8AAAAAAP8AAAD/AAB5dFRD4QAABcIYAADDGAAAxxgAAOEYAADlGAAA7BgAAG4A AAAAAAAAAAAAAABoAAAAAAAAAAAAAAAAaAAAAAAAAAAAAAAAAF8AAAAAAAAAAAAAAABfAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAJAAADJAIW JAFJZgEAAABhJAIGAAAWJAFJZgEAAACRAABrZDE1AAAWJAEXJAFJZgEAAAAClmwAB5QIAQjWXAAE 9P/2B/AXbxvMIQAnAgj/////////////////////ACf6D/////////////////////8AJ38D//// /////////////////wAnXQb/////////////////////FPYD2CEVNgEX9gMAABj2AwAAGtYQ//// /////////////////xvWEP////////////////////8c1hD/////////////////////HdYQ//// /////////////////zTWBgABBQMAADTWBgABCgNsAGH2A2AAcNYoAAAA/wAAAP8AAAAAAP8AAAD/ AAAAAAD/AAAA/wAAAAAA/wAAAP8AAHl0VEPhAAAF7BgAAO0YAADxGAAACRkAAA0ZAAAUGQAAbgAA AAAAAAAAAAAAAGgAAAAAAAAAAAAAAABoAAAAAAAAAAAAAAAAXwAAAAAAAAAAAAAAAF8AAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAkAAAMkAhYk AUlmAQAAAGEkAgYAABYkAUlmAQAAAJEAAGtkCjYAABYkARckAUlmAQAAAAKWbAAHlAgBCNZcAAT0 //YH8BdvG8whACcCCP////////////////////8AJ/oP/////////////////////wAnfwP///// ////////////////ACddBv////////////////////8U9gPYIRU2ARf2AwAAGPYDAAAa1hD///// ////////////////G9YQ/////////////////////xzWEP////////////////////8d1hD///// ////////////////NNYGAAEFAwAANNYGAAEKA2wAYfYDYABw1igAAAD/AAAA/wAAAAAA/wAAAP8A AAAAAP8AAAD/AAAAAAD/AAAA/wAAeXRUQ+EAAAUUGQAAFRkAABkZAAA9GQAAQRkAAEcZAABuAAAA AAAAAAAAAAAAaAAAAAAAAAAAAAAAAGgAAAAAAAAAAAAAAABfAAAAAAAAAAAAAAAAXwAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACQAAAyQCFiQB SWYBAAAAYSQCBgAAFiQBSWYBAAAAkQAAa2TjNgAAFiQBFyQBSWYBAAAAApZsAAeUCAEI1lwABPT/ 9gfwF28bzCEAJwII/////////////////////wAn+g//////////////////////ACd/A/////// //////////////8AJ10G/////////////////////xT2A9ghFTYBF/YDAAAY9gMAABrWEP////// //////////////8b1hD/////////////////////HNYQ/////////////////////x3WEP////// //////////////801gYAAQUDAAA01gYAAQoDbABh9gNgAHDWKAAAAP8AAAD/AAAAAAD/AAAA/wAA AAAA/wAAAP8AAAAAAP8AAAD/AAB5dFRD4QAABUcZAABIGQAATBkAAHkZAAB9GQAAhBkAAG4AAAAA AAAAAAAAAABoAAAAAAAAAAAAAAAAaAAAAAAAAAAAAAAAAF8AAAAAAAAAAAAAAABfAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAJAAADJAIWJAFJ ZgEAAABhJAIGAAAWJAFJZgEAAACRAABrZLw3AAAWJAEXJAFJZgEAAAAClmwAB5QIAQjWXAAE9P/2 B/AXbxvMIQAnAgj/////////////////////ACf6D/////////////////////8AJ38D//////// /////////////wAnXQb/////////////////////FPYD2CEVNgEX9gMAABj2AwAAGtYQ//////// /////////////xvWEP////////////////////8c1hD/////////////////////HdYQ//////// /////////////zTWBgABBQMAADTWBgABCgNsAGH2A2AAcNYoAAAA/wAAAP8AAAAAAP8AAAD/AAAA AAD/AAAA/wAAAAAA/wAAAP8AAHl0VEPhAAAFhBkAAIUZAACJGQAAoRkAAKUZAACrGQAAbgAAAAAA AAAAAAAAAGgAAAAAAAAAAAAAAABoAAAAAAAAAAAAAAAAXwAAAAAAAAAAAAAAAF8AAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAkAAAMkAhYkAUlm AQAAAGEkAgYAABYkAUlmAQAAAJEAAGtklTgAABYkARckAUlmAQAAAAKWbAAHlAgBCNZcAAT0//YH 8BdvG8whACcCCP////////////////////8AJ/oP/////////////////////wAnfwP///////// ////////////ACddBv////////////////////8U9gPYIRU2ARf2AwAAGPYDAAAa1hD///////// ////////////G9YQ/////////////////////xzWEP////////////////////8d1hD///////// ////////////NNYGAAEFAwAANNYGAAEKA2wAYfYDYABw1igAAAD/AAAA/wAAAAAA/wAAAP8AAAAA AP8AAAD/AAAAAAD/AAAA/wAAeXRUQ+EAAAWrGQAArBkAALAZAADZGQAA3RkAAOQZAABuAAAAAAAA AAAAAAAAaAAAAAAAAAAAAAAAAGgAAAAAAAAAAAAAAABfAAAAAAAAAAAAAAAAXwAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACQAAAyQCFiQBSWYB AAAAYSQCBgAAFiQBSWYBAAAAkQAAa2RuOQAAFiQBFyQBSWYBAAAAApZsAAeUCAEI1lwABPT/9gfw F28bzCEAJwII/////////////////////wAn+g//////////////////////ACd/A/////////// //////////8AJ10G/////////////////////xT2A9ghFTYBF/YDAAAY9gMAABrWEP////////// //////////8b1hD/////////////////////HNYQ/////////////////////x3WEP////////// //////////801gYAAQUDAAA01gYAAQoDbABh9gNgAHDWKAAAAP8AAAD/AAAAAAD/AAAA/wAAAAAA /wAAAP8AAAAAAP8AAAD/AAB5dFRD4QAABeQZAADlGQAA6RkAAAAaAAAEGgAACxoAAG4AAAAAAAAA AAAAAABoAAAAAAAAAAAAAAAAaAAAAAAAAAAAAAAAAF8AAAAAAAAAAAAAAABfAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAJAAADJAIWJAFJZgEA AABhJAIGAAAWJAFJZgEAAACRAABrZEc6AAAWJAEXJAFJZgEAAAAClmwAB5QIAQjWXAAE9P/2B/AX bxvMIQAnAgj/////////////////////ACf6D/////////////////////8AJ38D//////////// /////////wAnXQb/////////////////////FPYD2CEVNgEX9gMAABj2AwAAGtYQ//////////// /////////xvWEP////////////////////8c1hD/////////////////////HdYQ//////////// /////////zTWBgABBQMAADTWBgABCgNsAGH2A2AAcNYoAAAA/wAAAP8AAAAAAP8AAAD/AAAAAAD/ AAAA/wAAAAAA/wAAAP8AAHl0VEPhAAAFCxoAAAwaAAAQGgAAIBoAACQaAAArGgAAbgAAAAAAAAAA AAAAAGgAAAAAAAAAAAAAAABoAAAAAAAAAAAAAAAAXwAAAAAAAAAAAAAAAF8AAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAkAAAMkAhYkAUlmAQAA AGEkAgYAABYkAUlmAQAAAJEAAGtkIDsAABYkARckAUlmAQAAAAKWbAAHlAgBCNZcAAT0//YH8Bdv G8whACcCCP////////////////////8AJ/oP/////////////////////wAnfwP///////////// ////////ACddBv////////////////////8U9gPYIRU2ARf2AwAAGPYDAAAa1hD///////////// ////////G9YQ/////////////////////xzWEP////////////////////8d1hD///////////// ////////NNYGAAEFAwAANNYGAAEKA2wAYfYDYABw1igAAAD/AAAA/wAAAAAA/wAAAP8AAAAAAP8A AAD/AAAAAAD/AAAA/wAAeXRUQ+EAAAUrGgAALBoAADAaAAA+GgAAQhoAAEkaAABuAAAAAAAAAAAA AAAAaAAAAAAAAAAAAAAAAGgAAAAAAAAAAAAAAABfAAAAAAAAAAAAAAAAXwAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACQAAAyQCFiQBSWYBAAAA YSQCBgAAFiQBSWYBAAAAkQAAa2T5OwAAFiQBFyQBSWYBAAAAApZsAAeUCAEI1lwABPT/9gfwF28b zCEAJwII/////////////////////wAn+g//////////////////////ACd/A/////////////// //////8AJ10G/////////////////////xT2A9ghFTYBF/YDAAAY9gMAABrWEP////////////// //////8b1hD/////////////////////HNYQ/////////////////////x3WEP////////////// //////801gYAAQUDAAA01gYAAQoDbABh9gNgAHDWKAAAAP8AAAD/AAAAAAD/AAAA/wAAAAAA/wAA AP8AAAAAAP8AAAD/AAB5dFRD4QAABUkaAABKGgAAThoAAG4aAAByGgAAeRoAAG4AAAAAAAAAAAAA AABoAAAAAAAAAAAAAAAAaAAAAAAAAAAAAAAAAF8AAAAAAAAAAAAAAABfAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAJAAADJAIWJAFJZgEAAABh JAIGAAAWJAFJZgEAAACRAABrZNI8AAAWJAEXJAFJZgEAAAAClmwAB5QIAQjWXAAE9P/2B/AXbxvM IQAnAgj/////////////////////ACf6D/////////////////////8AJ38D//////////////// /////wAnXQb/////////////////////FPYD2CEVNgEX9gMAABj2AwAAGtYQ//////////////// /////xvWEP////////////////////8c1hD/////////////////////HdYQ//////////////// /////zTWBgABBQMAADTWBgABCgNsAGH2A2AAcNYoAAAA/wAAAP8AAAAAAP8AAAD/AAAAAAD/AAAA /wAAAAAA/wAAAP8AAHl0VEPhAAAFeRoAAHoaAAB+GgAAkBoAAJQaAACbGgAAbgAAAAAAAAAAAAAA AGgAAAAAAAAAAAAAAABoAAAAAAAAAAAAAAAAXwAAAAAAAAAAAAAAAF8AAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAkAAAMkAhYkAUlmAQAAAGEk AgYAABYkAUlmAQAAAJEAAGtkqz0AABYkARckAUlmAQAAAAKWbAAHlAgBCNZcAAT0//YH8BdvG8wh ACcCCP////////////////////8AJ/oP/////////////////////wAnfwP///////////////// ////ACddBv////////////////////8U9gPYIRU2ARf2AwAAGPYDAAAa1hD///////////////// ////G9YQ/////////////////////xzWEP////////////////////8d1hD///////////////// ////NNYGAAEFAwAANNYGAAEKA2wAYfYDYABw1igAAAD/AAAA/wAAAAAA/wAAAP8AAAAAAP8AAAD/ AAAAAAD/AAAA/wAAeXRUQ+EAAAWbGgAAnBoAAKAaAADFGgAAyRoAANAaAABuAAAAAAAAAAAAAAAA aAAAAAAAAAAAAAAAAGgAAAAAAAAAAAAAAABfAAAAAAAAAAAAAAAAXwAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACQAAAyQCFiQBSWYBAAAAYSQC BgAAFiQBSWYBAAAAkQAAa2SEPgAAFiQBFyQBSWYBAAAAApZsAAeUCAEI1lwABPT/9gfwF28bzCEA JwII/////////////////////wAn+g//////////////////////ACd/A/////////////////// //8AJ10G/////////////////////xT2A9ghFTYBF/YDAAAY9gMAABrWEP////////////////// //8b1hD/////////////////////HNYQ/////////////////////x3WEP////////////////// //801gYAAQUDAAA01gYAAQoDbABh9gNgAHDWKAAAAP8AAAD/AAAAAAD/AAAA/wAAAAAA/wAAAP8A AAAAAP8AAAD/AAB5dFRD4QAABdAaAADRGgAA1RoAAOsaAADvGgAA9hoAAG4AAAAAAAAAAAAAAABo AAAAAAAAAAAAAAAAaAAAAAAAAAAAAAAAAF8AAAAAAAAAAAAAAABfAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAJAAADJAIWJAFJZgEAAABhJAIG AAAWJAFJZgEAAACRAABrZF0/AAAWJAEXJAFJZgEAAAAClmwAB5QIAQjWXAAE9P/2B/AXbxvMIQAn Agj/////////////////////ACf6D/////////////////////8AJ38D//////////////////// /wAnXQb/////////////////////FPYD2CEVNgEX9gMAABj2AwAAGtYQ//////////////////// /xvWEP////////////////////8c1hD/////////////////////HdYQ//////////////////// /zTWBgABBQMAADTWBgABCgNsAGH2A2AAcNYoAAAA/wAAAP8AAAAAAP8AAAD/AAAAAAD/AAAA/wAA AAAA/wAAAP8AAHl0VEPhAAAF9hoAAPcaAAD7GgAAGhsAAB4bAAAlGwAAbgAAAAAAAAAAAAAAAGgA AAAAAAAAAAAAAABoAAAAAAAAAAAAAAAAXwAAAAAAAAAAAAAAAF8AAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAkAAAMkAhYkAUlmAQAAAGEkAgYA ABYkAUlmAQAAAJEAAGtkNkAAABYkARckAUlmAQAAAAKWbAAHlAgBCNZcAAT0//YH8BdvG8whACcC CP////////////////////8AJ/oP/////////////////////wAnfwP///////////////////// ACddBv////////////////////8U9gPYIRU2ARf2AwAAGPYDAAAa1hD///////////////////// G9YQ/////////////////////xzWEP////////////////////8d1hD///////////////////// NNYGAAEFAwAANNYGAAEKA2wAYfYDYABw1igAAAD/AAAA/wAAAAAA/wAAAP8AAAAAAP8AAAD/AAAA AAD/AAAA/wAAeXRUQ+EAAAUlGwAAJhsAACobAABWGwAAWhsAAGEbAABuAAAAAAAAAAAAAAAAaAAA AAAAAAAAAAAAAGgAAAAAAAAAAAAAAABfAAAAAAAAAAAAAAAAXwAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACQAAAyQCFiQBSWYBAAAAYSQCBgAA FiQBSWYBAAAAkQAAa2QPQQAAFiQBFyQBSWYBAAAAApZsAAeUCAEI1lwABPT/9gfwF28bzCEAJwII /////////////////////wAn+g//////////////////////ACd/A/////////////////////8A J10G/////////////////////xT2A9ghFTYBF/YDAAAY9gMAABrWEP////////////////////8b 1hD/////////////////////HNYQ/////////////////////x3WEP////////////////////80 1gYAAQUDAAA01gYAAQoDbABh9gNgAHDWKAAAAP8AAAD/AAAAAAD/AAAA/wAAAAAA/wAAAP8AAAAA AP8AAAD/AAB5dFRD4QAABWEbAABiGwAAYxsAAGQbAACAGwAAhRsAAIsbAACWGwAAbgAAAAAAAAAA AAAAAGwAAAAAAAAAAAAAAABsAAAAAAAAAAAAAAAAbAAAAAAAAAAAAAAAAGYAAAAAAAAAAAAAAABm AAAAAAAAAAAAAAAAZgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAYAABYkAUlm AQAAAAABAACRAABrZOhBAAAWJAEXJAFJZgEAAAAClmwAB5QIAQjWXAAE9P/2B/AXbxvMIQAnAgj/ ////////////////////ACf6D/////////////////////8AJ38D/////////////////////wAn XQb/////////////////////FPYD2CEVNgEX9gMAABj2AwAAGtYQ/////////////////////xvW EP////////////////////8c1hD/////////////////////HdYQ/////////////////////zTW BgABBQMAADTWBgABCgNsAGH2A2AAcNYoAAAA/wAAAP8AAAAAAP8AAAD/AAAAAAD/AAAA/wAAAAAA /wAAAP8AAHl0VEPhAAAHlhsAAJcbAACvGwAAsxsAALobAACGAAAAAAAAAAAAAAAAgAAAAAAAAAAA AAAAAHcAAAAAAAAAAAAAAAB3AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAkAAAMkAhYkAUlmAQAAAGEkAgYAABYkAUlmAQAAAHkA AGtkwUIAABYkARckAUlmAQAAAAKWbAAHlAgBCNZGAAP0/+8QrxSDGwAn+xD///////////////// ////ACfAA/////////////////////8AJ9QG/////////////////////xT2A48bFTYBF/YDAAAY 9gMAABrWDP///////////////xvWDP///////////////xzWDP///////////////x3WDP////// /////////zTWBgABBQMAADTWBgABCgNsAGH2A2AAcNYeAAAA/wAAAP8AAAAAAP8AAAD/AAAAAAD/ AAAA/wAAeXRUQ+EAAAS6GwAAuxsAAN8bAADjGwAA6RsAAIYAAAAAAAAAAAAAAACAAAAAAAAAAAAA AAAAdwAAAAAAAAAAAAAAAHcAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACQAAAyQCFiQBSWYBAAAAYSQCBgAAFiQBSWYBAAAAeQAA a2R6QwAAFiQBFyQBSWYBAAAAApZsAAeUCAEI1kYAA/T/7xCvFIMbACf7EP////////////////// //8AJ8AD/////////////////////wAn1Ab/////////////////////FPYDjxsVNgEX9gMAABj2 AwAAGtYM////////////////G9YM////////////////HNYM////////////////HdYM//////// ////////NNYGAAEFAwAANNYGAAEKA2wAYfYDYABw1h4AAAD/AAAA/wAAAAAA/wAAAP8AAAAAAP8A AAD/AAB5dFRD4QAABOkbAADqGwAAAhwAAAYcAAAMHAAAhgAAAAAAAAAAAAAAAIAAAAAAAAAAAAAA AAB3AAAAAAAAAAAAAAAAdwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAJAAADJAIWJAFJZgEAAABhJAIGAAAWJAFJZgEAAAB5AABr ZDNEAAAWJAEXJAFJZgEAAAAClmwAB5QIAQjWRgAD9P/vEK8UgxsAJ/sQ//////////////////// /wAnwAP/////////////////////ACfUBv////////////////////8U9gOPGxU2ARf2AwAAGPYD AAAa1gz///////////////8b1gz///////////////8c1gz///////////////8d1gz///////// //////801gYAAQUDAAA01gYAAQoDbABh9gNgAHDWHgAAAP8AAAD/AAAAAAD/AAAA/wAAAAAA/wAA AP8AAHl0VEPhAAAEDBwAAA0cAAAtHAAAMRwAADgcAACGAAAAAAAAAAAAAAAAgAAAAAAAAAAAAAAA AHcAAAAAAAAAAAAAAAB3AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAkAAAMkAhYkAUlmAQAAAGEkAgYAABYkAUlmAQAAAHkAAGtk 7EQAABYkARckAUlmAQAAAAKWbAAHlAgBCNZGAAP0/+8QrxSDGwAn+xD///////////////////// ACfAA/////////////////////8AJ9QG/////////////////////xT2A48bFTYBF/YDAAAY9gMA ABrWDP///////////////xvWDP///////////////xzWDP///////////////x3WDP////////// /////zTWBgABBQMAADTWBgABCgNsAGH2A2AAcNYeAAAA/wAAAP8AAAAAAP8AAAD/AAAAAAD/AAAA /wAAeXRUQ+EAAAQ4HAAAORwAAGUcAABpHAAAcBwAAIYAAAAAAAAAAAAAAACAAAAAAAAAAAAAAAAA dwAAAAAAAAAAAAAAAHcAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAACQAAAyQCFiQBSWYBAAAAYSQCBgAAFiQBSWYBAAAAeQAAa2Sl RQAAFiQBFyQBSWYBAAAAApZsAAeUCAEI1kYAA/T/7xCvFIMbACf7EP////////////////////8A J8AD/////////////////////wAn1Ab/////////////////////FPYDjxsVNgEX9gMAABj2AwAA GtYM////////////////G9YM////////////////HNYM////////////////HdYM//////////// ////NNYGAAEFAwAANNYGAAEKA2wAYfYDYABw1h4AAAD/AAAA/wAAAAAA/wAAAP8AAAAAAP8AAAD/ AAB5dFRD4QAABHAcAABxHAAAihwAAI4cAACVHAAAhgAAAAAAAAAAAAAAAIAAAAAAAAAAAAAAAAB3 AAAAAAAAAAAAAAAAdwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAJAAADJAIWJAFJZgEAAABhJAIGAAAWJAFJZgEAAAB5AABrZF5G AAAWJAEXJAFJZgEAAAAClmwAB5QIAQjWRgAD9P/vEK8UgxsAJ/sQ/////////////////////wAn wAP/////////////////////ACfUBv////////////////////8U9gOPGxU2ARf2AwAAGPYDAAAa 1gz///////////////8b1gz///////////////8c1gz///////////////8d1gz///////////// //801gYAAQUDAAA01gYAAQoDbABh9gNgAHDWHgAAAP8AAAD/AAAAAAD/AAAA/wAAAAAA/wAAAP8A AHl0VEPhAAAElRwAAJYcAACuHAAAshwAALkcAACGAAAAAAAAAAAAAAAAgAAAAAAAAAAAAAAAAHcA AAAAAAAAAAAAAAB3AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAkAAAMkAhYkAUlmAQAAAGEkAgYAABYkAUlmAQAAAHkAAGtkF0cA ABYkARckAUlmAQAAAAKWbAAHlAgBCNZGAAP0/+8QrxSDGwAn+xD/////////////////////ACfA A/////////////////////8AJ9QG/////////////////////xT2A48bFTYBF/YDAAAY9gMAABrW DP///////////////xvWDP///////////////xzWDP///////////////x3WDP////////////// /zTWBgABBQMAADTWBgABCgNsAGH2A2AAcNYeAAAA/wAAAP8AAAAAAP8AAAD/AAAAAAD/AAAA/wAA eXRUQ+EAAAS5HAAAuhwAAM4cAADRHAAA2BwAAIYAAAAAAAAAAAAAAACAAAAAAAAAAAAAAAAAdwAA AAAAAAAAAAAAAHcAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAACQAAAyQCFiQBSWYBAAAAYSQCBgAAFiQBSWYBAAAAeQAAa2TQRwAA FiQBFyQBSWYBAAAAApZsAAeUCAEI1kYAA/T/7xCvFIMbACf7EP////////////////////8AJ8AD /////////////////////wAn1Ab/////////////////////FPYDjxsVNgEX9gMAABj2AwAAGtYM ////////////////G9YM////////////////HNYM////////////////HdYM//////////////// NNYGAAEFAwAANNYGAAEKA2wAYfYDYABw1h4AAAD/AAAA/wAAAAAA/wAAAP8AAAAAAP8AAAD/AAB5 dFRD4QAABNgcAADZHAAA4BwAAOMcAADqHAAAhgAAAAAAAAAAAAAAAIAAAAAAAAAAAAAAAAB3AAAA AAAAAAAAAAAAdwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAJAAADJAIWJAFJZgEAAABhJAIGAAAWJAFJZgEAAAB5AABrZIlIAAAW JAEXJAFJZgEAAAAClmwAB5QIAQjWRgAD9P/vEK8UgxsAJ/sQ/////////////////////wAnwAP/ ////////////////////ACfUBv////////////////////8U9gOPGxU2ARf2AwAAGPYDAAAa1gz/ //////////////8b1gz///////////////8c1gz///////////////8d1gz///////////////80 1gYAAQUDAAA01gYAAQoDbABh9gNgAHDWHgAAAP8AAAD/AAAAAAD/AAAA/wAAAAAA/wAAAP8AAHl0 VEPhAAAE6hwAAOscAAAGHQAACR0AABAdAACGAAAAAAAAAAAAAAAAgAAAAAAAAAAAAAAAAHcAAAAA AAAAAAAAAAB3AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAkAAAMkAhYkAUlmAQAAAGEkAgYAABYkAUlmAQAAAHkAAGtkQkkAABYk ARckAUlmAQAAAAKWbAAHlAgBCNZGAAP0/+8QrxSDGwAn+xD/////////////////////ACfAA/// //////////////////8AJ9QG/////////////////////xT2A48bFTYBF/YDAAAY9gMAABrWDP// /////////////xvWDP///////////////xzWDP///////////////x3WDP///////////////zTW BgABBQMAADTWBgABCgNsAGH2A2AAcNYeAAAA/wAAAP8AAAAAAP8AAAD/AAAAAAD/AAAA/wAAeXRU Q+EAAAQQHQAAER0AACwdAAAvHQAANh0AAIYAAAAAAAAAAAAAAACAAAAAAAAAAAAAAAAAdwAAAAAA AAAAAAAAAHcAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAACQAAAyQCFiQBSWYBAAAAYSQCBgAAFiQBSWYBAAAAeQAAa2T7SQAAFiQB FyQBSWYBAAAAApZsAAeUCAEI1kYAA/T/7xCvFIMbACf7EP////////////////////8AJ8AD//// /////////////////wAn1Ab/////////////////////FPYDjxsVNgEX9gMAABj2AwAAGtYM//// ////////////G9YM////////////////HNYM////////////////HdYM////////////////NNYG AAEFAwAANNYGAAEKA2wAYfYDYABw1h4AAAD/AAAA/wAAAAAA/wAAAP8AAAAAAP8AAAD/AAB5dFRD 4QAABDYdAAA3HQAATx0AAFIdAABZHQAAhgAAAAAAAAAAAAAAAIAAAAAAAAAAAAAAAAB3AAAAAAAA AAAAAAAAdwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAJAAADJAIWJAFJZgEAAABhJAIGAAAWJAFJZgEAAAB5AABrZLRKAAAWJAEX JAFJZgEAAAAClmwAB5QIAQjWRgAD9P/vEK8UgxsAJ/sQ/////////////////////wAnwAP///// ////////////////ACfUBv////////////////////8U9gOPGxU2ARf2AwAAGPYDAAAa1gz///// //////////8b1gz///////////////8c1gz///////////////8d1gz///////////////801gYA AQUDAAA01gYAAQoDbABh9gNgAHDWHgAAAP8AAAD/AAAAAAD/AAAA/wAAAAAA/wAAAP8AAHl0VEPh AAAEWR0AAFodAABuHQAAcR0AAHgdAACGAAAAAAAAAAAAAAAAgAAAAAAAAAAAAAAAAHcAAAAAAAAA AAAAAAB3AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAkAAAMkAhYkAUlmAQAAAGEkAgYAABYkAUlmAQAAAHkAAGtkbUsAABYkARck AUlmAQAAAAKWbAAHlAgBCNZGAAP0/+8QrxSDGwAn+xD/////////////////////ACfAA/////// //////////////8AJ9QG/////////////////////xT2A48bFTYBF/YDAAAY9gMAABrWDP////// /////////xvWDP///////////////xzWDP///////////////x3WDP///////////////zTWBgAB BQMAADTWBgABCgNsAGH2A2AAcNYeAAAA/wAAAP8AAAAAAP8AAAD/AAAAAAD/AAAA/wAAeXRUQ+EA AAR4HQAAeR0AAJgdAACbHQAAoh0AAIYAAAAAAAAAAAAAAACAAAAAAAAAAAAAAAAAdwAAAAAAAAAA AAAAAHcAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAACQAAAyQCFiQBSWYBAAAAYSQCBgAAFiQBSWYBAAAAeQAAa2QmTAAAFiQBFyQB SWYBAAAAApZsAAeUCAEI1kYAA/T/7xCvFIMbACf7EP////////////////////8AJ8AD//////// /////////////wAn1Ab/////////////////////FPYDjxsVNgEX9gMAABj2AwAAGtYM//////// ////////G9YM////////////////HNYM////////////////HdYM////////////////NNYGAAEF AwAANNYGAAEKA2wAYfYDYABw1h4AAAD/AAAA/wAAAAAA/wAAAP8AAAAAAP8AAAD/AAB5dFRD4QAA BKIdAACjHQAAxx0AAModAADQHQAAhgAAAAAAAAAAAAAAAIAAAAAAAAAAAAAAAAB3AAAAAAAAAAAA AAAAdwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAJAAADJAIWJAFJZgEAAABhJAIGAAAWJAFJZgEAAAB5AABrZN9MAAAWJAEXJAFJ ZgEAAAAClmwAB5QIAQjWRgAD9P/vEK8UgxsAJ/sQ/////////////////////wAnwAP///////// ////////////ACfUBv////////////////////8U9gOPGxU2ARf2AwAAGPYDAAAa1gz///////// //////8b1gz///////////////8c1gz///////////////8d1gz///////////////801gYAAQUD AAA01gYAAQoDbABh9gNgAHDWHgAAAP8AAAD/AAAAAAD/AAAA/wAAAAAA/wAAAP8AAHl0VEPhAAAE 0B0AANEdAADzHQAA9h0AAPwdAACGAAAAAAAAAAAAAAAAgAAAAAAAAAAAAAAAAHcAAAAAAAAAAAAA AAB3AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAkAAAMkAhYkAUlmAQAAAGEkAgYAABYkAUlmAQAAAHkAAGtkmE0AABYkARckAUlm AQAAAAKWbAAHlAgBCNZGAAP0/+8QrxSDGwAn+xD/////////////////////ACfAA/////////// //////////8AJ9QG/////////////////////xT2A48bFTYBF/YDAAAY9gMAABrWDP////////// /////xvWDP///////////////xzWDP///////////////x3WDP///////////////zTWBgABBQMA ADTWBgABCgNsAGH2A2AAcNYeAAAA/wAAAP8AAAAAAP8AAAD/AAAAAAD/AAAA/wAAeXRUQ+EAAAT8 HQAA/R0AACMeAAAmHgAALR4AAIYAAAAAAAAAAAAAAACAAAAAAAAAAAAAAAAAdwAAAAAAAAAAAAAA AHcAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAACQAAAyQCFiQBSWYBAAAAYSQCBgAAFiQBSWYBAAAAeQAAa2RRTgAAFiQBFyQBSWYB AAAAApZsAAeUCAEI1kYAA/T/7xCvFIMbACf7EP////////////////////8AJ8AD//////////// /////////wAn1Ab/////////////////////FPYDjxsVNgEX9gMAABj2AwAAGtYM//////////// ////G9YM////////////////HNYM////////////////HdYM////////////////NNYGAAEFAwAA NNYGAAEKA2wAYfYDYABw1h4AAAD/AAAA/wAAAAAA/wAAAP8AAAAAAP8AAAD/AAB5dFRD4QAABC0e AAAuHgAAWB4AAFseAABiHgAAhgAAAAAAAAAAAAAAAIAAAAAAAAAAAAAAAAB3AAAAAAAAAAAAAAAA dwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAJAAADJAIWJAFJZgEAAABhJAIGAAAWJAFJZgEAAAB5AABrZApPAAAWJAEXJAFJZgEA AAAClmwAB5QIAQjWRgAD9P/vEK8UgxsAJ/sQ/////////////////////wAnwAP///////////// ////////ACfUBv////////////////////8U9gOPGxU2ARf2AwAAGPYDAAAa1gz///////////// //8b1gz///////////////8c1gz///////////////8d1gz///////////////801gYAAQUDAAA0 1gYAAQoDbABh9gNgAHDWHgAAAP8AAAD/AAAAAAD/AAAA/wAAAAAA/wAAAP8AAHl0VEPhAAAEYh4A AGMeAACLHgAAjh4AAJUeAACGAAAAAAAAAAAAAAAAgAAAAAAAAAAAAAAAAHcAAAAAAAAAAAAAAAB3 AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAkAAAMkAhYkAUlmAQAAAGEkAgYAABYkAUlmAQAAAHkAAGtkw08AABYkARckAUlmAQAA AAKWbAAHlAgBCNZGAAP0/+8QrxSDGwAn+xD/////////////////////ACfAA/////////////// //////8AJ9QG/////////////////////xT2A48bFTYBF/YDAAAY9gMAABrWDP////////////// /xvWDP///////////////xzWDP///////////////x3WDP///////////////zTWBgABBQMAADTW BgABCgNsAGH2A2AAcNYeAAAA/wAAAP8AAAAAAP8AAAD/AAAAAAD/AAAA/wAAeXRUQ+EAAASVHgAA lh4AAKceAACqHgAAsR4AAIYAAAAAAAAAAAAAAACAAAAAAAAAAAAAAAAAdwAAAAAAAAAAAAAAAHcA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAACQAAAyQCFiQBSWYBAAAAYSQCBgAAFiQBSWYBAAAAeQAAa2R8UAAAFiQBFyQBSWYBAAAA ApZsAAeUCAEI1kYAA/T/7xCvFIMbACf7EP////////////////////8AJ8AD//////////////// /////wAn1Ab/////////////////////FPYDjxsVNgEX9gMAABj2AwAAGtYM//////////////// G9YM////////////////HNYM////////////////HdYM////////////////NNYGAAEFAwAANNYG AAEKA2wAYfYDYABw1h4AAAD/AAAA/wAAAAAA/wAAAP8AAAAAAP8AAAD/AAB5dFRD4QAABJYeAACx HgAAsh4AALMeAADdHgAA3h4AAJ0fAACeHwAA8urm4tfi0AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAADBVoRQPoABZoRQPoAAAVA2ruUQAAFWhFA+gAFmhFA+gAVQgBBhZoRQPoAAAG FmhUQ+EAAA4WaFRD4QBDShQAYUoUAAAaFmhUQ+EAQ0oUAE9KAgBRSgIAXkoCAGFKFAAHsR4AALIe AACzHgAAtB4AAN0eAADfHgAA4B4AAOEeAAD8HgAAhgAAAAAAAAAAAAAAAIQAAAAAAAAAAAAAAACE AAAAAAAAAAAAAAAAhAAAAAAAAAAAAAAAAIQAAAAAAAAAAAAAAACEAAAAAAAAAAAAAAAAfgAAAAAA AAAAAAAAAH4AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAABgAAFiQBSWYBAAAAAAEAAHkAAGtkNVEAABYkARckAUlmAQAAAAKW bAAHlAgBCNZGAAP0/+8QrxSDGwAn+xD/////////////////////ACfAA/////////////////// //8AJ9QG/////////////////////xT2A48bFTYBF/YDAAAY9gMAABrWDP///////////////xvW DP///////////////xzWDP///////////////x3WDP///////////////zTWBgABBQMAADTWBgAB CgNsAGH2A2AAcNYeAAAA/wAAAP8AAAAAAP8AAAD/AAAAAAD/AAAA/wAAeXRUQ+EAAAj8HgAA/R4A ACEfAAAyHwAAhAAAAAAAAAAAAAAAAH4AAAAAAAAAAAAAAAB+AAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAGAAAWJAFJZgEAAAB7AABrZPfEAAAWJAEXJAFJZgEAAAAClmwABdYY BAEAAAQBAAAEAQAABAEAAAQBAAAEAQAACNYwAAKU/+AQLCIABkwRAAAAAAAAAAAAAAAAAAAAAAAG TBEAAAAAAAAAAAAAAAAAAAAACnQAAOABE9YwAAAA/wQBAAAAAAD/BAEAAAAAAP8EAQAAAAAA/wQB AAAAAAD/BAEAAAAAAP8EAQAAFPYBAAAVNgEX9gMAABrWCAAAAP8AAAD/G9YIAAAA/wAAAP8c1ggA AAD/AAAA/x3WCAAAAP8AAAD/NNYGAAEFAwAANNYGAAEKA2wAYfYDAAB5dEUD6AAAAzIfAAAzHwAA Vh8AAGcfAACEAAAAAAAAAAAAAAAAfgAAAAAAAAAAAAAAAH4AAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAYAABYkAUlmAQAAAHsAAGtkScUAABYkARckAUlmAQAAAAKWbAAF1hgE AQAABAEAAAQBAAAEAQAABAEAAAQBAAAI1jAAApT/4BAsIgAGTBEAAAAAAAAAAAAAAAAAAAAAAAZM EQAAAAAAAAAAAAAAAAAAAAAKdAAA4AET1jAAAAD/BAEAAAAAAP8EAQAAAAAA/wQBAAAAAAD/BAEA AAAAAP8EAQAAAAAA/wQBAAAU9gEAABU2ARf2AwAAGtYIAAAA/wAAAP8b1ggAAAD/AAAA/xzWCAAA AP8AAAD/HdYIAAAA/wAAAP801gYAAQUDAAA01gYAAQoDbABh9gMAAHl0RQPoAAADZx8AAGgfAACL HwAAnB8AAIQAAAAAAAAAAAAAAAB+AAAAAAAAAAAAAAAAfgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAABgAAFiQBSWYBAAAAewAAa2SbxQAAFiQBFyQBSWYBAAAAApZsAAXWGAQB AAAEAQAABAEAAAQBAAAEAQAABAEAAAjWMAAClP/gECwiAAZMEQAAAAAAAAAAAAAAAAAAAAAABkwR AAAAAAAAAAAAAAAAAAAAAAp0AADgARPWMAAAAP8EAQAAAAAA/wQBAAAAAAD/BAEAAAAAAP8EAQAA AAAA/wQBAAAAAAD/BAEAABT2AQAAFTYBF/YDAAAa1ggAAAD/AAAA/xvWCAAAAP8AAAD/HNYIAAAA /wAAAP8d1ggAAAD/AAAA/zTWBgABBQMAADTWBgABCgNsAGH2AwAAeXRFA+gAAAOcHwAAnR8AAJ4f AACEAAAAAAAAAAAAAAAAggAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABAAB7AABrZO3FAAAWJAEXJAFJZgEAAAAClmwABdYYBAEA AAQBAAAEAQAABAEAAAQBAAAEAQAACNYwAAKU/+AQLCIABkwRAAAAAAAAAAAAAAAAAAAAAAAGTBEA AAAAAAAAAAAAAAAAAAAACnQAAOABE9YwAAAA/wQBAAAAAAD/BAEAAAAAAP8EAQAAAAAA/wQBAAAA AAD/BAEAAAAAAP8EAQAAFPYBAAAVNgEX9gMAABrWCAAAAP8AAAD/G9YIAAAA/wAAAP8c1ggAAAD/ AAAA/x3WCAAAAP8AAAD/NNYGAAEFAwAANNYGAAEKA2wAYfYDAAB5dEUD6AAAAiwAMZBoAR+w0C8g sOA9IbAIByKwCAcjkKAFJJCgBSWwAAAXsNACGLDQAgyQ0AIAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAYwAWJAEXJAFJZgEA AAABlgAAIXYAAmgBNdYFAAEDKAg11gUBAgNwGiN2AAEoCCN2AQJwGjpWEAAClmwACnQAAOABFPYB AAAVNgEY9gMAADXWBQABAygINdYFAQIDcBp5dIcgNQBjABYkARckAUlmAQAAAAGWAAAhdgACaAE1 1gUAAQMoCDXWBQECA3AaI3YAASgII3YBAnAaOlYQAAKWbAAKdAAA4AEU9gEAABU2ARj2AwAANdYF AAEDKAg11gUBAgNwGnl0hyA1AGMAFiQBFyQBSWYBAAAAAZYAACF2AAJoATXWBQABAygINdYFAQID cBojdgABKAgjdgECcBo6VhAAApZsAAp0AADgART2AQAAFTYBGPYDAAA11gUAAQMoCDXWBQECA3Aa eXSHIDUAYwAWJAEXJAFJZgEAAAABlgAAIXYAAmgBNdYFAAEDKAg11gUBAgNwGiN2AAEoCCN2AQJw GjpWEAAClmwACnQAAOABFPYBAAAVNgEY9gMAADXWBQABAygINdYFAQIDcBp5dIcgNQBjABYkARck AUlmAQAAAAGWAAAhdgACaAE11gUAAQMoCDXWBQECA3AaI3YAASgII3YBAnAaOlYQAAKWbAAKdAAA 4AEU9gEAABU2ARj2AwAANdYFAAEDKAg11gUBAgNwGnl0hyA1ALcAFiQBFyQBSWYBAAAAAZZgACF2 AANoATXWBQABA5gINdYFAQIDwAM11gUCAwPUBiN2AAGYCCN2AQLAAyN2AgPUBjpWCwAClmwAB5QI ART2AywTFTYBGPYDAAAs1gMAAwI11gUAAQOYCDXWBQECA8ADNdYFAgMD1AY51gMAAwEv1gsAAw// ///////g/2H2A2AAcNYeAAAA/wAAAP8AAAAAAP8AAAD/AAAAAAD/AAAA/wAAeXQHLiQAtwAWJAEX JAFJZgEAAAABlmAAIXYAA2gBNdYFAAEDmAg11gUBAgPAAzXWBQIDA9QGI3YAAZgII3YBAsADI3YC A9QGOlYLAAKWbAAHlAgBFPYDLBMVNgEY9gMAACzWAwADAjXWBQABA5gINdYFAQIDwAM11gUCAwPU BjnWAwADAS/WCwADD////////+D/YfYDYABw1h4AAAD/AAAA/wAAAAAA/wAAAP8AAAAAAP8AAAD/ AAB5dAcuJAC3ABYkARckAUlmAQAAAAGWYAAhdgADaAE11gUAAQOYCDXWBQECA8ADNdYFAgMD1AYj dgABmAgjdgECwAMjdgID1AY6VgsAApZsAAeUCAEU9gMsExU2ARj2AwAALNYDAAMCNdYFAAEDmAg1 1gUBAgPAAzXWBQIDA9QGOdYDAAMBL9YLAAMP////////4P9h9gNgAHDWHgAAAP8AAAD/AAAAAAD/ AAAA/wAAAAAA/wAAAP8AAHl0By4kALcAFiQBFyQBSWYBAAAAAZZgACF2AANoATXWBQABA5gINdYF AQIDwAM11gUCAwPUBiN2AAGYCCN2AQLAAyN2AgPUBjpWCwAClmwAB5QIART2AywTFTYBGPYDAAAs 1gMAAwI11gUAAQOYCDXWBQECA8ADNdYFAgMD1AY51gMAAwEv1gsAAw/////////g/2H2A2AAcNYe AAAA/wAAAP8AAAAAAP8AAAD/AAAAAAD/AAAA/wAAeXQHLiQAtwAWJAEXJAFJZgEAAAABlmAAIXYA A2gBNdYFAAEDmAg11gUBAgPAAzXWBQIDA9QGI3YAAZgII3YBAsADI3YCA9QGOlYLAAKWbAAHlAgB FPYDLBMVNgEY9gMAACzWAwADAjXWBQABA5gINdYFAQIDwAM11gUCAwPUBjnWAwADAS/WCwADD/// /////+D/YfYDYABw1h4AAAD/AAAA/wAAAAAA/wAAAP8AAAAAAP8AAAD/AAB5dAcuJAC3ABYkARck AUlmAQAAAAGWYAAhdgADaAE11gUAAQOYCDXWBQECA8ADNdYFAgMD1AYjdgABmAgjdgECwAMjdgID 1AY6VgsAApZsAAeUCAEU9gMsExU2ARj2AwAALNYDAAMCNdYFAAEDmAg11gUBAgPAAzXWBQIDA9QG OdYDAAMBL9YLAAMP////////4P9h9gNgAHDWHgAAAP8AAAD/AAAAAAD/AAAA/wAAAAAA/wAAAP8A AHl0By4kALcAFiQBFyQBSWYBAAAAAZZgACF2AANoATXWBQABA5gINdYFAQIDwAM11gUCAwPUBiN2 AAGYCCN2AQLAAyN2AgPUBjpWCwAClmwAB5QIART2AywTFTYBGPYDAAAs1gMAAwI11gUAAQOYCDXW BQECA8ADNdYFAgMD1AY51gMAAwEv1gsAAw/////////g/2H2A2AAcNYeAAAA/wAAAP8AAAAAAP8A AAD/AAAAAAD/AAAA/wAAeXQHLiQAtwAWJAEXJAFJZgEAAAABlmAAIXYAA2gBNdYFAAEDmAg11gUB AgPAAzXWBQIDA9QGI3YAAZgII3YBAsADI3YCA9QGOlYLAAKWbAAHlAgBFPYDLBMVNgEY9gMAACzW AwADAjXWBQABA5gINdYFAQIDwAM11gUCAwPUBjnWAwADAS/WCwADD////////+D/YfYDYABw1h4A AAD/AAAA/wAAAAAA/wAAAP8AAAAAAP8AAAD/AAB5dAcuJAC3ABYkARckAUlmAQAAAAGWYAAhdgAD aAE11gUAAQOYCDXWBQECA8ADNdYFAgMD1AYjdgABmAgjdgECwAMjdgID1AY6VgsAApZsAAeUCAEU 9gMsExU2ARj2AwAALNYDAAMCNdYFAAEDmAg11gUBAgPAAzXWBQIDA9QGOdYDAAMBL9YLAAMP//// ////4P9h9gNgAHDWHgAAAP8AAAD/AAAAAAD/AAAA/wAAAAAA/wAAAP8AAHl0By4kALcAFiQBFyQB SWYBAAAAAZZgACF2AANoATXWBQABA5gINdYFAQIDwAM11gUCAwPUBiN2AAGYCCN2AQLAAyN2AgPU BjpWCwAClmwAB5QIART2AywTFTYBGPYDAAAs1gMAAwI11gUAAQOYCDXWBQECA8ADNdYFAgMD1AY5 1gMAAwEv1gsAAw/////////g/2H2A2AAcNYeAAAA/wAAAP8AAAAAAP8AAAD/AAAAAAD/AAAA/wAA eXQHLiQAtwAWJAEXJAFJZgEAAAABlmAAIXYAA2gBNdYFAAEDmAg11gUBAgPAAzXWBQIDA9QGI3YA AZgII3YBAsADI3YCA9QGOlYLAAKWbAAHlAgBFPYDLBMVNgEY9gMAACzWAwADAjXWBQABA5gINdYF AQIDwAM11gUCAwPUBjnWAwADAS/WCwADD////////+D/YfYDYABw1h4AAAD/AAAA/wAAAAAA/wAA AP8AAAAAAP8AAAD/AAB5dAcuJAD3ABYkARckAUlmAQAAAAGWYAAhdgAFaAE11gUAAQMFAzXWBQEC Aw8ENdYFAgMD1xI11gUDBANdBDXWBQQFA7cDI3YAAQUDI3YBAg8EI3YCA9cSI3YDBF0EI3YEBbcD OlYLAAKWbAAHlAgBFPYD/yEVNgEY9gMAACzWAwAFAjXWBQABAwUDNdYFAQIDDwQ11gUCAwPXEjXW BQMEA10ENdYFBAUDtwM51gMABQEv1gsABQ/////////g/2H2A2AAcNYyAAAA/wAAAP8AAAAAAP8A AAD/AAAAAAD/AAAA/wAAAAAA/wAAAP8AAAAAAP8AAAD/AAB5dEkM2wD3ABYkARckAUlmAQAAAAGW YAAhdgAFaAE11gUAAQMFAzXWBQECAw8ENdYFAgMD1xI11gUDBANdBDXWBQQFA7cDI3YAAQUDI3YB Ag8EI3YCA9cSI3YDBF0EI3YEBbcDOlYLAAKWbAAHlAgBFPYD/yEVNgEY9gMAACzWAwAFAjXWBQAB AwUDNdYFAQIDDwQ11gUCAwPXEjXWBQMEA10ENdYFBAUDtwM51gMABQEv1gsABQ/////////g/2H2 A2AAcNYyAAAA/wAAAP8AAAAAAP8AAAD/AAAAAAD/AAAA/wAAAAAA/wAAAP8AAAAAAP8AAAD/AAB5 dEkM2wD3ABYkARckAUlmAQAAAAGWYAAhdgAFaAE11gUAAQMFAzXWBQECAw8ENdYFAgMD1xI11gUD BANdBDXWBQQFA7cDI3YAAQUDI3YBAg8EI3YCA9cSI3YDBF0EI3YEBbcDOlYLAAKWbAAHlAgBFPYD /yEVNgEY9gMAACzWAwAFAjXWBQABAwUDNdYFAQIDDwQ11gUCAwPXEjXWBQMEA10ENdYFBAUDtwM5 1gMABQEv1gsABQ/////////g/2H2A2AAcNYyAAAA/wAAAP8AAAAAAP8AAAD/AAAAAAD/AAAA/wAA AAAA/wAAAP8AAAAAAP8AAAD/AAB5dEkM2wD3ABYkARckAUlmAQAAAAGWYAAhdgAFaAE11gUAAQMF AzXWBQECAw8ENdYFAgMD1xI11gUDBANdBDXWBQQFA7cDI3YAAQUDI3YBAg8EI3YCA9cSI3YDBF0E I3YEBbcDOlYLAAKWbAAHlAgBFPYD/yEVNgEY9gMAACzWAwAFAjXWBQABAwUDNdYFAQIDDwQ11gUC AwPXEjXWBQMEA10ENdYFBAUDtwM51gMABQEv1gsABQ/////////g/2H2A2AAcNYyAAAA/wAAAP8A AAAAAP8AAAD/AAAAAAD/AAAA/wAAAAAA/wAAAP8AAAAAAP8AAAD/AAB5dEkM2wD3ABYkARckAUlm AQAAAAGWYAAhdgAFaAE11gUAAQMFAzXWBQECAw8ENdYFAgMD1xI11gUDBANdBDXWBQQFA7cDI3YA AQUDI3YBAg8EI3YCA9cSI3YDBF0EI3YEBbcDOlYLAAKWbAAHlAgBFPYD/yEVNgEY9gMAACzWAwAF AjXWBQABAwUDNdYFAQIDDwQ11gUCAwPXEjXWBQMEA10ENdYFBAUDtwM51gMABQEv1gsABQ////// ///g/2H2A2AAcNYyAAAA/wAAAP8AAAAAAP8AAAD/AAAAAAD/AAAA/wAAAAAA/wAAAP8AAAAAAP8A AAD/AAB5dEkM2wD3ABYkARckAUlmAQAAAAGWYAAhdgAFaAE11gUAAQMFAzXWBQECAw8ENdYFAgMD 1xI11gUDBANdBDXWBQQFA7cDI3YAAQUDI3YBAg8EI3YCA9cSI3YDBF0EI3YEBbcDOlYLAAKWbAAH lAgBFPYD/yEVNgEY9gMAACzWAwAFAjXWBQABAwUDNdYFAQIDDwQ11gUCAwPXEjXWBQMEA10ENdYF BAUDtwM51gMABQEv1gsABQ/////////g/2H2A2AAcNYyAAAA/wAAAP8AAAAAAP8AAAD/AAAAAAD/ AAAA/wAAAAAA/wAAAP8AAAAAAP8AAAD/AAB5dEkM2wD3ABYkARckAUlmAQAAAAGWYAAhdgAFaAE1 1gUAAQMFAzXWBQECAw8ENdYFAgMD1xI11gUDBANdBDXWBQQFA7cDI3YAAQUDI3YBAg8EI3YCA9cS I3YDBF0EI3YEBbcDOlYLAAKWbAAHlAgBFPYD/yEVNgEY9gMAACzWAwAFAjXWBQABAwUDNdYFAQID DwQ11gUCAwPXEjXWBQMEA10ENdYFBAUDtwM51gMABQEv1gsABQ/////////g/2H2A2AAcNYyAAAA /wAAAP8AAAAAAP8AAAD/AAAAAAD/AAAA/wAAAAAA/wAAAP8AAAAAAP8AAAD/AAB5dEkM2wD3ABYk ARckAUlmAQAAAAGWYAAhdgAFaAE11gUAAQMFAzXWBQECAw8ENdYFAgMD1xI11gUDBANdBDXWBQQF A7cDI3YAAQUDI3YBAg8EI3YCA9cSI3YDBF0EI3YEBbcDOlYLAAKWbAAHlAgBFPYD/yEVNgEY9gMA ACzWAwAFAjXWBQABAwUDNdYFAQIDDwQ11gUCAwPXEjXWBQMEA10ENdYFBAUDtwM51gMABQEv1gsA BQ/////////g/2H2A2AAcNYyAAAA/wAAAP8AAAAAAP8AAAD/AAAAAAD/AAAA/wAAAAAA/wAAAP8A AAAAAP8AAAD/AAB5dEkM2wD3ABYkARckAUlmAQAAAAGWYAAhdgAFaAE11gUAAQMFAzXWBQECAw8E NdYFAgMD1xI11gUDBANdBDXWBQQFA7cDI3YAAQUDI3YBAg8EI3YCA9cSI3YDBF0EI3YEBbcDOlYL AAKWbAAHlAgBFPYD/yEVNgEY9gMAACzWAwAFAjXWBQABAwUDNdYFAQIDDwQ11gUCAwPXEjXWBQME A10ENdYFBAUDtwM51gMABQEv1gsABQ/////////g/2H2A2AAcNYyAAAA/wAAAP8AAAAAAP8AAAD/ AAAAAAD/AAAA/wAAAAAA/wAAAP8AAAAAAP8AAAD/AAB5dEkM2wD3ABYkARckAUlmAQAAAAGWYAAh dgAFaAE11gUAAQMFAzXWBQECAw8ENdYFAgMD1xI11gUDBANdBDXWBQQFA7cDI3YAAQUDI3YBAg8E I3YCA9cSI3YDBF0EI3YEBbcDOlYLAAKWbAAHlAgBFPYD/yEVNgEY9gMAACzWAwAFAjXWBQABAwUD NdYFAQIDDwQ11gUCAwPXEjXWBQMEA10ENdYFBAUDtwM51gMABQEv1gsABQ/////////g/2H2A2AA cNYyAAAA/wAAAP8AAAAAAP8AAAD/AAAAAAD/AAAA/wAAAAAA/wAAAP8AAAAAAP8AAAD/AAB5dEkM 2wD3ABYkARckAUlmAQAAAAGWYAAhdgAFaAE11gUAAQMFAzXWBQECAw8ENdYFAgMD1xI11gUDBANd BDXWBQQFA7cDI3YAAQUDI3YBAg8EI3YCA9cSI3YDBF0EI3YEBbcDOlYLAAKWbAAHlAgBFPYD/yEV NgEY9gMAACzWAwAFAjXWBQABAwUDNdYFAQIDDwQ11gUCAwPXEjXWBQMEA10ENdYFBAUDtwM51gMA BQEv1gsABQ/////////g/2H2A2AAcNYyAAAA/wAAAP8AAAAAAP8AAAD/AAAAAAD/AAAA/wAAAAAA /wAAAP8AAAAAAP8AAAD/AAB5dEkM2wD3ABYkARckAUlmAQAAAAGWYAAhdgAFaAE11gUAAQMFAzXW BQECAw8ENdYFAgMD1xI11gUDBANdBDXWBQQFA7cDI3YAAQUDI3YBAg8EI3YCA9cSI3YDBF0EI3YE BbcDOlYLAAKWbAAHlAgBFPYD/yEVNgEY9gMAACzWAwAFAjXWBQABAwUDNdYFAQIDDwQ11gUCAwPX EjXWBQMEA10ENdYFBAUDtwM51gMABQEv1gsABQ/////////g/2H2A2AAcNYyAAAA/wAAAP8AAAAA AP8AAAD/AAAAAAD/AAAA/wAAAAAA/wAAAP8AAAAAAP8AAAD/AAB5dEkM2wD3ABYkARckAUlmAQAA AAGWYAAhdgAFaAE11gUAAQMFAzXWBQECAw8ENdYFAgMD1xI11gUDBANdBDXWBQQFA7cDI3YAAQUD I3YBAg8EI3YCA9cSI3YDBF0EI3YEBbcDOlYLAAKWbAAHlAgBFPYD/yEVNgEY9gMAACzWAwAFAjXW BQABAwUDNdYFAQIDDwQ11gUCAwPXEjXWBQMEA10ENdYFBAUDtwM51gMABQEv1gsABQ/////////g /2H2A2AAcNYyAAAA/wAAAP8AAAAAAP8AAAD/AAAAAAD/AAAA/wAAAAAA/wAAAP8AAAAAAP8AAAD/ AAB5dEkM2wD3ABYkARckAUlmAQAAAAGWYAAhdgAFaAE11gUAAQMFAzXWBQECAw8ENdYFAgMD1xI1 1gUDBANdBDXWBQQFA7cDI3YAAQUDI3YBAg8EI3YCA9cSI3YDBF0EI3YEBbcDOlYLAAKWbAAHlAgB FPYD/yEVNgEY9gMAACzWAwAFAjXWBQABAwUDNdYFAQIDDwQ11gUCAwPXEjXWBQMEA10ENdYFBAUD twM51gMABQEv1gsABQ/////////g/2H2A2AAcNYyAAAA/wAAAP8AAAAAAP8AAAD/AAAAAAD/AAAA /wAAAAAA/wAAAP8AAAAAAP8AAAD/AAB5dEkM2wD3ABYkARckAUlmAQAAAAGWYAAhdgAFaAE11gUA AQMFAzXWBQECAw8ENdYFAgMD1xI11gUDBANdBDXWBQQFA7cDI3YAAQUDI3YBAg8EI3YCA9cSI3YD BF0EI3YEBbcDOlYLAAKWbAAHlAgBFPYD/yEVNgEY9gMAACzWAwAFAjXWBQABAwUDNdYFAQIDDwQ1 1gUCAwPXEjXWBQMEA10ENdYFBAUDtwM51gMABQEv1gsABQ/////////g/2H2A2AAcNYyAAAA/wAA AP8AAAAAAP8AAAD/AAAAAAD/AAAA/wAAAAAA/wAAAP8AAAAAAP8AAAD/AAB5dEkM2wD3ABYkARck AUlmAQAAAAGWYAAhdgAFaAE11gUAAQMFAzXWBQECAw8ENdYFAgMD1xI11gUDBANdBDXWBQQFA7cD I3YAAQUDI3YBAg8EI3YCA9cSI3YDBF0EI3YEBbcDOlYLAAKWbAAHlAgBFPYD/yEVNgEY9gMAACzW AwAFAjXWBQABAwUDNdYFAQIDDwQ11gUCAwPXEjXWBQMEA10ENdYFBAUDtwM51gMABQEv1gsABQ// ///////g/2H2A2AAcNYyAAAA/wAAAP8AAAAAAP8AAAD/AAAAAAD/AAAA/wAAAAAA/wAAAP8AAAAA AP8AAAD/AAB5dEkM2wD3ABYkARckAUlmAQAAAAGWYAAhdgAFaAE11gUAAQMFAzXWBQECAw8ENdYF AgMD1xI11gUDBANdBDXWBQQFA7cDI3YAAQUDI3YBAg8EI3YCA9cSI3YDBF0EI3YEBbcDOlYLAAKW bAAHlAgBFPYD/yEVNgEY9gMAACzWAwAFAjXWBQABAwUDNdYFAQIDDwQ11gUCAwPXEjXWBQMEA10E NdYFBAUDtwM51gMABQEv1gsABQ/////////g/2H2A2AAcNYyAAAA/wAAAP8AAAAAAP8AAAD/AAAA AAD/AAAA/wAAAAAA/wAAAP8AAAAAAP8AAAD/AAB5dEkM2wD3ABYkARckAUlmAQAAAAGWYAAhdgAF aAE11gUAAQMFAzXWBQECAw8ENdYFAgMD1xI11gUDBANdBDXWBQQFA7cDI3YAAQUDI3YBAg8EI3YC A9cSI3YDBF0EI3YEBbcDOlYLAAKWbAAHlAgBFPYD/yEVNgEY9gMAACzWAwAFAjXWBQABAwUDNdYF AQIDDwQ11gUCAwPXEjXWBQMEA10ENdYFBAUDtwM51gMABQEv1gsABQ/////////g/2H2A2AAcNYy AAAA/wAAAP8AAAAAAP8AAAD/AAAAAAD/AAAA/wAAAAAA/wAAAP8AAAAAAP8AAAD/AAB5dEkM2wD3 ABYkARckAUlmAQAAAAGWYAAhdgAFaAE11gUAAQMFAzXWBQECAw8ENdYFAgMD1xI11gUDBANdBDXW BQQFA7cDI3YAAQUDI3YBAg8EI3YCA9cSI3YDBF0EI3YEBbcDOlYLAAKWbAAHlAgBFPYD/yEVNgEY 9gMAACzWAwAFAjXWBQABAwUDNdYFAQIDDwQ11gUCAwPXEjXWBQMEA10ENdYFBAUDtwM51gMABQEv 1gsABQ/////////g/2H2A2AAcNYyAAAA/wAAAP8AAAAAAP8AAAD/AAAAAAD/AAAA/wAAAAAA/wAA AP8AAAAAAP8AAAD/AAB5dEkM2wD3ABYkARckAUlmAQAAAAGWYAAhdgAFaAE11gUAAQMFAzXWBQEC Aw8ENdYFAgMD1xI11gUDBANdBDXWBQQFA7cDI3YAAQUDI3YBAg8EI3YCA9cSI3YDBF0EI3YEBbcD OlYLAAKWbAAHlAgBFPYD/yEVNgEY9gMAACzWAwAFAjXWBQABAwUDNdYFAQIDDwQ11gUCAwPXEjXW BQMEA10ENdYFBAUDtwM51gMABQEv1gsABQ/////////g/2H2A2AAcNYyAAAA/wAAAP8AAAAAAP8A AAD/AAAAAAD/AAAA/wAAAAAA/wAAAP8AAAAAAP8AAAD/AAB5dEkM2wD3ABYkARckAUlmAQAAAAGW YAAhdgAFaAE11gUAAQMFAzXWBQECAw8ENdYFAgMD1xI11gUDBANdBDXWBQQFA7cDI3YAAQUDI3YB Ag8EI3YCA9cSI3YDBF0EI3YEBbcDOlYLAAKWbAAHlAgBFPYD/yEVNgEY9gMAACzWAwAFAjXWBQAB AwUDNdYFAQIDDwQ11gUCAwPXEjXWBQMEA10ENdYFBAUDtwM51gMABQEv1gsABQ/////////g/2H2 A2AAcNYyAAAA/wAAAP8AAAAAAP8AAAD/AAAAAAD/AAAA/wAAAAAA/wAAAP8AAAAAAP8AAAD/AAB5 dEkM2wD3ABYkARckAUlmAQAAAAGWYAAhdgAFaAE11gUAAQMFAzXWBQECAw8ENdYFAgMDGBU11gUD BAPQAjXWBQQFAycDI3YAAQUDI3YBAg8EI3YCAxgVI3YDBNACI3YEBScDOlYLAAKWbAAHlAgBFPYD IyIVNgEY9gMAACzWAwAFAjXWBQABAwUDNdYFAQIDDwQ11gUCAwMYFTXWBQMEA9ACNdYFBAUDJwM5 1gMABQEv1gsABQ/////////g/2H2A2AAcNYyAAAA/wAAAP8AAAAAAP8AAAD/AAAAAAD/AAAA/wAA AAAA/wAAAP8AAAAAAP8AAAD/AAB5dBk05wD3ABYkARckAUlmAQAAAAGWYAAhdgAFaAE11gUAAQMF AzXWBQECAw8ENdYFAgMDGBU11gUDBAPQAjXWBQQFAycDI3YAAQUDI3YBAg8EI3YCAxgVI3YDBNAC I3YEBScDOlYLAAKWbAAHlAgBFPYDIyIVNgEY9gMAACzWAwAFAjXWBQABAwUDNdYFAQIDDwQ11gUC AwMYFTXWBQMEA9ACNdYFBAUDJwM51gMABQEv1gsABQ/////////g/2H2A2AAcNYyAAAA/wAAAP8A AAAAAP8AAAD/AAAAAAD/AAAA/wAAAAAA/wAAAP8AAAAAAP8AAAD/AAB5dBk05wD3ABYkARckAUlm AQAAAAGWYAAhdgAFaAE11gUAAQMFAzXWBQECAw8ENdYFAgMDGBU11gUDBAPQAjXWBQQFAycDI3YA AQUDI3YBAg8EI3YCAxgVI3YDBNACI3YEBScDOlYLAAKWbAAHlAgBFPYDIyIVNgEY9gMAACzWAwAF AjXWBQABAwUDNdYFAQIDDwQ11gUCAwMYFTXWBQMEA9ACNdYFBAUDJwM51gMABQEv1gsABQ////// ///g/2H2A2AAcNYyAAAA/wAAAP8AAAAAAP8AAAD/AAAAAAD/AAAA/wAAAAAA/wAAAP8AAAAAAP8A AAD/AAB5dBk05wD3ABYkARckAUlmAQAAAAGWYAAhdgAFaAE11gUAAQMFAzXWBQECAw8ENdYFAgMD GBU11gUDBAPQAjXWBQQFAycDI3YAAQUDI3YBAg8EI3YCAxgVI3YDBNACI3YEBScDOlYLAAKWbAAH lAgBFPYDIyIVNgEY9gMAACzWAwAFAjXWBQABAwUDNdYFAQIDDwQ11gUCAwMYFTXWBQMEA9ACNdYF BAUDJwM51gMABQEv1gsABQ/////////g/2H2A2AAcNYyAAAA/wAAAP8AAAAAAP8AAAD/AAAAAAD/ AAAA/wAAAAAA/wAAAP8AAAAAAP8AAAD/AAB5dBk05wD3ABYkARckAUlmAQAAAAGWYAAhdgAFaAE1 1gUAAQMFAzXWBQECAw8ENdYFAgMDGBU11gUDBAPQAjXWBQQFAycDI3YAAQUDI3YBAg8EI3YCAxgV I3YDBNACI3YEBScDOlYLAAKWbAAHlAgBFPYDIyIVNgEY9gMAACzWAwAFAjXWBQABAwUDNdYFAQID DwQ11gUCAwMYFTXWBQMEA9ACNdYFBAUDJwM51gMABQEv1gsABQ/////////g/2H2A2AAcNYyAAAA /wAAAP8AAAAAAP8AAAD/AAAAAAD/AAAA/wAAAAAA/wAAAP8AAAAAAP8AAAD/AAB5dBk05wD3ABYk ARckAUlmAQAAAAGWYAAhdgAFaAE11gUAAQMFAzXWBQECAw8ENdYFAgMDGBU11gUDBAPQAjXWBQQF AycDI3YAAQUDI3YBAg8EI3YCAxgVI3YDBNACI3YEBScDOlYLAAKWbAAHlAgBFPYDIyIVNgEY9gMA ACzWAwAFAjXWBQABAwUDNdYFAQIDDwQ11gUCAwMYFTXWBQMEA9ACNdYFBAUDJwM51gMABQEv1gsA BQ/////////g/2H2A2AAcNYyAAAA/wAAAP8AAAAAAP8AAAD/AAAAAAD/AAAA/wAAAAAA/wAAAP8A AAAAAP8AAAD/AAB5dBk05wD3ABYkARckAUlmAQAAAAGWYAAhdgAFaAE11gUAAQMFAzXWBQECAw8E NdYFAgMDGBU11gUDBAPQAjXWBQQFAycDI3YAAQUDI3YBAg8EI3YCAxgVI3YDBNACI3YEBScDOlYL AAKWbAAHlAgBFPYDIyIVNgEY9gMAACzWAwAFAjXWBQABAwUDNdYFAQIDDwQ11gUCAwMYFTXWBQME A9ACNdYFBAUDJwM51gMABQEv1gsABQ/////////g/2H2A2AAcNYyAAAA/wAAAP8AAAAAAP8AAAD/ AAAAAAD/AAAA/wAAAAAA/wAAAP8AAAAAAP8AAAD/AAB5dBk05wD3ABYkARckAUlmAQAAAAGWYAAh dgAFaAE11gUAAQMFAzXWBQECAw8ENdYFAgMDGBU11gUDBAPQAjXWBQQFAycDI3YAAQUDI3YBAg8E I3YCAxgVI3YDBNACI3YEBScDOlYLAAKWbAAHlAgBFPYDIyIVNgEY9gMAACzWAwAFAjXWBQABAwUD NdYFAQIDDwQ11gUCAwMYFTXWBQMEA9ACNdYFBAUDJwM51gMABQEv1gsABQ/////////g/2H2A2AA cNYyAAAA/wAAAP8AAAAAAP8AAAD/AAAAAAD/AAAA/wAAAAAA/wAAAP8AAAAAAP8AAAD/AAB5dBk0 5wD3ABYkARckAUlmAQAAAAGWYAAhdgAFaAE11gUAAQMFAzXWBQECAw8ENdYFAgMDGBU11gUDBAPQ AjXWBQQFAycDI3YAAQUDI3YBAg8EI3YCAxgVI3YDBNACI3YEBScDOlYLAAKWbAAHlAgBFPYDIyIV NgEY9gMAACzWAwAFAjXWBQABAwUDNdYFAQIDDwQ11gUCAwMYFTXWBQMEA9ACNdYFBAUDJwM51gMA BQEv1gsABQ/////////g/2H2A2AAcNYyAAAA/wAAAP8AAAAAAP8AAAD/AAAAAAD/AAAA/wAAAAAA /wAAAP8AAAAAAP8AAAD/AAB5dBk05wD3ABYkARckAUlmAQAAAAGWYAAhdgAFaAE11gUAAQMFAzXW BQECAw8ENdYFAgMDGBU11gUDBAPQAjXWBQQFAycDI3YAAQUDI3YBAg8EI3YCAxgVI3YDBNACI3YE BScDOlYLAAKWbAAHlAgBFPYDIyIVNgEY9gMAACzWAwAFAjXWBQABAwUDNdYFAQIDDwQ11gUCAwMY FTXWBQMEA9ACNdYFBAUDJwM51gMABQEv1gsABQ/////////g/2H2A2AAcNYyAAAA/wAAAP8AAAAA AP8AAAD/AAAAAAD/AAAA/wAAAAAA/wAAAP8AAAAAAP8AAAD/AAB5dBk05wD3ABYkARckAUlmAQAA AAGWYAAhdgAFaAE11gUAAQMFAzXWBQECAw8ENdYFAgMDGBU11gUDBAPQAjXWBQQFAycDI3YAAQUD I3YBAg8EI3YCAxgVI3YDBNACI3YEBScDOlYLAAKWbAAHlAgBFPYDIyIVNgEY9gMAACzWAwAFAjXW BQABAwUDNdYFAQIDDwQ11gUCAwMYFTXWBQMEA9ACNdYFBAUDJwM51gMABQEv1gsABQ/////////g /2H2A2AAcNYyAAAA/wAAAP8AAAAAAP8AAAD/AAAAAAD/AAAA/wAAAAAA/wAAAP8AAAAAAP8AAAD/ AAB5dBk05wD3ABYkARckAUlmAQAAAAGWYAAhdgAFaAE11gUAAQMFAzXWBQECAw8ENdYFAgMDGBU1 1gUDBAPQAjXWBQQFAycDI3YAAQUDI3YBAg8EI3YCAxgVI3YDBNACI3YEBScDOlYLAAKWbAAHlAgB FPYDIyIVNgEY9gMAACzWAwAFAjXWBQABAwUDNdYFAQIDDwQ11gUCAwMYFTXWBQMEA9ACNdYFBAUD JwM51gMABQEv1gsABQ/////////g/2H2A2AAcNYyAAAA/wAAAP8AAAAAAP8AAAD/AAAAAAD/AAAA /wAAAAAA/wAAAP8AAAAAAP8AAAD/AAB5dBk05wD3ABYkARckAUlmAQAAAAGWYAAhdgAFaAE11gUA AQMFAzXWBQECAw8ENdYFAgMDGBU11gUDBAPQAjXWBQQFAycDI3YAAQUDI3YBAg8EI3YCAxgVI3YD BNACI3YEBScDOlYLAAKWbAAHlAgBFPYDIyIVNgEY9gMAACzWAwAFAjXWBQABAwUDNdYFAQIDDwQ1 1gUCAwMYFTXWBQMEA9ACNdYFBAUDJwM51gMABQEv1gsABQ/////////g/2H2A2AAcNYyAAAA/wAA AP8AAAAAAP8AAAD/AAAAAAD/AAAA/wAAAAAA/wAAAP8AAAAAAP8AAAD/AAB5dBk05wD3ABYkARck AUlmAQAAAAGWYAAhdgAFaAE11gUAAQMFAzXWBQECAw8ENdYFAgMDGBU11gUDBAPQAjXWBQQFAycD I3YAAQUDI3YBAg8EI3YCAxgVI3YDBNACI3YEBScDOlYLAAKWbAAHlAgBFPYDIyIVNgEY9gMAACzW AwAFAjXWBQABAwUDNdYFAQIDDwQ11gUCAwMYFTXWBQMEA9ACNdYFBAUDJwM51gMABQEv1gsABQ// ///////g/2H2A2AAcNYyAAAA/wAAAP8AAAAAAP8AAAD/AAAAAAD/AAAA/wAAAAAA/wAAAP8AAAAA AP8AAAD/AAB5dBk05wD3ABYkARckAUlmAQAAAAGWYAAhdgAFaAE11gUAAQMFAzXWBQECAw8ENdYF AgMDGBU11gUDBAPQAjXWBQQFAycDI3YAAQUDI3YBAg8EI3YCAxgVI3YDBNACI3YEBScDOlYLAAKW bAAHlAgBFPYDIyIVNgEY9gMAACzWAwAFAjXWBQABAwUDNdYFAQIDDwQ11gUCAwMYFTXWBQMEA9AC NdYFBAUDJwM51gMABQEv1gsABQ/////////g/2H2A2AAcNYyAAAA/wAAAP8AAAAAAP8AAAD/AAAA AAD/AAAA/wAAAAAA/wAAAP8AAAAAAP8AAAD/AAB5dBk05wD3ABYkARckAUlmAQAAAAGWYAAhdgAF aAE11gUAAQMFAzXWBQECAw8ENdYFAgMDGBU11gUDBAPQAjXWBQQFAycDI3YAAQUDI3YBAg8EI3YC AxgVI3YDBNACI3YEBScDOlYLAAKWbAAHlAgBFPYDIyIVNgEY9gMAACzWAwAFAjXWBQABAwUDNdYF AQIDDwQ11gUCAwMYFTXWBQMEA9ACNdYFBAUDJwM51gMABQEv1gsABQ/////////g/2H2A2AAcNYy AAAA/wAAAP8AAAAAAP8AAAD/AAAAAAD/AAAA/wAAAAAA/wAAAP8AAAAAAP8AAAD/AAB5dBk05wD3 ABYkARckAUlmAQAAAAGWYAAhdgAFaAE11gUAAQMFAzXWBQECAw8ENdYFAgMDGBU11gUDBAPQAjXW BQQFAycDI3YAAQUDI3YBAg8EI3YCAxgVI3YDBNACI3YEBScDOlYLAAKWbAAHlAgBFPYDIyIVNgEY 9gMAACzWAwAFAjXWBQABAwUDNdYFAQIDDwQ11gUCAwMYFTXWBQMEA9ACNdYFBAUDJwM51gMABQEv 1gsABQ/////////g/2H2A2AAcNYyAAAA/wAAAP8AAAAAAP8AAAD/AAAAAAD/AAAA/wAAAAAA/wAA AP8AAAAAAP8AAAD/AAB5dBk05wD3ABYkARckAUlmAQAAAAGWYAAhdgAFaAE11gUAAQMFAzXWBQEC Aw8ENdYFAgMDGBU11gUDBAPQAjXWBQQFAycDI3YAAQUDI3YBAg8EI3YCAxgVI3YDBNACI3YEBScD OlYLAAKWbAAHlAgBFPYDIyIVNgEY9gMAACzWAwAFAjXWBQABAwUDNdYFAQIDDwQ11gUCAwMYFTXW BQMEA9ACNdYFBAUDJwM51gMABQEv1gsABQ/////////g/2H2A2AAcNYyAAAA/wAAAP8AAAAAAP8A AAD/AAAAAAD/AAAA/wAAAAAA/wAAAP8AAAAAAP8AAAD/AAB5dBk05wD3ABYkARckAUlmAQAAAAGW YAAhdgAFaAE11gUAAQMFAzXWBQECAw8ENdYFAgMDGBU11gUDBAPQAjXWBQQFAycDI3YAAQUDI3YB Ag8EI3YCAxgVI3YDBNACI3YEBScDOlYLAAKWbAAHlAgBFPYDIyIVNgEY9gMAACzWAwAFAjXWBQAB AwUDNdYFAQIDDwQ11gUCAwMYFTXWBQMEA9ACNdYFBAUDJwM51gMABQEv1gsABQ/////////g/2H2 A2AAcNYyAAAA/wAAAP8AAAAAAP8AAAD/AAAAAAD/AAAA/wAAAAAA/wAAAP8AAAAAAP8AAAD/AAB5 dBk05wD3ABYkARckAUlmAQAAAAGWYAAhdgAFaAE11gUAAQMFAzXWBQECAw8ENdYFAgMDGBU11gUD BAPQAjXWBQQFAycDI3YAAQUDI3YBAg8EI3YCAxgVI3YDBNACI3YEBScDOlYLAAKWbAAHlAgBFPYD IyIVNgEY9gMAACzWAwAFAjXWBQABAwUDNdYFAQIDDwQ11gUCAwMYFTXWBQMEA9ACNdYFBAUDJwM5 1gMABQEv1gsABQ/////////g/2H2A2AAcNYyAAAA/wAAAP8AAAAAAP8AAAD/AAAAAAD/AAAA/wAA AAAA/wAAAP8AAAAAAP8AAAD/AAB5dBk05wDXABYkARckAUlmAQAAAAGWYAAhdgAEaAE11gUAAQMC CDXWBQECA/oPNdYFAgMDfwM11gUDBANdBiN2AAECCCN2AQL6DyN2AgN/AyN2AwRdBjpWCwAClmwA B5QIART2A9ghFTYBGPYDAAAs1gMABAI11gUAAQMCCDXWBQECA/oPNdYFAgMDfwM11gUDBANdBjnW AwAEAS/WCwAED////////+D/YfYDYABw1igAAAD/AAAA/wAAAAAA/wAAAP8AAAAAAP8AAAD/AAAA AAD/AAAA/wAAeXRUQ+EA1wAWJAEXJAFJZgEAAAABlmAAIXYABGgBNdYFAAEDAgg11gUBAgP6DzXW BQIDA38DNdYFAwQDXQYjdgABAggjdgEC+g8jdgIDfwMjdgMEXQY6VgsAApZsAAeUCAEU9gPYIRU2 ARj2AwAALNYDAAQCNdYFAAEDAgg11gUBAgP6DzXWBQIDA38DNdYFAwQDXQY51gMABAEv1gsABA// ///////g/2H2A2AAcNYoAAAA/wAAAP8AAAAAAP8AAAD/AAAAAAD/AAAA/wAAAAAA/wAAAP8AAHl0 VEPhANcAFiQBFyQBSWYBAAAAAZZgACF2AARoATXWBQABAwIINdYFAQID+g811gUCAwN/AzXWBQME A10GI3YAAQIII3YBAvoPI3YCA38DI3YDBF0GOlYLAAKWbAAHlAgBFPYD2CEVNgEY9gMAACzWAwAE AjXWBQABAwIINdYFAQID+g811gUCAwN/AzXWBQMEA10GOdYDAAQBL9YLAAQP////////4P9h9gNg AHDWKAAAAP8AAAD/AAAAAAD/AAAA/wAAAAAA/wAAAP8AAAAAAP8AAAD/AAB5dFRD4QDXABYkARck AUlmAQAAAAGWYAAhdgAEaAE11gUAAQMCCDXWBQECA/oPNdYFAgMDfwM11gUDBANdBiN2AAECCCN2 AQL6DyN2AgN/AyN2AwRdBjpWCwAClmwAB5QIART2A9ghFTYBGPYDAAAs1gMABAI11gUAAQMCCDXW BQECA/oPNdYFAgMDfwM11gUDBANdBjnWAwAEAS/WCwAED////////+D/YfYDYABw1igAAAD/AAAA /wAAAAAA/wAAAP8AAAAAAP8AAAD/AAAAAAD/AAAA/wAAeXRUQ+EA1wAWJAEXJAFJZgEAAAABlmAA IXYABGgBNdYFAAEDAgg11gUBAgP6DzXWBQIDA38DNdYFAwQDXQYjdgABAggjdgEC+g8jdgIDfwMj dgMEXQY6VgsAApZsAAeUCAEU9gPYIRU2ARj2AwAALNYDAAQCNdYFAAEDAgg11gUBAgP6DzXWBQID A38DNdYFAwQDXQY51gMABAEv1gsABA/////////g/2H2A2AAcNYoAAAA/wAAAP8AAAAAAP8AAAD/ AAAAAAD/AAAA/wAAAAAA/wAAAP8AAHl0VEPhANcAFiQBFyQBSWYBAAAAAZZgACF2AARoATXWBQAB AwIINdYFAQID+g811gUCAwN/AzXWBQMEA10GI3YAAQIII3YBAvoPI3YCA38DI3YDBF0GOlYLAAKW bAAHlAgBFPYD2CEVNgEY9gMAACzWAwAEAjXWBQABAwIINdYFAQID+g811gUCAwN/AzXWBQMEA10G OdYDAAQBL9YLAAQP////////4P9h9gNgAHDWKAAAAP8AAAD/AAAAAAD/AAAA/wAAAAAA/wAAAP8A AAAAAP8AAAD/AAB5dFRD4QDXABYkARckAUlmAQAAAAGWYAAhdgAEaAE11gUAAQMCCDXWBQECA/oP NdYFAgMDfwM11gUDBANdBiN2AAECCCN2AQL6DyN2AgN/AyN2AwRdBjpWCwAClmwAB5QIART2A9gh FTYBGPYDAAAs1gMABAI11gUAAQMCCDXWBQECA/oPNdYFAgMDfwM11gUDBANdBjnWAwAEAS/WCwAE D////////+D/YfYDYABw1igAAAD/AAAA/wAAAAAA/wAAAP8AAAAAAP8AAAD/AAAAAAD/AAAA/wAA eXRUQ+EA1wAWJAEXJAFJZgEAAAABlmAAIXYABGgBNdYFAAEDAgg11gUBAgP6DzXWBQIDA38DNdYF AwQDXQYjdgABAggjdgEC+g8jdgIDfwMjdgMEXQY6VgsAApZsAAeUCAEU9gPYIRU2ARj2AwAALNYD AAQCNdYFAAEDAgg11gUBAgP6DzXWBQIDA38DNdYFAwQDXQY51gMABAEv1gsABA/////////g/2H2 A2AAcNYoAAAA/wAAAP8AAAAAAP8AAAD/AAAAAAD/AAAA/wAAAAAA/wAAAP8AAHl0VEPhANcAFiQB FyQBSWYBAAAAAZZgACF2AARoATXWBQABAwIINdYFAQID+g811gUCAwN/AzXWBQMEA10GI3YAAQII I3YBAvoPI3YCA38DI3YDBF0GOlYLAAKWbAAHlAgBFPYD2CEVNgEY9gMAACzWAwAEAjXWBQABAwII NdYFAQID+g811gUCAwN/AzXWBQMEA10GOdYDAAQBL9YLAAQP////////4P9h9gNgAHDWKAAAAP8A AAD/AAAAAAD/AAAA/wAAAAAA/wAAAP8AAAAAAP8AAAD/AAB5dFRD4QDXABYkARckAUlmAQAAAAGW YAAhdgAEaAE11gUAAQMCCDXWBQECA/oPNdYFAgMDfwM11gUDBANdBiN2AAECCCN2AQL6DyN2AgN/ AyN2AwRdBjpWCwAClmwAB5QIART2A9ghFTYBGPYDAAAs1gMABAI11gUAAQMCCDXWBQECA/oPNdYF AgMDfwM11gUDBANdBjnWAwAEAS/WCwAED////////+D/YfYDYABw1igAAAD/AAAA/wAAAAAA/wAA AP8AAAAAAP8AAAD/AAAAAAD/AAAA/wAAeXRUQ+EA1wAWJAEXJAFJZgEAAAABlmAAIXYABGgBNdYF AAEDAgg11gUBAgP6DzXWBQIDA38DNdYFAwQDXQYjdgABAggjdgEC+g8jdgIDfwMjdgMEXQY6VgsA ApZsAAeUCAEU9gPYIRU2ARj2AwAALNYDAAQCNdYFAAEDAgg11gUBAgP6DzXWBQIDA38DNdYFAwQD XQY51gMABAEv1gsABA/////////g/2H2A2AAcNYoAAAA/wAAAP8AAAAAAP8AAAD/AAAAAAD/AAAA /wAAAAAA/wAAAP8AAHl0VEPhANcAFiQBFyQBSWYBAAAAAZZgACF2AARoATXWBQABAwIINdYFAQID +g811gUCAwN/AzXWBQMEA10GI3YAAQIII3YBAvoPI3YCA38DI3YDBF0GOlYLAAKWbAAHlAgBFPYD 2CEVNgEY9gMAACzWAwAEAjXWBQABAwIINdYFAQID+g811gUCAwN/AzXWBQMEA10GOdYDAAQBL9YL AAQP////////4P9h9gNgAHDWKAAAAP8AAAD/AAAAAAD/AAAA/wAAAAAA/wAAAP8AAAAAAP8AAAD/ AAB5dFRD4QDXABYkARckAUlmAQAAAAGWYAAhdgAEaAE11gUAAQMCCDXWBQECA/oPNdYFAgMDfwM1 1gUDBANdBiN2AAECCCN2AQL6DyN2AgN/AyN2AwRdBjpWCwAClmwAB5QIART2A9ghFTYBGPYDAAAs 1gMABAI11gUAAQMCCDXWBQECA/oPNdYFAgMDfwM11gUDBANdBjnWAwAEAS/WCwAED////////+D/ YfYDYABw1igAAAD/AAAA/wAAAAAA/wAAAP8AAAAAAP8AAAD/AAAAAAD/AAAA/wAAeXRUQ+EA1wAW JAEXJAFJZgEAAAABlmAAIXYABGgBNdYFAAEDAgg11gUBAgP6DzXWBQIDA38DNdYFAwQDXQYjdgAB AggjdgEC+g8jdgIDfwMjdgMEXQY6VgsAApZsAAeUCAEU9gPYIRU2ARj2AwAALNYDAAQCNdYFAAED Agg11gUBAgP6DzXWBQIDA38DNdYFAwQDXQY51gMABAEv1gsABA/////////g/2H2A2AAcNYoAAAA /wAAAP8AAAAAAP8AAAD/AAAAAAD/AAAA/wAAAAAA/wAAAP8AAHl0VEPhANcAFiQBFyQBSWYBAAAA AZZgACF2AARoATXWBQABAwIINdYFAQID+g811gUCAwN/AzXWBQMEA10GI3YAAQIII3YBAvoPI3YC A38DI3YDBF0GOlYLAAKWbAAHlAgBFPYD2CEVNgEY9gMAACzWAwAEAjXWBQABAwIINdYFAQID+g81 1gUCAwN/AzXWBQMEA10GOdYDAAQBL9YLAAQP////////4P9h9gNgAHDWKAAAAP8AAAD/AAAAAAD/ AAAA/wAAAAAA/wAAAP8AAAAAAP8AAAD/AAB5dFRD4QDXABYkARckAUlmAQAAAAGWYAAhdgAEaAE1 1gUAAQMCCDXWBQECA/oPNdYFAgMDfwM11gUDBANdBiN2AAECCCN2AQL6DyN2AgN/AyN2AwRdBjpW CwAClmwAB5QIART2A9ghFTYBGPYDAAAs1gMABAI11gUAAQMCCDXWBQECA/oPNdYFAgMDfwM11gUD BANdBjnWAwAEAS/WCwAED////////+D/YfYDYABw1igAAAD/AAAA/wAAAAAA/wAAAP8AAAAAAP8A AAD/AAAAAAD/AAAA/wAAeXRUQ+EA1wAWJAEXJAFJZgEAAAABlmAAIXYABGgBNdYFAAEDAgg11gUB AgP6DzXWBQIDA38DNdYFAwQDXQYjdgABAggjdgEC+g8jdgIDfwMjdgMEXQY6VgsAApZsAAeUCAEU 9gPYIRU2ARj2AwAALNYDAAQCNdYFAAEDAgg11gUBAgP6DzXWBQIDA38DNdYFAwQDXQY51gMABAEv 1gsABA/////////g/2H2A2AAcNYoAAAA/wAAAP8AAAAAAP8AAAD/AAAAAAD/AAAA/wAAAAAA/wAA AP8AAHl0VEPhANcAFiQBFyQBSWYBAAAAAZZgACF2AARoATXWBQABAwIINdYFAQID+g811gUCAwN/ AzXWBQMEA10GI3YAAQIII3YBAvoPI3YCA38DI3YDBF0GOlYLAAKWbAAHlAgBFPYD2CEVNgEY9gMA ACzWAwAEAjXWBQABAwIINdYFAQID+g811gUCAwN/AzXWBQMEA10GOdYDAAQBL9YLAAQP//////// 4P9h9gNgAHDWKAAAAP8AAAD/AAAAAAD/AAAA/wAAAAAA/wAAAP8AAAAAAP8AAAD/AAB5dFRD4QDX ABYkARckAUlmAQAAAAGWYAAhdgAEaAE11gUAAQMCCDXWBQECA/oPNdYFAgMDfwM11gUDBANdBiN2 AAECCCN2AQL6DyN2AgN/AyN2AwRdBjpWCwAClmwAB5QIART2A9ghFTYBGPYDAAAs1gMABAI11gUA AQMCCDXWBQECA/oPNdYFAgMDfwM11gUDBANdBjnWAwAEAS/WCwAED////////+D/YfYDYABw1igA AAD/AAAA/wAAAAAA/wAAAP8AAAAAAP8AAAD/AAAAAAD/AAAA/wAAeXRUQ+EA1wAWJAEXJAFJZgEA AAABlmAAIXYABGgBNdYFAAEDAgg11gUBAgP6DzXWBQIDA38DNdYFAwQDXQYjdgABAggjdgEC+g8j dgIDfwMjdgMEXQY6VgsAApZsAAeUCAEU9gPYIRU2ARj2AwAALNYDAAQCNdYFAAEDAgg11gUBAgP6 DzXWBQIDA38DNdYFAwQDXQY51gMABAEv1gsABA/////////g/2H2A2AAcNYoAAAA/wAAAP8AAAAA AP8AAAD/AAAAAAD/AAAA/wAAAAAA/wAAAP8AAHl0VEPhALcAFiQBFyQBSWYBAAAAAZZgACF2AANo ATXWBQABA/sQNdYFAQIDwAM11gUCAwPUBiN2AAH7ECN2AQLAAyN2AgPUBjpWCwAClmwAB5QIART2 A48bFTYBGPYDAAAs1gMAAwI11gUAAQP7EDXWBQECA8ADNdYFAgMD1AY51gMAAwEv1gsAAw////// ///g/2H2A2AAcNYeAAAA/wAAAP8AAAAAAP8AAAD/AAAAAAD/AAAA/wAAeXRUQ+EAtwAWJAEXJAFJ ZgEAAAABlmAAIXYAA2gBNdYFAAED+xA11gUBAgPAAzXWBQIDA9QGI3YAAfsQI3YBAsADI3YCA9QG OlYLAAKWbAAHlAgBFPYDjxsVNgEY9gMAACzWAwADAjXWBQABA/sQNdYFAQIDwAM11gUCAwPUBjnW AwADAS/WCwADD////////+D/YfYDYABw1h4AAAD/AAAA/wAAAAAA/wAAAP8AAAAAAP8AAAD/AAB5 dFRD4QC3ABYkARckAUlmAQAAAAGWYAAhdgADaAE11gUAAQP7EDXWBQECA8ADNdYFAgMD1AYjdgAB +xAjdgECwAMjdgID1AY6VgsAApZsAAeUCAEU9gOPGxU2ARj2AwAALNYDAAMCNdYFAAED+xA11gUB AgPAAzXWBQIDA9QGOdYDAAMBL9YLAAMP////////4P9h9gNgAHDWHgAAAP8AAAD/AAAAAAD/AAAA /wAAAAAA/wAAAP8AAHl0VEPhALcAFiQBFyQBSWYBAAAAAZZgACF2AANoATXWBQABA/sQNdYFAQID wAM11gUCAwPUBiN2AAH7ECN2AQLAAyN2AgPUBjpWCwAClmwAB5QIART2A48bFTYBGPYDAAAs1gMA AwI11gUAAQP7EDXWBQECA8ADNdYFAgMD1AY51gMAAwEv1gsAAw/////////g/2H2A2AAcNYeAAAA /wAAAP8AAAAAAP8AAAD/AAAAAAD/AAAA/wAAeXRUQ+EAtwAWJAEXJAFJZgEAAAABlmAAIXYAA2gB NdYFAAED+xA11gUBAgPAAzXWBQIDA9QGI3YAAfsQI3YBAsADI3YCA9QGOlYLAAKWbAAHlAgBFPYD jxsVNgEY9gMAACzWAwADAjXWBQABA/sQNdYFAQIDwAM11gUCAwPUBjnWAwADAS/WCwADD/////// /+D/YfYDYABw1h4AAAD/AAAA/wAAAAAA/wAAAP8AAAAAAP8AAAD/AAB5dFRD4QC3ABYkARckAUlm AQAAAAGWYAAhdgADaAE11gUAAQP7EDXWBQECA8ADNdYFAgMD1AYjdgAB+xAjdgECwAMjdgID1AY6 VgsAApZsAAeUCAEU9gOPGxU2ARj2AwAALNYDAAMCNdYFAAED+xA11gUBAgPAAzXWBQIDA9QGOdYD AAMBL9YLAAMP////////4P9h9gNgAHDWHgAAAP8AAAD/AAAAAAD/AAAA/wAAAAAA/wAAAP8AAHl0 VEPhALcAFiQBFyQBSWYBAAAAAZZgACF2AANoATXWBQABA/sQNdYFAQIDwAM11gUCAwPUBiN2AAH7 ECN2AQLAAyN2AgPUBjpWCwAClmwAB5QIART2A48bFTYBGPYDAAAs1gMAAwI11gUAAQP7EDXWBQEC A8ADNdYFAgMD1AY51gMAAwEv1gsAAw/////////g/2H2A2AAcNYeAAAA/wAAAP8AAAAAAP8AAAD/ AAAAAAD/AAAA/wAAeXRUQ+EAtwAWJAEXJAFJZgEAAAABlmAAIXYAA2gBNdYFAAED+xA11gUBAgPA AzXWBQIDA9QGI3YAAfsQI3YBAsADI3YCA9QGOlYLAAKWbAAHlAgBFPYDjxsVNgEY9gMAACzWAwAD AjXWBQABA/sQNdYFAQIDwAM11gUCAwPUBjnWAwADAS/WCwADD////////+D/YfYDYABw1h4AAAD/ AAAA/wAAAAAA/wAAAP8AAAAAAP8AAAD/AAB5dFRD4QC3ABYkARckAUlmAQAAAAGWYAAhdgADaAE1 1gUAAQP7EDXWBQECA8ADNdYFAgMD1AYjdgAB+xAjdgECwAMjdgID1AY6VgsAApZsAAeUCAEU9gOP GxU2ARj2AwAALNYDAAMCNdYFAAED+xA11gUBAgPAAzXWBQIDA9QGOdYDAAMBL9YLAAMP//////// 4P9h9gNgAHDWHgAAAP8AAAD/AAAAAAD/AAAA/wAAAAAA/wAAAP8AAHl0VEPhALcAFiQBFyQBSWYB AAAAAZZgACF2AANoATXWBQABA/sQNdYFAQIDwAM11gUCAwPUBiN2AAH7ECN2AQLAAyN2AgPUBjpW CwAClmwAB5QIART2A48bFTYBGPYDAAAs1gMAAwI11gUAAQP7EDXWBQECA8ADNdYFAgMD1AY51gMA AwEv1gsAAw/////////g/2H2A2AAcNYeAAAA/wAAAP8AAAAAAP8AAAD/AAAAAAD/AAAA/wAAeXRU Q+EAtwAWJAEXJAFJZgEAAAABlmAAIXYAA2gBNdYFAAED+xA11gUBAgPAAzXWBQIDA9QGI3YAAfsQ I3YBAsADI3YCA9QGOlYLAAKWbAAHlAgBFPYDjxsVNgEY9gMAACzWAwADAjXWBQABA/sQNdYFAQID wAM11gUCAwPUBjnWAwADAS/WCwADD////////+D/YfYDYABw1h4AAAD/AAAA/wAAAAAA/wAAAP8A AAAAAP8AAAD/AAB5dFRD4QC3ABYkARckAUlmAQAAAAGWYAAhdgADaAE11gUAAQP7EDXWBQECA8AD NdYFAgMD1AYjdgAB+xAjdgECwAMjdgID1AY6VgsAApZsAAeUCAEU9gOPGxU2ARj2AwAALNYDAAMC NdYFAAED+xA11gUBAgPAAzXWBQIDA9QGOdYDAAMBL9YLAAMP////////4P9h9gNgAHDWHgAAAP8A AAD/AAAAAAD/AAAA/wAAAAAA/wAAAP8AAHl0VEPhALcAFiQBFyQBSWYBAAAAAZZgACF2AANoATXW BQABA/sQNdYFAQIDwAM11gUCAwPUBiN2AAH7ECN2AQLAAyN2AgPUBjpWCwAClmwAB5QIART2A48b FTYBGPYDAAAs1gMAAwI11gUAAQP7EDXWBQECA8ADNdYFAgMD1AY51gMAAwEv1gsAAw/////////g /2H2A2AAcNYeAAAA/wAAAP8AAAAAAP8AAAD/AAAAAAD/AAAA/wAAeXRUQ+EAtwAWJAEXJAFJZgEA AAABlmAAIXYAA2gBNdYFAAED+xA11gUBAgPAAzXWBQIDA9QGI3YAAfsQI3YBAsADI3YCA9QGOlYL AAKWbAAHlAgBFPYDjxsVNgEY9gMAACzWAwADAjXWBQABA/sQNdYFAQIDwAM11gUCAwPUBjnWAwAD AS/WCwADD////////+D/YfYDYABw1h4AAAD/AAAA/wAAAAAA/wAAAP8AAAAAAP8AAAD/AAB5dFRD 4QC3ABYkARckAUlmAQAAAAGWYAAhdgADaAE11gUAAQP7EDXWBQECA8ADNdYFAgMD1AYjdgAB+xAj dgECwAMjdgID1AY6VgsAApZsAAeUCAEU9gOPGxU2ARj2AwAALNYDAAMCNdYFAAED+xA11gUBAgPA AzXWBQIDA9QGOdYDAAMBL9YLAAMP////////4P9h9gNgAHDWHgAAAP8AAAD/AAAAAAD/AAAA/wAA AAAA/wAAAP8AAHl0VEPhALcAFiQBFyQBSWYBAAAAAZZgACF2AANoATXWBQABA/sQNdYFAQIDwAM1 1gUCAwPUBiN2AAH7ECN2AQLAAyN2AgPUBjpWCwAClmwAB5QIART2A48bFTYBGPYDAAAs1gMAAwI1 1gUAAQP7EDXWBQECA8ADNdYFAgMD1AY51gMAAwEv1gsAAw/////////g/2H2A2AAcNYeAAAA/wAA AP8AAAAAAP8AAAD/AAAAAAD/AAAA/wAAeXRUQ+EAtwAWJAEXJAFJZgEAAAABlmAAIXYAA2gBNdYF AAED+xA11gUBAgPAAzXWBQIDA9QGI3YAAfsQI3YBAsADI3YCA9QGOlYLAAKWbAAHlAgBFPYDjxsV NgEY9gMAACzWAwADAjXWBQABA/sQNdYFAQIDwAM11gUCAwPUBjnWAwADAS/WCwADD////////+D/ YfYDYABw1h4AAAD/AAAA/wAAAAAA/wAAAP8AAAAAAP8AAAD/AAB5dFRD4QC3ABYkARckAUlmAQAA AAGWYAAhdgADaAE11gUAAQP7EDXWBQECA8ADNdYFAgMD1AYjdgAB+xAjdgECwAMjdgID1AY6VgsA ApZsAAeUCAEU9gOPGxU2ARj2AwAALNYDAAMCNdYFAAED+xA11gUBAgPAAzXWBQIDA9QGOdYDAAMB L9YLAAMP////////4P9h9gNgAHDWHgAAAP8AAAD/AAAAAAD/AAAA/wAAAAAA/wAAAP8AAHl0VEPh ALcAFiQBFyQBSWYBAAAAAZZgACF2AANoATXWBQABA/sQNdYFAQIDwAM11gUCAwPUBiN2AAH7ECN2 AQLAAyN2AgPUBjpWCwAClmwAB5QIART2A48bFTYBGPYDAAAs1gMAAwI11gUAAQP7EDXWBQECA8AD NdYFAgMD1AY51gMAAwEv1gsAAw/////////g/2H2A2AAcNYeAAAA/wAAAP8AAAAAAP8AAAD/AAAA AAD/AAAA/wAAeXRUQ+EAtwAWJAEXJAFJZgEAAAABlmAAIXYAA2gBNdYFAAED+xA11gUBAgPAAzXW BQIDA9QGI3YAAfsQI3YBAsADI3YCA9QGOlYLAAKWbAAHlAgBFPYDjxsVNgEY9gMAACzWAwADAjXW BQABA/sQNdYFAQIDwAM11gUCAwPUBjnWAwADAS/WCwADD////////+D/YfYDYABw1h4AAAD/AAAA /wAAAAAA/wAAAP8AAAAAAP8AAAD/AAB5dFRD4QC3ABYkARckAUlmAQAAAAGWYAAhdgADaAE11gUA AQP7EDXWBQECA8ADNdYFAgMD1AYjdgAB+xAjdgECwAMjdgID1AY6VgsAApZsAAeUCAEU9gOPGxU2 ARj2AwAALNYDAAMCNdYFAAED+xA11gUBAgPAAzXWBQIDA9QGOdYDAAMBL9YLAAMP////////4P9h 9gNgAHDWHgAAAP8AAAD/AAAAAAD/AAAA/wAAAAAA/wAAAP8AAHl0VEPhAAlzAABEAGQAAAAAAAAA CgAAAAAAAAAAAAAAAABpNXEkdwJ3AgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADwAE 8DAAAACyBArwCAAAAAEEAAAACgAAIwAL8AwAAAAEQQEAAAD/AQAACAAAABDwBAAAAAAAAIAiAAfw hXIAAAIEGFEIxH/vnZQTSxDqSTrPqf8AYXIAAAEAAAAyUgAAAAAzEEA9GvBZcgAAGFEIxH/vnZQT SxDqSTrPqYgNBgAAAAAAAAAAADwWAAA0DwAAiHqEANhjWgAncgAAAP542ty9CZyN5f//PzP3uddz Zmxlyb7LUvYtsoSIyJIla5QlJZEQSSRLFJEkKiqRrIksRUnZsoRSkrInsqRElv/rus77es91f8zn 7/b7+f1+93x9H6/v+8xcz/t1Xc9zzpw5M5VPYkJCwqPI48gAZPnNCQlLUhL4T4UOCQl310xIyFf3 3noJCYkJo5KthMntEhKsBP+fi9nBZElIyJCYkLD1P9Y+zB9JePtWIwEFCSWRfAjqSiTWTEzIhdsZ kaSMa/YItnVSPILFNgn3EVugZiQhRn15arp8uxA61O3SNZNkV0R+NLRG/po2r0XgoG7jqHw7B92+ cuVKwk10OxnJTLdxlIT8iIMUSGWvpPU5j1zUH8Xoe+h7N0N6J4p7NSFhnljU/qxKSr1dK6FPQo+E B+Xj9L/2J0uCOFv2VQujlY9mSaj3cULpB45lSRC3b8Hn8mKtSMKYxHvFmbU1wYvHaudvWRIqXYx/ 3qQe8fmn/0oo3fpYKif+DD6eJWHy3wml/9tJ/lddEmke+yKRuyM4l/hTJZNXMYEcxO3EYvl/EWcS LkV+z5Lw0FPyYUgoTPd9onYbj/XQ/xOfV49tUhqP7fjEG//Yvl3x6sd2ZsXUx/ae/3hsBZ/WY6s+ rx5b9fH/q8d2VyavjXpsxW3x2Ioz/bfHNum/PCZJ/5cff/3zab1u6Ox/e33IQ69V6k+1rAkJ5TP8 n+0uSp836PNr1qxJ0O9fQ7uNvYaqTsHl0Pr/22tpS/E6jWxCZiNL8TAPA2TKz83GxyLDkjcliMzG 454gv0dE0njeqHNEtNu29jgkaLeD3FdpOUa0+1D/3iF81X0oXN4llxewUU76PiA+3yF67e8xYu+K dI3oENfoHVVc/7r4WF+/2favi4/19dMR/7r4WF/fnORfFx/r67P/43yz/y/d3/pzVr+///M5q54j Jn3eoTl06FDuFWvFtD3+0y/I4/Kf94N43lbUev7z49kJCYGfv8W0c+a8xp76a1rO/3KerfRxzv94 Xunr+vNMPa/0df15pp5X+rr+PFPPK31df56p55W+rj/P/tN1K32c87/cv0vT8Hvj/2e9e7J/XXys r+ew/evi42H/8bX8RhqP9//u10HS/8bXQX5KTnwdZMnw//YsS5GJ9LhNTQ7HWTbjLK9pZ8HX1tBi Wqf62jT+43UDmG9v/XXjv71OtEIaISPwwRx88n3MnMnx9TGJWZPHJrrIv7GxiX8gv8bGJe6IvZz4 TWxC4lexSYlrYq8lrohNS1wSm5k4Pya6WiPT0dEaBR1wZ3yEiYc4QazPSZwdW5z4TmxV4vTY+sQp sZ2JE2O/Jr4Uu5j4fCxb0tOxwkn9YmWSeseqJ/WM1U/qFmua1DnWJqm97MWPQQkt0JeMvnGYnTHx ZZ4g1jsmtY49nNQi9njSPbGnkmrFBiVVij2bdFtsWFKh2KikzDHl+CyuW4vXjlcxs8XijmJ9dFJy bEySi3klOirp7+gLScejzycdiI5I+gG3d+Fz26NjkzZHxyetj4quFsiL6BiJrhK4o7/BFD96ivXJ SV9Gpyetib6XtCo6P+mT6CdJS6JfJC2M7k6aE/0jaWY0YkyNphivRbMZE6N5jfHRIsZY2VlHfE2g 6z50PYQ5AVO8PxbrJY1R0TLGiGhVY0i0ltE/Ws/oHW1o9IjeZ3SOtjLaRTsa90fVffQArs2La9dg PhCN30divYfRJNrPqB8dZtSOjjeqRacZFaOzjdLRj4zi0ZVGoai6j5biulPYeDvmrdH4fSTWPzUK RFcbeaNrjBzRz40smDHEjH5hXPHWGhe9dcYFb71xztts/OWp58HX6NiIrl54Al7w4s8Dsf6tccb7 0TjlHTBOeMeN371zxlEvKXLYuyXyq1cmsterHvnRuzuy22sa+c5rG9npdY5s93pEtsreashD6JuF vhcxd3rx579Y7x3Z5PWLfO0NjHzhDY586j0X+cgbHpnvvRCZy9c+h2uexzVLMRfStWL9xcj73oTI TG96ZKr3TmSyNycywZsXGectioyW15YXvw/ANZ1xzUrMl7z47xLE+keREd7Hkee8pZEByONIN3lN ZWQh2JpgP8N81JOvKwlifWmkA65piTRD7vWWRRp4yyN1PfU4LgGfD/xxzHu8+OMo1j+N1PLWRqp7 GyJVvG2RCt73kTLez5FS3oHIrd6RSGFPPZf24rpEXHcCs7gXfy6J9aOR/Ege73Akh3cocjOuy+Tt jyR7ByMuPnbQYXHHflx7CBvfjRegKHdY3rFIxPsjkuT9E7niRsx/3UzmP25e86xb0jztVjZPuLXN Y666z6rj2k3oeBrzpBu/z8T6PeYRt5l5wO1k7nV7mt+5/cxtfE1vsIvBvoS5i64R6wPNb9zB5kb3 OXOtO8L81B1tLpPXiPflz4OdCvZNzFVu/P2IWB9nLnInmHPdSeZ77uvmW8xPAjAM3DLMd4kX62+Z r7vvmRPdD81x7mJzpKueN/MA9AS3HnOsG3/eiPUl5vPuUvM59xNzkLvCHOCuMvu5q82+7lqzt6se y89wTUtcE4VIPzf+WIr1DeZj7nazp7vH7O4eNB92/zC7uOfMTm6C1cG1rLZ8fyTiutq4KC9mJ7o/ xLpntXFTrJZuZqupm9Vq5N5i3c1+NwO6DWwlzEbkJ9bzWbXdIlZ1t6RV2S1rlZO8+N1WKXA5xWON WdmNf88Q65Ws29w7rFvd2lY+ZquDccC0xCxMrFhvYGV177Uyu02tZD5HIzB/4c56FDMznUOst7Qc t51luJ2tK04364Kj+M7gDoIfjHnFifNivaf1t9PLOu30sU44/a3fHHXf9AG3A9xbmH848ftGrA+y jjjPWoecUdYvzivWT85Uazfv8SqgL8AuxdxLe4j1GdZOZ7a11ZlnbXIWWV876mt4LrjF4JZhbnbi X8NifbG1DlkLdrWz0FqJLMftZbzPh+Bngt+KuYr2EesfWx85K60FzlprrrPRep/5deAmgjuJ+SHx Yv1b6x3nR+stZ781zTlmTWH+ELjnwXk40HTixfoZa5Jz3hrvJNjjHNMezR7i4E+By4j5EnmIdcse 6dj2C8gwx7GHOK79jBO1Bznq+WsB7A7+DvGmyIk/f8V6Bnugc5M9wLnFfsrJbz/pFLX7OKXs3k5Z +3Gnov0YP0ZlcN0DuK46Zh96jMR6Zbsn8gjSFXxnpCO7iWvuBVsb8yFyE+uV7HZOFbu1U82+36lu N+M9KoGrQXwr2kOsV7ebgG2I3I3Uw8d1+P6oDLYs2DaYDej+EOs17NpOLbuWU9+u7jSxqzrN7CpO C7sSX9cEYGHwnTCr0XVi/X67gtPSLu+0sks7re1SThu7pNPWLs5nbAkwh/jlA+btdEax3sEu5jxo F3UesQs5fe38ziA7j6O+1p4Cmwz2dcyCTvxrTayPtrM7L9s3O5PszHyfvQwmEcwMzGx0n4n11+wM zut2zJlqu8402+Lu18D9jSxGotQt1t+2DeddO8GZZ/9rq+7ZYH5HvrTjbzhFt1hfbP9jL7P/slfZ f9qr7VO2uo+Wg/sFWYf8ZcfvI7G+xj6JnLA/s48hR5HDuO4QX7cC4C5kH3KMrztkf24ftL+099ub 7X32Tnuv/b29x/4R/6fOJ67ZiByla8X5xPrPIH/BFb/a39oH7K22cv8ZzBrkNLLTjruL9aP2Rpxs vX3cXsfsEax/jJyhPQQr1k/YXyCrwa6w1WN8COtzqXe1HX+Mxfrv9ifo/RhZjNuLcM1Cdhb94jFL ceL72PKahfYf9gL7jD3fvmDPxSMy27ad9/EIzuK9Ik78MczoxPcUe4l1z3nPjuIR9JwZ4N+Uj7py EdeMA5udnicRec008FPtZDxTsjivMCvOMxxMAdpHsGI9hzPOzumMsXM7o5gVfQPpOTqOWLGex3kB GQ52CLPiufk49Q5ndoidyxmIPAX2SX5cRW9XMKWo35Tsk3Zep49dwHncLuw8hq+ensyL/duBq4TZ m3ixXtzpga/GrvZtThe7LL7a1H0vepvTa0ZXuu/FegWnE77qO9p3Oe3sRs4DeBVpg1eT1ryPeG26 B3AbzPa0j1hvgVeA5k5zpCn4JpIvRHwt2qeFHf85Uaw3c+rx/dLIib8mCaYh3S9ivSlejZriVUm8 mun73w6mM73mxfevjn3vsFviFbUNXk3bO+WZbw2uqB3/flGFeLH+EF6tH3VK4xX8NvtZpyQ/t54G lwfcbCf+WiyeW2J9tFPcnohX+mlOYfttp5D9jlOQ93gTbFawH2AWoz3E+nv47vCukxfJDT4n8+J7 VgrtkY/5nGBy2DOdbMjNuJ3F1y++F32MmZ35LPYsJ5M9B9+N5jnJ9kJ851K8OMdlHHwpfc8TvFhf hO9wC/HdbgG+Oy50DObngjsH/nNMh3nDXuwk2kudK9YK57K1yrloKX4pfa8W7yUSiRfrnzoXwP2D dwR/Y55lfhm4I+C3YJ63FH8W7x7OWF84p6yvnD+sDc5x5r8E9wu4rZiniRfrG/EuYKNzFOwR5JCl nmOC3039x6z4c0ysb3D2cudarG0jZj937gWzx1rv/IB8j9u7fGfYAG4P5o/M77I2OzvwTmm7tcPZ Zn3nbGF+G7jPwf2EuYN4sf69sxncRmuXsx7zK+a3g1sB7jfMTcx/Zf3gfGntdb6wfnU+tw46q5nf B24xuGOYXxIv1g85nyIrwS5HljH/sxN//yb6VzG/DMzH1gHnI2Qxbi/09b8L7m/xWsz8QrybnG8d cz60/nDm4l3oHOaPg5sO7hzmfOLF+hnnfWQW2HeRmcyLc79K/e8zP9M65byNvGmddKaBn2qpnztE /8vg8rvx97iO5KdaZ53XrfPOFLx7nmJZ7mt41z3Zyu6+auVyJ1n8OotrRuGa0pivW/HXE7Ge333F KuxOsEq44/hcRcA8B6YG5it0LrF+u/sifgoYbVVyR1lV3ReYrwBuELiamC8SL9bvcEcgw8E+hwyV fDHin6T+EVb891Nivao7GBnIveWx3ou4Idw7EMwAq4r7FPIkbvf1naMbuMaYA5jvi59wnrBquY9b dd1eVgP3Uf4aqQPuQXAdMJ+grxGx3sbtyp0tsNYWa70we1KnWG/vPmR1drtYXd0HrR5uJ+YfAnc/ uMcxHyZerD/idkTag22LPMBnEHwT6u9IZxDrPdwW3NkFaw2IacOdLcA0t7rjJ6zubhPcbmyp72Oi 8y5wz2I2t+Lfx8T6I/iJ7FG3kfWE29Dqj5/QBiJPu/V5nyfd+M9zQzHvpX3E+iD3bnB1wd+FWZv3 6Uc/U75MPyvakq8Nvpb1jFvTGubWsEa61a3RyBi3Gu8zAnwZ8OMxa9E+Yv1F/HT5olsFbCWkIt9H gi9J+9xB95FYH+OW8TFFiKnITBkwJXxMPmJKM1MCTGEfcwsxxZkpDCavj7mJmELM5AWTw8ekEJOH mRxgsvD98Lz4+Z+Y7Hw/ZAGTGfdZRiQDbqfw/S06DXAzMLPQ/S3Wx7rJ1kvIRDdqTXE9a6rrWtNc h/eZDP4SymdiJtM+Yn26a4MzrTdcAzOJ93kN3D/0exeb9hHr091E6y3kXfeK+YF72fwQmedeMvnn AvBncN1HmEm0j1if715ELoD9BznH/PvgTtA+F03FnwPzN7rPIn/i9hlTnUv0HwG0DvOcGT+XWF/g njYXIUvdk+Yq94T5GbLGPc77rAC/n647TfuI9TXu78hv5mr3KOYRU/2MuxLcXkC/Yx434z/jivW1 7mFzPfKNe8jc4R40f0B+dg+YB5DD7n7e71dcsBvXHafziv3E+hH3V3D7kJ+Rvewl+B2ALtM5bcnv NY+6P5nHkJPuj+Zf7g/mOeS8u5v3OQt+C/grdF6xj1i/4H6P7AK7E9nB/J/gNtA+u5nfAeZb8x93 G7IVt7fwuUT/l4CyePHz2ZLfYv7rfmNeQgxvk+l5G80YkuJt4H1c8KvB3+TFzyf2EesZvPXIV2DX IV8y74BbQftsYP5LMGvNZO9zZA1ur+Zzif6lgIp58fPZkl9tZvQ+MzMj2b1PzbzeKjM/UtBbyfvk Ab8I/K2Ya2gfsV7IW4EsB7sMWWqqr2HBf0j7rDTjX8NivaC3iDtzY202MUu5cxGYhWYBbwEyH7fn mep7uOh8B1BzT/zOMP49XKwX8T40SyBlvLlmJe8Ds443x2yANPZm814NcM1buOYRL/47SLGXWL/f e99s680yO3nvmQ9775rqfXsncG+I321izjHj79vFek/vHbOPN9Mc6M0wB3lvm88gao8BYF8DOxzz PdpDrA/x3kLeBDsdmcZ8f3ATaY8ZzE8D84Y52JuKvI7bU/ixE/0vA3oDczo9dmL9WWSY95o52pts TvBeNSd5k8zJiNpngvgdP/hpnvjdbHwfsf6aNxF5BewEZDzz48GNpH1eZX48mJfNV72XkHG4PZbP JfqHA1qCOYHOJdanIG94L5ozvTHmB95oc543ylyAqH3mgH+WrhtH+yyQzEjkBXO+NwLzed7nA3CD AW31xO+k4/uI9UXIEm+4ucobZq5D1nvPmRsR/n0g+AHgt2G+QPuI9U3eUORZsEOQZ/i5K/gnaZ9h 9NwV6xu9gT6mNzFDmBkIpp+PeYyYp5npB6YPn+1LrPUgpj+frQ+YJ8wNXm/kcdzuxfeB6OwK6Bhm X7oPxPpmZKv3mPm996j5C3LA62keQtQ+v4DvLF6X6dxiH7F+2HsE6QG2O9KN+X3gOtA+jzLfDUxX 86D3MPIQbnfhc4n+tuI80YSE7nQusX4E+d3rbP7pPWheRBKincwkRO1zCde1Fl/LuO5h2kesG9GO MknRDkh7U73/FXwL2kf4GJJvD6Yt0oZ7L4JrSlwH7m0DprWZGG0lkxRtyecXvY0BFY6Sh+Rbmibi RO83MyG3RFuYuaPNzXyI2icn+HvAF4nGPcQ+Yj1/tBnSFOx9SBN+Tgj+btqnBT0nxHq+aCMfU4eY psw0AtPAx9QipjEzDcDU47PdEo3/cyPBNOSz1QNT18wbrYPchdu1+T4QnVUB1aEz2pKvbRZEikRr mbdHa5pVkGrRGmYNRO1TFXwl8HXp3GIfsV4zeidSHaxINeargCtP+9RivhqYO8w7o1VlakSr8HsK 0V8G0EOYd9J7CrFeG6kbrWzegzSJVjJbIG2QdtGKZkdE7Sf++e1tuO5hzDtoP7HeKVoBKQ9WpBzf t4IvQftVpvtWrHeMlvYxxYipwExpMKV8TGFiyjJTCkxxH1OAmNuZKQ6mKJ+/DdbyElOSz18UTBGz Q7SwTMdoIb6/RGcuM/7P1W+l+0usd0a6RguaPZHe0QLmU8gg5NlofnMYovZ7Rvw7a7huFGYR2k+s D4/mQ/KCFcnDX5OCz0b7FaSvSbE+LJobycXnEtxNWJ+LmZ/OJdZHIKOjOc2XkEnI1Ogt5lvIO9Ec 5ixEnWsGrsuE6z7EzEPnEuvvR7Mj2cCKZOX7VvAZaL+cdN+K9VnRm3xMjJgczNwEJpOPcYnJykwm MCk+xiImCzMpYKI+JkJMRmaiYFx2fBtricSksKMLxjHfi9oys6IW36ei80okIWE7ZpTuU7E+B5kf Nc2PkOXIauRLZEM0Ym5G1H5f47qLuP5bchT7ifVvogaSBFYkkR0Ef572s8hBrG+OXo7ozDliDGYu RzZHL0bUvl9h7SwxibzvRTD/RjZFL8hsjp6PKE/ReQb8eczLkbinWN+K7Iz+E/kR+QU5jBxHTkfP Rc4iar+TuO6k+PcnyFfsJ9b/iv6N/AVW5Cw7CP4E7Sd8kyR/FswZH/M7MeeYOQPmVER9bQjmKDF/ ReJfG2L9bPQP5ISv6zBxZ7jrBJjffV0HiDnFXb+D+Q056uN+Je4Ec0fBHEEO830quH1YLxiLe7iS Oxz5B7mEGLFDERfJgNwcOxi5BcmDqH1yxOL/foS4/jfaJ49kDiD7fdyPxB1hbj+YX5B9fB8Ibjdx B+k+EOt5Ynt9zHfE7GdmL5g9vv12EPML77cHzA/Ibl/XduL2ctduMN/5urYSs4e7vgOzC9nJ96Xg vsH6fZg/0H0p1gsgRZHbYjsi5ZE7kNqxbyN3Iw0RtU89XLeJrv+e9mkome3INj6z4DYQt4vOLNYb xrb4ur4iZgd3bQGzGdnk6/qSuG3ctQnMBh/zBTFbmNkA5msfs4aYzcx8DWadj/mMmI3MrAOz1nfu VcSs53OvBfMF8jnf14JbgfXnyNOV3OeRJsj9SLvYmkgXpCfSJ7Y6MgAZjKh9+uO6T+j6L2mfwZL5 DPmUzyy4pcR9QWcW64NjK33MEmLWMLMSzHIfs5iYz5hZDmaZj1lIzCpmloH52MfMJ2YFMx+D+cjH fEjMJ8x8BGaRj/mAmKXMLAKzwMfMJmYJMwvAzPMxs4hZzMw8MHN9zLvELGRmLpg5vsdjJjHz+fGY A2Y28j4/7oJ7G+sfk6MrufcjQ5GRyEuxWZHJyJvIe7H3Ih8iCxG1z1xc9yZd/wHts1Ay7yLv8JkF N4242XRmsb4wNsPHvEHMLGZmgHnbx7xOzHvMvA3mTR/zGjHvMPMmmGk+5lViZjAzDcxUHzORmLeY mQpmio+ZQMx0ZqaAmexjxhPzBjOTwbzqY14iZiozr4KZ6LuvxxIzhe/riWBeQSbwYyq4MVg/gTmZ HlOx/jGyElkbGx/ZjOxC9sZejhxAjiJqnwO4bhRdP4n2OSqZl5BxfGbBjSTuFTqzWD8aG+tjRhAz gZmxYMb4mOHEvMzMGDCjfMwwYsYxMwrMSB8zlJixzIwEM8LHDCFmDDMjwAz3Mc8QM4qZ4WCG+ZhB xIxkZhiYoT5mIDEjmBkKZoiP6U/McGaGgBnsezyeIuY5fjwGgxkkox53wT0p/p3K5Pj94EpuUOQE cha5FHs6YiU/HcmI5EgeGMmHFEbUPvlwXV+6fgjtU1gyA2TUmQX3BHHP0JnjzFM+pjcxg5h5Ckw/ H9OLmKeZ6Qemr495lJgBzPQF84SP6UnMU8w8Aaa3j+lBTD9meoPp5WO6E9OXmV5gHvMxXYnpw8xj YHr6mIeJ6c1MTzCP+JguxDzOzCNguvuYB4l5jJnuYLr6HrNOxPTkx6wrmIdlBFefuI5YfwzzEcyo 5B6OFEVKIOWQakg9pGnyQ5EHkM5IV6Q7ovbrguvbU08P2q+7ZLognfnsgmtHXDc6u1jvnvygj3mA mK7MPAimo49pQ8xDzHQE08HHtCKmCzMdwLTzMS2JeZCZdmDa+pj7ienETFswD/iY5sR0ZOYBMK19 TDNi2jPTGkwrH3MfMe2YaQXmfh/ThJgHmLkfTAsf05iYNsy0ANPcxzQipjUzzcE09TENiWnJTFMw 9/mYBsTcz8x9YBr7mPrENGemMZh7fc+hesQ04+fQvWAaIQ35OSu4ulhfRvdVVHINIz2RXkh/ZBgy LvmeyBTkHeRDZAGyGFH7zcP1dainCe23WDINZNTZBXcXcY3p7HGmvo+pRcy9zNQHU8/H1CSmITP1 wNT1MTWIuYeZumDq+JjqxDRgpg6Y2j6mGjF3M1MbTC0fcwcx9ZipBaamj6lKTF1maoKp4WMqE1OH mRpgqvuYSsTUZqY6mGo+piIxtZipBuYOH1OBmJrM3AGmqo8pR0wNZqqCqexjyhJTnZnKYCr5nh9l iKnGz49KYCrKqOej4EqL76sp8fszKrmKkY+R5chaZAuyBzmaXCHyJ3IJSUypEIkgar8r6LmNeqrS fhHJlEfK8dkFV4q4ynR2sR5JKetjShJTiZmyYMr4mBLEVGSmDJjSPqY4MRWYKQ3mdh9zKzHlmbkd zG0+phgx5Zi5DUwpH1OUmLLMlAJT0scUJqYMMyXBFPcxhYi5nZniYG71MQWJuY2ZW8EU8zEFiCnF TDEwRX1MfmJKMlMUTBEfk4+YEswUAVPYx+QlpjgzhcEU8jG5ibmVmUJgCviYXMQUZaYAmPw+Jicx RZjJDyafj7mFmMLM5AOT18fkIKYQM3nB5PEx2YkpyEweMLl9TDZiCjCTG0wuH5OVmPzM5AKT08fc REw+ZnKCyeFjshCTh5kcYLL7mMzE5GYmO5hsPiYTMbmYyQYmq4/JSExOZrKCudn3NZ+BmFv4a/5m MDfJtKK/l0VwKVjvlhK/z5Mld1PERmJIJiQbUggpl5IlUhtpgtyPPIB0RDojat/26Emmvuy0b2fJ ZJZRDoKLEZeNHOJMJh8TJSYrM5nAZPQxHjE3M5MRTAYf4xJzEzMZwKT4GIeYLMykgEn2MTYxmZlJ BhPzMRYxmZiJgYn6GJOYjMxEwXg+JkJMBmY8MK6PMYhJYcYF4/iYJGKSmXHA2D4mkZgYMzYYy8ck EBNlxgJj+pgrRpzxmDHBRHzPj8vEuPz8iIAxZNTzUnCXsLiDHpdkyRmRrkhP5AlkADISmZKSFJmD fIKsRtYhG5EtiNp3A3ouUp9N+26RTKKMchDcv8RZ5BBnEnzMBWJMZhLAXDHSYiLMXDH+kzmfJnPZ x/xDjMHMZTCXfMw5YpKYuQTmoo/5m5hEZi6C+dfH/EVMAjP/grngY84SIx7rOHMBzPk0mcvMnL+K +TNN5h8fc4aYS8z8A+acjzlNzEVmzoH528ecIuZfZv4G85ePOUnMBWb+AnM2TeY8M2evYv5Ik/nT x5wg5h9m/gRzxsccJ+YcM2fAnPYxvxPzNzOnwZzyMceI+YuZU2BO+pjfiDnLzEkwf6TJ/MnMH1cx R9NkTviYI8ScYeYEmOM+5jAxp5k5DuZ3H3OImFPM/A7mmI85SMxJZo6B+c3HHCDmD2Z+A3M0TeYE M0evYvanyRzxMb8Sc5yZI2AO+5hfiPmdmcNgDvmYfcQcY+YQmIM+5mdifmPmIJgDaTJHmTnAjHrd 3KsxBjP7ZdR/3y64n7DYPEP88c0guf3GDuQH5BfkKHIauYCkZPjVKICUQMoj1ZC7kAZIY0Tt3wBF e6j3MO3fWDK/yCgXnTtELmkxP6bJ7PMxPxBzkJl9YH72MbuJOcDMz2D2psnsZ2bvVcz3aTI/+Zjv iPmVmZ/A7EmT+YWZPVcxu9JkfvQxO4nZx8yPYH7wMTuI+ZmZH8DsTpPZy8zuq5hv02S+9zHbifmJ me/BfJcms4eZ765itqXJ7PIxW4n5kZldYHamyfzAzM6rmC1pMjt8zDfE7GZmB5hvfcxmYr5n5lsw 29NkvmNm+1XMpjSZbT5mIzG7mNkGZmuazE5mtl7FbEiT2eJj1hOzg5ktYL7xMV8T8y0z34DZnCaz nZnNVzFfpcls8jHriNnGzCYwG9NktjKz8SrmyzSZDT5mLTFbmNkAZr2P+YKYb5hZD+brNJnNzHx9 FfN5msxXPmYNMZuY+QrMujSZjcysu4pZnSbzpY/5jJgNzHwJZm2azHpm1jKjvh98qjEGM1/IqO9H gluFxZP0PMkguS+MFkhb5CGkFzIAeR6ZluFzYwmyBtmI7ET2IgeRY4g64yGt9ys64zGNKUbMSo0x mFkjo3cpbh13Xc2sSJNZ7WOWE/MlM6vBfJYms5aZz5hR5/5EYwxmPpXRuxT3BXelMqprmcYYzKyS 0bsU9zl3Xc0sTZNZ6WM+JmYNMyvBrEiTWc3MCmbUuZdojMHMchm9S3GfcVcqo7o+0hiDmU9k9C7F fcpdVzOL02SW+ZhFxKxiZhmYpWkyK5lZyow690KNMZj5WEbvUtwK7kplVNcCjTGYWSKjdyluOXdd zcxPk/nIx8wj5hNmPgKzOE1mGTOLmVHn/lBjDGYWyehdilvKXamM6pqrMQYzC2X0LsV9zF2pjOr6 QGMMZhbI6F2KW8JdVzNz0mTm+5jZxHzEzHww89JkFjMzjxl17vc1xmDmQxm9S3GLuCuVUV2zNMZg Zq6M3qW4hdx1NfNemswHPuZdYhYw8wGYOWky85mZw4w69zsaYzAzW0bvUtw87kplVNdMjTGYeV9G 71Lch9x1NTMjTWaWj3mbmLnMzALzXprMB8y8x4w691saYzDzrozepbg53JXKqK43NcZg5h0ZvUtx s7nramZ6msxMHzONmPeZmQlmRprMLGZmMKPO/YbGGMy8LaN3Ke497kplVNdUjTGYeUtG71Lcu9yV yqiu1zXGYOZNGb1Lce9w19XMlDSZ6T7mNWJmMjMdzLQ0mRnMTGNGnXuyxhjMvCGjdynube5KZVTX qxpjMDNVRu9S3FvcdTUzKU3mdR8zkZg3mXkdzJQ0menMTGFGnfsVjTGYeU1G71LcNO5KZVoTMwFr yzPGmQzEnEb+RayMrxlZkPxIaaRJxslGL+QZ5EVkCvIOMg9Zgqi9F2RM7X2D9l6iMcWIGa8xBjOv yuhdipvKXdfHqP1e1hiDmUkyepfiXueuVEZ1vaQxBjMTZfQuxU3hrlRGdY3TGIOZV2T0LsW9xl3X x6j9xmqMwcwEGb1LcZO5K5VRXS9qjMHMeBm9S3Gvclcqo7rGaIzBzMsyepfiJnHX9TFqv9EaYzDz kozepbiJ3JXKqK5RGmMwM05G71LcK9x1fYzab6TGGMyMldG7FDeBu1IZ1fWCxhjMvCijdyluPHel MqprhMYYzIyR0bsU9zJ3XR+j9nteYwxmRsvoXYp7ibtSGdU1XGMMZkbJ6F2KG8ddqYzqGqYxBjMj ZfQuxY3lrutj1H7PaYzBzAsyepfiXuSuVEZ1DdUYg5kRMnqX4sZwVyqjup7VGIOZ52X0LsWN5q7r Y9R+QzTGYGa4jN6luFHclcqormc0xmBmmIzepbiR3JXKqK7BGmMw85yM3qW4F7jr+hi13yCNMZgZ KqN3KW4Ed6UyqutpjTGYeVZG71Lc89yVyqiugRpjMDNERu9S3HDuuj5G7TdAYwxmnpHRuxQ3jLtS GdXVX2MMZgbL6F2Ke467ro9R+z2lMQYzg2T0LsUN5a5URnX10xiDmadl9C7FPctdqYzqelJjDGYG yuhdihvCXdfHqP36aozBzAAZvUtxz3BXKqO6+miMwUx/Gb1LcYO5K5VRXU9ojMHMUzJ6l+IGcdf1 MWq/3hpjMNNPRu9S3NPclcqorsc1xmDmSRm9S3EDuSuVUV29NMZgpq+M3qW4Adx1fYza7zGNMZjp I6N3Ka4/d6UyqutRjTGYeUJG71LcU9yVyqiunhpjMNNbRu9SXD/uuj5G7feIxhjMPC6jdynuSe5K ZVRXD40xmOklo3cpri93pTKqq7vGGMw8JqN3Ka4Pd10fo/brpjEGM4/K6F2Ke4K7UhnV1VVjDGZ6 yuhdiuvNXamM6npYYwxmHpHRuxT3OHddH6P2e0hjDGZ6yOhdiuvFXamM6uqiMQYz3WX0LsU9xl3X x6j9OmuMwUw3Gb1LcY9yVyqjuh7UGIOZrjJ6l+J6clcqo7o6aYzBzMMyepfiHuGu62PUfh01xmDm IRm9S3E9uCuVUV0dNMZgpouM3qW47tyVyqiu9hpjMNNZRu9SXDfuuj5G7ddOYwxmHpTRuxTXlbtS GdXVVmMMZjrJ6F2Ke5i7UhnV9YDGGMx0lBFcd43blSn+tZZFch2N5chnyGbkJ+QPJDFTRyMrUhKp jbRGeiHDkcnIbOQTZB2yCdmWqSOfeVMm/z7izNuukylGTBuNMZjpIKN3Ka4Ld10fo/ZrrTEGM+1l 9C7FdeauG8+oM7XSGIOZdjJ6l+Ie5K7rY9R+LTXGYKatjN6luE7cdeMZdab7NcZg5gEZvUtxHbnr +hi1XwuNMZhpI6N3Ka4Dd914Rp2pucYYzLSW0bsU1567bjyjztRMYwxmWsnoXYprx13Xx6j9mmqM wUxLGb1LcW2568Yz6kz3aYzBzP0yepfiHuCu62PUfk00xmCmhYzepbg23HXjGXWmxhpjMNNcRu9S XGvuuj5G7XevxhjMNJPRuxTXirtuPKPO1EhjDGaayuhdimvJXdfHqP0aaozBzH0yepfi7ueuG8+o M92jMQYzTWT0LsW14K7rY9R+DTTGYKaxjN6luObcdeMZdab6GmMwc6+M3qW4Ztx1fYza726NMZhp JKN3Ka4pd914Rp2pnsYYzDSU0bsUdx93XR+j9qurMQYz98joXYprwl03nlFnqqMxBjMNZPQuxTXm rutj1H53aYzBTH0ZvUtx93LXjWfUmWprjMHM3TJ6l+IacdeNZ9SZammMwUw9Gb1LcQ256/oYtV9N jTGYqSujdynuHu668Yw6Uw2NMZipI6N3Ka4Bd10fo/a7U2MMZu6S0bsUV5+7bjyjzlRdYwxmasvo XYq7m7uuj1H7VdMYg5laMnqX4upx141n1Jnu0BiDmZoyepfi6nLX9TFqv6oaYzBTQ0bvUlwd7rrx jDpTFY0xmLlTRu9S3F3cdX2M2q+yxhjMVJfRuxRXm7tuPKPOVEljDGaqyehdiqvFXdfHqP0qaozB zB0yepfianLXjWfUmSpojMFMVRm9S3E1uOv6GLVfeY0xmKkio3cp7k7uuvGMOlM5jTGYqSyjdymu OnddH6P2K6sxBjOVZPQuxVXjrhvPqDOV0RiDmYoyepfi7uCu62PUfqU1xmCmgozepbiq3HXjGXWm 2zXGYKa8jN6luCrcdeMZdabbNMZgppyM3qW4ytx1fYzar5TGGMyUldG7FFeJu248o85UUmMMZsrI 6F2Kq8hd18eo/UpojMFMaRm9S3EVuOvGM+pMxTXGYOZ2Gb1LceW56/oYtd+tGmMwc5uM3qW4ctx1 4xl1pmIaYzBTSkbvUlxZ7ro+Ru1XVGMMZkrK6F2KK8NdN55RZyqiMQYzJWT0LsWV5q7rY9R+hTXG YKa4jN6luNu568Yz6kyFNMZg5lYZvUtxt3HX9TFqv4IaYzBTTEbvUlwp7rrxjDpTAY0xmCkqo3cp riR3XR+j9suvMQYzRWT0LsWV4K4bz6gz5dMYg5nCMnqX4opz1/Uxar+8GmMwU0hG71Lcrdx14xl1 pjwaYzBTUEZwQzVuZZb4614OyRU0diP7kRPIecTKXNC4CSmIlENaIAOQ6cha5DckJUtBoyzSHOmC 9EGGIuOQ15F3kfnI0iwF2WVRFv/+wmVpiJlixOTWGIOZAjJ6l+KKclf6ZpR/Lo0xmMkvo3cprgh3 pW9G+efUGIOZfDJ6l+IKc1f6ZpT/LRpjMJNXRu9SXCHuSt+M8s+hMQYzeWT0LsUV5K70zSj/7Bpj MJNbRu9SXAHuSt+M8s+mMQYzuWT0LsXl5670zSj/rBpjMJNTRu9SXD7uSt+M8r9ZYwxmbpHRuxSX l7vSN6P8b9IYg5kcMnqX4vJwV/pmlH8WjTGYyS6jdykuN3elb0b5Z9YYg5lsMnqX4nJxV/pmlH8m jTGYySqjdykuJ3elb0b5Z9QYg5mbZfQuxd3CXembUf4ZNMZg5iYZvUtxObgrfTPKP0VjDGayyOhd isvOXembUf7JGmMwk1lG71JcNu5K34zyj2mMwUwmGb1LcVm5638+o+6jqMYYzGSU0bsUdzN3pW9G +XsaYzCTQUbvUtxN3JW+GeXvaozBTIqM3qW4LNyVvhnl72iMwUyyjN6luMzclb4Z5W9rjMFMTEbv Ulwm7krfjPK3NMZgJiqjdykuI3elb0b5mxpjMOPJ6F2Ky8Bd6ZtR/hGNMZhxZfQuxaVwV/pmlL+h MQYzjozepbhk7krfjPJP0hiDGVtG71JcjLvSN6P8EzXGYMaS0bsUF+Wu9M0o/wSNMZgxZfQuxXnc lb4Z5X8lKZUxmInI6F2Kc7krfTPK/7LGGMwYMnqX4hzuSt+M8r+kMQYzSTJ6l+Js7krfjPK/qDEG M4kyepfiLO5K34zy/1djDGYSZPQuxZnclb4Z5X9BYwxmriSJ6F2Ki3DX/3xG3UfnNcZg5rKM3qU4 g7vSN6P8/9EYg5lLMnqX4pK4K30zyv+cxhjMXJTRuxSXyF3pm1H+f2uMwcy/MnqX4hK4K30zyv8v jTGYuSCjdylOvO+Kd6VvRvmf1RiDmfMyepfiLnNX+maU/58aYzDzj4zepbhL3JW+GeV/RmMMZs7J 6F2Ku8hd6ZtR/qc1xmDmbxm9S3H/clf6ZpT/KY0xmPlLRu9S3AXuSt+M8j+pMQYzZ2X0LsWd5670 zSj/PzTGYOZPGb1Lcf9wV/pmlP8JjTGYOSOjdynuHHelb0b5H9cYg5nTMnqX4v7mrvTNKP/fNcZg 5pSM3qW4v7grfTPK/5jGGMyclNG7FHeWu9I3o/x/0xiDmT9k9C7F/cld6ZtR/kc1xmDmhIzepbgz 3PU/n1H30RGNMZg5LqN3Ke40d6VvRvkf1hiDmd9l9C7FneKu9M0o/0MaYzBzTEbvUtxJ7krfjPI/ qDEGM7/J6F2K+4O70jej/A9ojMHMURm9S3EnuCt9M8p/v8YYzByR0bsUd5y70jej/H/VGIOZwzJ6 l+J+5670zSj/XzTGYOaQjN6luGPclb4Z5b9PYwxmDsroXYr7jbvSN6P8f9YYg5kDMnqX4o5yV/pm lP9ejTGY2S+jdynuCHelb0b5/6QxBjO/yuhdijvMXembUf57NMZg5hcZvUtxh7grfTPK/0eNMZjZ J6N3Ke4gd6VvRvn/oDEGMz/L6F2KO8Bd6ZtR/rs1xmBmr4zepbj93JW+GeX/vcYYzPwko3cp7lfu St+M8v9OYwxm9sjoXYr7hbv+5zPqPtqlMQYzP8roXYrbx13pm1H+OzXGYOYHGb1LcT9zV/pmlP8O jTGY2S2jdyluL3elb0b5f6sxBjPfy+hdivuJu9I3o/y3a4zBzHcyepfi9nBX+maU/zaNMZjZJaN3 Ke5H7krfjPLfqjEGMztl9C7F/cBd6ZtR/ls0xmBmh4zepbjd3JW+GeX/jcYYzHwro3cp7nvuSt+M 8t+sMQYz22X0LsV9x13pm1H+mzTGYGabjN6luF3clb4Z5b9RYwxmtsroXYrbyV3pm1H+GzTGYGaL jN6luB3clb4Z5b9eYwxmvpHRuxT3LXelb0b5f60xBjObZfQuxW3nrjiTE7czImMSExKyJickFMXt 7EgkQf0ZKv9/YSRGn89Ot8VaDr6dkJCZbov+lkhppDd6L+KT72KWRr8p90pMfisxa/KYxBLJ/eRM TFb9NkoLp3bybVw6tADdvoI/+TEd7VxJ/3FGdVvcJ/oZ9bPnoY+XIhORzbh/XsNG6j6ZiTPPB3xT 6hnSdBwFbhI+uQpzfSzuODPx9diyxPmxmYlrY+PkfD0WRsc2KG0fwLEGPrgLn+yL2Z8c2yTVj/VK ah9rk9QnVkfO+qF0HIXSzAEce+GDf6J47DBLkuOopEvR6UmZY6OSisb6ynkpGkbH8ShdH72241P4 YD64DzD3R+OO45M+ir6XtD46PmlvdJCcH4XSUfydy2MDOIr/7r5PNP6/XzSLHIsY/aN3GGOjRYwZ 0Uxy9g+lo/jfWb4/gKP43w27A9xAzMfJsaNRM/qkcX+0o/FI9B45a4bScSUuLhTAcQY4D9wuzDvJ caWRIbrNKBRdaVSJzpIzQygdN+Piv7xrOy4GtwfcYcwM5LjZ+MX71fjL22x40WVy/uKF0bEHirYG cGwC7mNwwzF/8+KOPSIrvCGRrV6PyEGvhZwrQun4AormBnB8FNwEcG9jriPHFyKTvTcic70XImu8 J+ScHErHRSgaHcDxNXCPg9uE+Q45Loo86X0VGe0tirzpTZPzyVA6LkVRtwCO08DdC24b5nPkuDTS zNsU6eYtjQz2ZsjZLJSOy1FUN4DjW+BKgNuB2ZEcl0dKe1sidb3lkQe8d+UsHUrHIygqHMDxG3BR cImQq0GORyIZvYuRwt6RSFXvWzkzhtbRCuh43I075mPH0+7FiAW3nHAU87QbRsfaOOwx99qOxcBt A9cOM0KOtc1dbivzmFvbvOKWknNXKB370dmv5dgW3FJwL9N9YsprV7pjzG1uP/OQ20nOlaF0HI3D Lgvg+Di46eDewdxOjqPNme6b5jJ3tLnZfVLOmaF0fB2HfSuA47PgRoD7CHM5Ob5ujnHnm2+5r5tL 3OflHBNKx8U47MgAjlPAPQZuM+YMclxs9nG/Nke6i81p7nQ5+4TScS0O2zuA4xxwLcHtxRxDjmvN tu5us7e71hyBx1PMtqF0tCy8ngRwPA6pWuDyge9HjpZVz81ptXUtq7d72hSzXigdb8GZ7w7gmACu FLjymA+S4y1WWfd26273Fquda8pZNpSOZXHmcgEcs4PLAa4R5r3kWNbK495tlXPLWvXd3HLmCed7 AJw5X5D3AOAs8R4Asyo51raibisrn1vbquCWkjMaSsemOHNyAMdK4P7EYXpiFiXHptY/Tlcr2W1q FXCryfmPE0bHbjjzBefajveC+wXcc5g3kWM365Az2LrgdLMyuM3kPBRKx/44828BHNuD2wpuAqZB jv2tnc5Y6zenv3XZ6SznzlA6TsWZdwdwHAruM3BLMM84ccep1lpngbXbmWqdcEbIuTaUjotw5q8D OL4Gbh64TZi/kuMia7HzlfW1s8j6yZkm5+LQOi4L6DidHLez40w4LoPbZjiKOTOUjhtx5vcDOC4E Nw7cQczPyXGj9Yqzz3rf2Witcj6W85VQOh7DmacEcNwGbgi4CA6/mByPWcOdK9YU55g1z9kl5/BQ Opo4zOgAjr/D8XFwecG/Q46m/aRziz3aMe03nVOWmE+G0jGKwwwK4HhavE8FVxj8q+QYtbs6+exB TtQe7/xtidk1lI4VcZjHAjjmAtcc3H2YI8mxot3aaWg/5lS0hzn55WwdWseOAR3rkuNAdrwHjh3h 9iQcxbwnlI7VcZhmARwLgqsMrhXmo+RY3a7uNLObOdXtbk4xOauH1rFOQMfi5NiBHW+HYx24tYGj mLeH0rEFDlMpgGNVcLnB9cJsSo4t7AJOD7uS08Ju5NSQs0AoHdvS43Mtx1rgMoLrR4+7Ka+92elt F3fa2jWcenLeHErHQThMngCOD4KLgHuVvi5Nea3rjLfzOIPsck5XOd1QOk7CYTIHcHwa3D/IfKQk OU6yL9lz7MzOJLuo86ycl+wwOk7DYawAjsPAHUeWIvnIcZp92l5kW840O6czUs7ToXSch8P8a1/b cSKYX5GvkZvJcZ592P7C/teeZ2d0psh5OJSOq3GYUwEc3wPzHfID4pHjanuPvdM+Za+2TecDOfeE 1vFQQMdN5HjFVo7b4HgIbhfsD+TcFkrHH+14ruW4xo7nLMWU166zT9o/4v9O4paY60LpeACH2RrA cQOYj5FLyG/keMBeYf9jb7UP2AftLXKuCKWjeK1cF8DxWzBz6TV4Hzketxfaic46+zgewe9tMReG 1nFFQMe3yXEnO74HxxVw2wpHMd8LrePCgI6TyXEjO74Bx4VwWwdHMd8IpaOLDWYFcDwJZixS0Im/ 9pjy2gl4BzcL7+BW2mdtMSeE1nFaQMdh5LiUHUfCcRrcFsFRzJGhdMyCDV4J4HgezACkFPgPyTGL 84xdzHnFzuK8b1+2xXwmlI7iZ8JRARwN+tlR/Kw5kxxzO33tss4oO7cz3Xbk7BtaxyEBHR8ixyns 2AOOQ+A2EY5i9git45MBHR8gx5fYsSMcn4TbaDiK2TGUjsXEPzcN4JgCrim42pgjyLGY09Ku7vTE 1+RQfC2K2TKUjmWd+M/41/z3AcDdDa6RE//dgfz3AZxG9t3Og3gsn8JjKGajUDqK3zu2DuAofr9x J/3esQ85NnPusrs5re1mzmN4PMW8K7SOTQI6ViDHHuxYFY5N4PYQHMWsGlrHegEdS5JjJ3YsA8d6 cGsLRzHLhNaxekDHguTYih2LwbE63JrBUcxioXRsjw3KB3C8C9wt4PpjNibH9k5eu49T3m7vNLDr y5k3lI7P0nPwWo4Pg8sM7nV6bpvy2mz2JKek/axTy35EzmyhdHyHnoPXchT/HNYF9yk9t015bYr9 iVPQfsepbL8kZ0poHXMGdEwkxwrsaMExJ9xKw1FMK7SOWQI6nrfijqXY8bL1iZMFbsXgKOZlK4yO C534Py+/luNkJ/7PyzfSPy835bV/W+ucqL3QyWe/IeffoXU0Ajr+Ro652fEPOBpwyw5HMf8IpeMq bHDRurbjTHD7wX2HmZUcVzlHrO3ORWuVk8l+X84joXU8G9DxR3JMYcd9cDwLNxeOYu4LpeMGbHA8 gOMCcN+CO4BpkeMG53vrZ+e4tcFJtJfI+X1oHQ8FdNxEjlcs5bgNjofgdsFaIue20DruDei4lhzP seN6OO6F2xk4irk+tI67AjquJMeT7LgGjrvgdgyOYq4JpaN4DdkSwHEV/fu5pzCPkuN3znLrd2eL 9Z1zwPpczuWhdfwqoOOH5PgLOy6C41dw2wNHMReF0vEgNlgdwFF8738P3GXMH8jxoPOBdd5ZbR10 dlpb5fwgtI7LAjpOJ8ft7DgTjsvgthmOYs4MrePCgI6TyXEjO74Bx4VwWwdHMd8IpeNpbDAngOP3 4F4GF3Xj30NMee0ky3LnWKedz6yfHDEnhdZxZkDHUeS4ih3HwXEm3JbBUcxxoXWcGtBxKDkuYccR cJwKtwVwFHNEKB1z4cyTAjgmgXsaXEXM+eSYy33WKuNOsnLh+WrL+WwoHUvgzOMCOGYC1xdcXcz3 ybGEO8Cq6Y6zSuD5mlXOAaF0FP+d3wsBHMV/P/gouBaYb5NjVfcJq4n7glXVxeupnE+E1nFoQMeu 5DiVHXvCcSjcXoWjmD1D6zgwoGNHcpzIjg/BcSDcXoKjmA+F1rFvQMc25DiOHTvAsS/cRsFRzA6h dGxAX2fXcrwdXDNwXejr15TXtrI6uI9aDdznrPJytgqlYxv6Orvm34VI/711X/r6lX8XotvU6uV2 tdq4g6w6cjYNpWMPnLlTAMcm4OqBG07fJ+Xf2eU2tIa4nawebj+rhZwNQ+v4QEDHmuT4JDvWheMD cHscjmLWDa1ji4COVcmxFzvWgGMLuPWAo5g1QuvYOKBjeXLszo5V4NgYbl3gKGaVUDo+jTPXD+DY Cdxt4CZhdibHp91y1stufetpt731sJzlQutYO6BjMXJsx46l4Fgbbq3gKGapUDqKvyemWgBH8ffP FAD3LmZLchzjFrXecqtZY/A9o5+cRUPrWDGgYy5yvI8d88OxItwawlHM/KF1LBPQMRs5NmTHXHAs A7d6cBQzV2gdSwR0zESOddkxKxxLwK0mHMXMGlrHwgEdo+RYgx0zwrEw3KrCUcyMoXXMG9DRJMcq 7OjBMS/cysNRTC+0jjkCOl4x447l2DECxxxwuw2OYkZC65gloON5cizFjpfNt9wscCsGRzEvm2F1 TAnoeJYci7HjeTimwK0gHMU8H0rHaTizE8BxGLg/6O98LECO09w/zUWuY01zc1sj5fwztI5JAR2P kmMudjwBxyS4ZYOjmCdC6TgPZ75kBvjvWMEdAPc1vReQ/x2re9T8wr1kznMzW1PkPBpax3MBHfeS YyZ23A/Hc3CLwVHM/aF1PBPQcTc5xthxLxzPwM2Go5h7Q+m4xo3/XY7XcpwF7ltwP7rxvyPSlNd+ b+5yj5tr3ERrrpzfh9bxSEDHb8gxkR2/heMRuF0058r5bSgdD+PM+wM4bga3Xoh5CQkXzbjjYfcb 8198DR7G1+J2Ob8JrePegI5ryfEcO66H4164nYGjmOtD6XieXkuu5bgP3Gfgsnjx1yhTXrvWTPF2 m+fxffGgK+ba0DruCOi4nBxPsONncNwBt6NwFPOz0DpuCei4hByPsuNyOG6B2wE4irk8lI4pOPOG AI5n4bgAXDEv/n7HlNcuMQt6G+D5M/zEXBJaxy8DOn5Ajj+z4wI4fgm3H+Ao5oLQOq4O6PgeOf7A jh/AcTXcdsJRzA9C6VgQZ14ZwNEFNwNcdcxd5FjQm2VW9lbCcxv8xJwVWselAR2nkeM2dpwBx6Vw 2wRHMWeE1nFRQMfXyHETO06D4yK4fQVHMaeF1nFeQMeJ5Pg1O06B4zy4fQFHMaeE0rExzjw7gGN5 cC+B6475BTk29iaaXbzZZmPvU7OKnBND6fgwzvxuAMeG4MaAe9aLv6cz5bUvm09775oPe8vN++R8 OZSOz4j/zaoAjl3AvQDuNcwV5PiM96L5ive2+Yz3sdldzhdD6zgtoOMwclzKjiPhOA1ui+Ao5sjQ Ok4J6DiEHBez43A4ToHbPDiKOTyUjpNx5kkBHAeDexrcQsz55DjZe9ac600yJ3tzzOfkfDa0juMD Oj5Fjh+w4yA4jofbe3AUc1BoHccGdOxDjrPYsT8cx8JtBhzF7B9KxwU486gAjq+C6wVuA+ZMclzg 9TW/9EaZC7zp5lQ5+4bW8fmAjo+Q45vs+Dgcn4fb63AU8/FQOm7EmZ8L4Cieo93AHcR8gxw3eo+a +7znzI3eZPNjOR8NreMzAR27kONr7Ngdjs/A7RU4itk9tI4DAzp2JMeJ7PgQHAfC7SU4ivlQaB37 BXRsS44vs2MnOPaD2xg4itkptI59Ajq2Jsex7Ngejn3gNhKOYrYPrWOvgI4tyHEUO7aBYy+4DYej mG1C6XgIZ+4ZwHETuKbgrmCOIMdDXkvzgtfTPOQNNbfJ2TK0jt0COt5Ljs+xYzM4doPbYDiK2Sy0 jl0COjYgx2fYsTEcu8BtABzFbBxKx6RoQkKnAI5H4VYPXK5o/OcPU17b0MwW7WQmRfuZJzwxG4bW sX1Ax7vIsT871odje7j1gaOY9UPr2CagYw1y7MuOdeDYBm694ChmndA6tgzoWI0ce7NjLTi2hFtP OIpZK5SO+XDm5gEcLXBVwFXFfIwc80XvNCtEm5v5ot3NqJx3htaxSUDHCuTYgx2rwrEJ3B6Co5hV Q+vYKKBjWXLsyo6V4NgIbg/CUcxKoXVsENDxdnLswo7l4dgAbh3gKGb50DrWC+hYkhw7sWMZONaD W1s4ilkmtI61AzoWI8d27FgKjrXh1gqOYpYKpWONaPz73rUcC4MrDK4NfT815bXFzRbRGmaNaAuz uJzFQ+tYLaBjAXJsyY5F4VgNbk3hKGbR0DpWCeiYlxybs2MhOFaBW2M4ilkolI4dceaKARzrgssF biDmfeTYMZrffDJa0eyI9+L3yJk/tI7lAjrmIMd72TEPHMvBrT4cxcwTWsfSAR2zkuM97JgTjqXh VheOYuYMrWOpgI5ZyPFudswOx1Jwqw1HMbOH1rF4QMeM5FiHHW+GY3G41YCjmDeH1rFoQMdkcqzF jpnhWBRu1eAoZubQOhYK6OiR453smAGOheBWBY5iZgil4zCcOX8Ax+7gbHDTMO8gx2HRmPkavl8M w/eNx+SMhdYxT0DHCDlWZkcXjnngVg6OYrqhdcwV0DGJHCuyow3HXHArA0cx7VA6zqLv7ddyHAvu CjZdQ+8ZTHltxFwZzWHOit5mTpAzElrHrAEdL5JjaXZMhGNWuJWAo5iJoXW8KaDjBXK8jR2vRFZG b4LbrXAU80okrI6ZAjqeI8cS7HgRjpngVgSOYl4MrWNKQMez5FiMHc/DMQVuBeEo5vnQOkYDOp4m x8Ls+Dcco3DLB0cx/w6toxvQ8SQ5FmTHs3B04ZYHjmKeDa2jFdDxODnmY8fTcLTglhOOYp4OpeNm ev9yLcfF4I5h08P0vsiU156M/IrviZvxvXGZnCdD65gY0PEIOeZkx+NwTIRbVjiKeTy0jpcjwRwP kmN2dvwNjpcjm6NZ4Cjmb6F1vBjQcT85ZmXHI3C8CLdMcBTzSGgdzwd03EeOWdjxIBzPwy0FjmIe DKXjWXr/ci3HH8HtBZcSi78vMuW1+yNu7FzkLH5u3BcVc39oHc8GdPyRHFPYcR8cz8LNhaOY+0Lr eCag425yjLHjXjiegZsNRzH3htbxVEDH78jRY8c9cDwFNxOOYu4JreOJgI47yNFmx91wPAG3JDiK uTu0jr8HdNxOjiY7fgfH3+GWAEcxvwut49GAjlvIMYkdd8DxKNwuRfZFxdwRWsfDAR03k2MCO26H 42G4/QtHMbeH0jFPLP4e7VqOEXxiI7jKsfh7P1NeuzVSLnYwkid2Hq5ibg2t4/6AjuvJ8SI7fgPH /XA7B0cxvwmt476AjuvI8Tw7boTjPridhaOYG0PruDeg41pyPMeO6+G4F25n4Cjm+tA67gno+Dk5 /sWOX8FxD9xOwVHMr0LruDug42fkeIYd18JxN9xOwFHMtaF1/C6g4ypyPMWOn8PxO7j9DkcxPw+t 486AjivI8Q92XA3HnXD7DY5irg6lY0OA3wZwLINPfALu4Vj893OmvPbTSKfYt5GGsSORinJ+GlrH bQEdl5LjMXZcCcdtcDsERzFXhtZxS0DHJeR4lB2Xw3EL3A7AUczloXXcFNBxETkeYselcNwEt1/g KObS0DpuCOi4gBwPsOMSOG6A289wFHNJaB2/Dug4jxx/ZcfFcPwabj/BUczFoXVcF9BxLjnuY8eF cFwHtx/hKObC0DquDeg4hxz3suN8OK6F2244ijk/tI6fB3R8nxz3sOOHcPwcbt/BUcwPQ+k4GODq AI6d8Yn3wE3G/IEcB8c+iEzAe5vBeI/TTc4PQuv4aUDHd8jxe3acDcdP4fYtHMWcHVrHlQEdZ5Dj LnacBceVcNsGRzFnhdZxeUDHt8hxBzu+C8flcNsCRzHfDa3jsoCO08lxOzvOhOMyuG2Go5gzQ+v4 cUDHN8hxKzu+DceP4bYRjmK+HVrHjwI6vk6O37Djm3D8CG7r4Sjmm6F1XBTQ8TVy3MSO0+C4CG5f wVHMaaF1XBDQ8VVy3MCOU+G4AG5fwlHMqaF1nBfQcSI5fs2OU+A4D25fwFHMKaF1nBvQcQI5rmPH yXCcC7c1cBRzcmgd5wR0fJkc17LjJDjOgdtncBRzUmgd3w/oOI4cP2fHV+D4PtxWwVHMV0LpuJDe a1/LUbi9CG4jvYc35bXjI+ti70UWxlZE3pBzfGgd3wnoOJocP2XHl+D4Dtw+gaOYL4XWcUZAx5Hk uJIdx8JxBtyWwlHMsaF1fDug4wvkuIIdX4Tj23D7GI5ivhhaxzcDOj5Pjp+w42g4vgm3j+Ao5ujQ Ok4L6DiMHJey40g4ToPbIjiKOTK0jlMDOg4lxyXsOAKOU+G2AI5ijgit45SAjkPIcTE7DofjFLjN g6OYw0PrODmg42ByXMiOz8FxMtzmwlHM50Lr+GpAx0HkuIAdh8LxVbh9AEcxh4bWcWJAx4HkOI8d h8BxItxmw1HMIaF1nBDQsT85zmXHwXCcALdZcBRzcCgdj9LPE9dy3IJP9AOXlBz/OcWU1z4duRR7 OXI09m5kh5xPh9ZxXEDHvuT4PjsOgOM4uM2Eo5gDQus4NqBjH3KcxY794TgWbjPgKGb/0DqOCejY mxzfZcd+cBwDt7fgKGa/0DqOCujYixxnsmNfOI6C23Q4itk3tI4jAzo+Ro4z2LEPHEfCbRocxewT WscRAR17kuNb7NgbjiPgNhWOYvYOrePwgI49yHE6O/aC43C4TYGjmL1C6zgsoGN3cpzGjo/BcRjc XoOjmI+F1nFoQMeu5DiVHXvCcSjcXoWjmD1D6zgkoOND5DiFHXvAcQjcJsJRzB6hdRwc0LEzOU5m x25wHAy3CXAUs1toHQcFdHyQHF9lx65wHAS38XAUs2soHQsnx39mupZjFAsdwdVIjv8sZsprH4pU TR4YKZz8UiSjnA+F1nFAQMcO5PgKO3aBI96HJ4+Do5hdQuv4VEDHduQ4nh0fhONTcHsRjmI+GFrH fgEd25Ljy+zYCY54H548Bo5idgqtY9+Ajm3IcRw7doAj3ocnj4KjmB1C6/hEQMdW5PgiO7aD4xNw ewGOYrYLrWPvgI4tyXEMO7aFI96HJ4+Ao5htQ+vYK6BjC3IcxY5t4Ij34cnD4Shmm9A6PhbQsTk5 jmTH1nDE+/DkYXAUs3VoHXsGdGxKjiPYsSUc8T48eSgcxWwZWsdHAjreR47Ps+P9cHwEbs/CUcz7 Q+vYPaBjY3Icxo7N4dgdbs/AUczmoXXsGtCxETkOZcemcMT78ORBcBSzaWgdHw7o2JAcn2XH++D4 MNyehqOY94XSsXty/Gffazk2xsI94IYlx3+mNuW1TSLP4GeN7viZo7mcTULr2DmgY31yHMyO98Kx M9z6w1HMe0Pr+GBAx7vJcRA7NoLjg3B7Co5iNgqtY8eAjnXJcSA73gPHjnB7Eo5i3hNaxw4BHeuQ 4wB2bADHDnDrC0cxG4TWsV1Ax9rk+BQ73g3HdnB7Ao5i3h1ax7YBHWuRYz92rAfHtnDrDUcx64XW 8YGAjjXJ8Ul2rAvHB+D2OBzFrBtax9YBHe8kxz7seBccW8PtMTiKeVdoHVsFdKxOjk+wY204toLb o3AUs3ZoHe8P6HgHOT7OjjXheD/cHoGjmDVD69gioGNVcuzFjjXg2AJuPeAoZo3QOjYP6FiFHB9j xzvh2Bxu3eEo5p2hdWwa0LESOfZkx2pwbAq3rnAUs1poHe8L6FiRHB9hxzvgeB/cHoajmHeE1rFx QMfy5NidHavAsTHcusBRzCqhdbw3oGM5cuzGjpXheC/cOsNRzMqhdWwY0LEMOT7MjhXh2BBuneAo ZsVQOi6mn++v5TgFC6XBbabfG5jy2gqRr/Hz1GL8XDVdzgqhdWwQ0PF2cuzCjuXh2ABuHeAoZvnQ OtYP6HgbOXZmx3JwrA+39nAUs1xoHesFdCxJjp3YsQwc68GtLRzFLBNax7oBHUuQY0d2LA3HunB7 AI5ilg6tY52AjsXJsQM73g7HOnBrA0cxbw+tY+2AjsXIsR07loJjbbi1gqOYpULrWCugY1FybMuO JeFYC24t4ShmydA61gzoWIQcH2DHEnCsCbf74ShmidA61gjoWJgc27BjcTjWgFsLOIpZPLSO1QM6 FiTHVuxYDI7V4dYMjmIWC61jtYCOBcixJTsWhWM1uDWFo5hFQ+t4R0DH/OR4PzsWgeMdcLsPjmIW Ca1j1YCO+cixBTsWhmNVuDWBo5iFQ+tYOaBjHnJsxo4F4VgZbvfCUcyCoXWsFNAxNzk2ZccCcKwE t0ZwFLNAaB0rBnTMRY73sWN+OFaEW0M4ipk/lI6RlISECgEcj4lrwOUB34QcIyn5IjlSKkQiKfdE TiaLmS+0juUCOuYgx3vZMQ8cy8GtPhzFzBNax7IBHbOTYyN2zA3HsnC7G45i5g6tY5mAjtnIsSE7 5oJjGbjVg6OYuULrWDqgY1ZyvIcdc8KxNNzqwlHMnKF1vD2g483k2IAdb4Hj7XCrA0cxbwmt420B HW8ix/rsmAOOt8HtLjiKmSO0jqUCOmYhx7vZMTscS8GtNhzFzB5ax5IBHTOTYz12zAbHknCrBUcx s4XWsXhAx4zkWIcdb4ZjcbjVgKOYN4fW8daAjhnI8S52vAmOt8LtTjiKeVNoHYsFdEwhx9rsmAWO xeBWHY5iZgmtY9GAjsnkWIsdM8OxKNyqwVHMzKF1LBLQMUaONdkxExyLwO0OOIqZKbSOhQM6Rsmx BjtmhGNhuFWFo5gZQ+tYKKCjR453smMGOBaCWxU4ipkhtI4FAjo65FiNHZPhWABuleAoZnJoHfMH dLTJ8Q52jMExP9wqwlHMWGgd8wV0tMixKjtG4ZgPbhXgKGY0tI55Azqa5FiFHT045oVbeTiK6YXW MU9Axwg5VmZHF4554FYOjmK6oXXMHdDRIMdK7OjAMTfcysJRTCe0jrkCOiaRY0V2tOGYC25l4Cim HVrHnAEdE8mxAjtacMwJt9JwFNMKrWOOgI5XjLhjOXaMwDEH3G6Do5iR0DpmD+h4mRzLsqMBx+xw KwVHMY3QOmYL6HiJHMuwYxIcs8GtJBzFTAqtY9aAjhfJsTQ7JsIxK9xKwFHMxNA63hzQ8V9yvJ0d E+B4M9yKw1HMhNA63hTQ8QI53saOV4wcKTfB7VY4innFCKNj55T47xSv5Vgf3HlsNJh+V2nKay8b /VOyRDqnFIvcK+fl0DpmDuj4DzmWZMdLcMwMt6JwFPNSaB0zBXQ8R44l2PEiHDPBrQgcxbwYWseM AR3/Jsfi7PgvHDPCrTAcxfw3tI4ZAjr+RY63suMFOGaAWyE4inkhtI4pAR3PkmMxdjwPxxS4FYSj mOdD65gc0PFPcizKjv/AMRluBeAo5j+hdYwFdDxDjkXY8RwcY3DLD0cxz4XWMRrQ8TQ5FmbHv+EY hVs+OIr5d2gdvYCOp8ixEDv+BUcPbnnhKOZfoXV0AzqeJMeC7HgWji7c8sBRzLOhdXQCOv5BjgXY 8U84OnDLDUcx/wytox3Q8QQ55mfHM3C04ZYLjmKeCa2jFdDxODnmY8fTcLTglhOOYp4OraMZ0PF3 cszLjqfgaMLtFjiKeSq0jpGAjsfIMQ87noRjBG454CjmydA6GgEdfyPH3Oz4BxwNuGX//9q7D/Ao 6u2N45uE3gKELiooKjYEpFsAUVSaiNgQFCl2xY69K2BvWBCN2BuKSO+9E0Lvvffe2/89m8Mx6lXO vXn2zv7vvMszz3eTmZ3ffHZmdtOeAUbplrg0phXI+Nnw8Yx9sNw6DLROf+acPfrYzUkrCyRmSytQ PNvAaDfHrTHBaVyrxhPMuAnGBNiKwSjdFLfGiNO4Ro2lzLgRxghsRWGUboxbo/z822NcrcaSZtwA 49GktAJFYJRuoDFA4xGncZUaS5hxPYxHYEuBUbo+bo2HncaVaixuxnUwHoatMIzSdXFrPOQ0rlBj MTOuhfEQbIVglK6NW+NBp3G5GouacQ2MB2ErCKN0TdwaDziNy9RYxIyrYTwAWzKM0tVxa9zvNC5V Y4oZV8G4H7YCMEpX0RigcZ/TuESNhc24EsZ9sOWHUboybo17ncbFaixkxhUw7oUtH4zSFXFr3OM0 LlJjQTMuh3EPbHlhlC6PW+Nup3GhGpPNuAzG3bDlgVG6LG6Nu5zGBWosYMalMO6CLTeM0qU0Bmjc 6TTOV2N+My6BcSdsuWCULolb4w6ncZ4a85lxMYw7YMsJo3Rx3Bq3O41z1ZjXjItg3A5bDhili+LW uM1pnKPGPGZcCOM22LLDKF0Yt8atTuNsNeY24wIYt8KWDUbpgrg1bnEaZ6kxlxnnw7gFtiQYpfNp DNC42WmcqcacZpwH42bYEmGUzotb4yancYYac5hxLoybYEuAUTo3bo0bncbpasxuxjkwboQtAqN0 TtwaNziN6WrMZsbZMG6A7WjSwGhnx61xvdM4TY1JZpwF43rYjsAonRW3xnVOY5oaE804E8Z1sB2G UTqTxgCNa53GqWpMMOMMGNfCdghG6Yy4Na5xGqeoMWLG6TCuge0gjNLpcWtc7TROVqP8nivDmA7j atgOwChNj1vjKqdxkhqPmHEajKtg2w+jdFrcGlc6jRPVeNiMaTCuhG0fjNI0GgM0rnAaJ6jxkBmn wrgCtr0wSqfGpbFJcsbv3I5nrILlxmO5O5IzfpeXPfrYKUltk5cnNUnek1Qz2ilxa1zmNI5T4wEz ToZxGWy7YZROpjFA41Kncawa95txEoxLYdsFo3RS3BqXOI1j1LjPjBNhXALbThilE+PWuNhpHK3G vWacAONi2HbAKJ1AY4DGRU7jKDXuMeN4GBfBth1G6fi4NS50GkeqcbcZx8G4ELZtMErH0RigcYHT OEKNu8w4FsYFsG2FUTo2bo3zncbhatxpxjEwzodtC4zSMXFrnOc0DlPjDjOOhnEebJthlI6mMUDj XKdxqBq3m3EUjHNh2wSjdFTcGuc4jUPUuM2MI2GcA9tGGKUjaQzQONtpHKzGrWYcAeNs2DbAKB0R t8ZZTuMgNW4x43AYZ8G2HkbpcBoDNM50GgeqcbMZh8E4E7Z1MEqHxa1xhtM4QI2bzDgUxhmwrYVR OjRujdOdxv5q3GjGITBOh20NjNIhNAZoTHca+6lxgxkHw5gO22oYpYPj1jjNaeyrxvVmHATjNNhW wSgdRGOAxjSnsY8a15lxIIxpsK2EUTowbo1Tncbf1LjWjANgnArbChilA+LWOMVp7K3GNWbsD+MU 2JbDKO1PY4DGyU7jr2pcbcZ+ME6GbRmM0n5xa5zkNPZS4yoz9oVxEmxLYZT2pTFA40Sn8Rc1rjRj HxgnwrYERmmfuDVOcBp/VuMKM/4G4wTYFsMo/S1ujeOdxp5qXG7G3jCOh20RjNLeNAZoHOc0/qTG ZWb8FcZxsC2EUfpr3BrHOo0/qnGpGXvBOBa2BTBKe9EYoHGM0/iDGpeY8RcYx8A2H0bpL3FrHO00 fq/GxWb8GcbRsM2DUfozjQEaRzmN36lxkRl7wjgKtrkwSnvGpXGD/p7/eMZ0LPctlstWMOPvB7JH H/tT0tHkkUkbkuckzY72JxoDNI5wGr9R4wIz/gjjCNhmwyj9kcYAjcOdxq/VON+MP8A4HLZZMEp/ iFvjMKfxKzXOM+P3MA6DbSaM0u9pDNA41Gn8Uo1zzfgdjENhmwGj9DsaAzQOcRq/UOMcM34L4xDY psMo/ZbGAI2DncYeapxtxm9gHAxbOozSb+LWOMhp/FyNs8z4NYyDYJsGo/RrGgM0DnQaU9U404xf wTgQtjQYpV/RGKBxgNP4mRpnmPFLGAfANhVG6Zc0Bmjs7zR+qsbpZvwCxv6wTYFR+kXcGvs5jd3V mG7GHjD2g20yjNIeNAZo7Os0fqLGaWb8HMa+sE2CUfo5jQEa+ziN3dSYZsZUGPvANhFGaSqNARp/ cxo/VuNUM34G42+wTYBR+lncGns7jR+pcYoZP4WxN2zjYZR+SmOAxl+dxg/VONmM3WH8FbZxMEq7 0xigsZfT+IEaJ5nxExh7wTYWRuknNAZo/MVp7KrGiWbsBuMvsI2BUdqNxgCNPzuN76txghk/hvFn 2EbDKP04bo09ncb31DjejB/B2BO2UTBKP6IxQONPTuO7ahxnxg9h/Am2kTBKP6QxQOOPTuM7ahxr xg9g/BG2ETBKP6AxQOMPTuPbahxjxq4w/gDbcBilXePW+L3T+JYaR5vxfRi/h20YjNL3aQzQ+J3T +KYaR5nxPRi/g20ojNL3aAzQ+K3T+IYaR5rxXRi/hW0IjNJ3aQzQ+I3T+LoaR5jxHRi/gW0wjNJ3 4tb4tdP4mhqHm/FtGL+GbRCM0rdpDND4ldP4qhqHmfEtGL+CbSCM0rdoDND4pdPYRY1DzfgmjF/C NgBG6Zs0Bmj8wmnsrMYhZnwDxi9g6w+j9I24NfZwGjupcbAZX4exB2z9YJS+TmOAxs+dxlfUOMiM r8H4OWx9YZS+RmOAxlSn8WU1DjTjqzCmwtYHRumrNAZo/MxpfEmNA8zYBcbPYPsNRmkXGgM0fuo0 vqjG/mbsDOOnsPWGUdo5bo3dncYX1NjPjJ1g7A7brzBKO9EYoPETp/F5NfY14yswfgJbLxilr9AY oLGb0/icGvuY8WUYu8H2C4zSl2kM0Pix0/isGn8z40swfgzbzzBKX4pb40dO4zNq7G3GF2H8CLae MEpfpDFA44dO49Nq/NWML8D4YfTaB7OjfYHGgIx9Cmb8rd/xjN2w3FNYLq1gxt8QZo8+9vmkiQU/ SOpT8Mek1GifpzFAY1en8Uk1/mLG52DsCtsPMEqfo5HGmBrfdxqfUOPPZnwWxvdh+x5G6bM0Bmh8 z2l8XI09zfgMjO/B9h2M0mdoDND4rtP4mBp/MuPTML4L27cwSp+mkcaYGt9xGjuq8UczPgXjO7B9 A6P0KRoDNL7tND6qxh/M+CSMb8P2NYzSJ2kM0PiW0/iIGr834xMwvgXbVzBKn6CRxpga33QaH1bj d2Z8HMY3YfsSRunjNAZofMNpfEiN35rxMRjfgO0LGKWP0UhjTI2vO40PqvEbM3aE8XXYesAo7Uhj gMbXnMYH1Pi1GR+F8TXYPodR+iiNARpfdRrvV+NXZnwExldhS4VR+giNNMbU2MVp7KDGL834MIxd YPsMRunDNAZo7Ow03qfGL8z4EIydYfsURulDNAZo7OQ03qvGHmZ8EMZOsHWHUfogjTTG1PiK03iP Gj834wMwvgLbJzBKH6AxQOPLTuPdakw14/0wvgxbNxil99MYoPElp/EuNX5mxg4wvgTbxzBKO9BI Y0yNLzqNd6rxUzPeB+OLsH0Eo/Q+GgM0vuA03qHG7ma8F8YXYPsQRum9NAZofN5pvF2Nn5jxHhif h+0DGKX30EhjTI3POY23qbGbGe+G8TnYusIovZvGAI3POo3t1fixGe+C8VnY3odReheNARqfcRrb qfEjM94J4zOwvQej9E4aaYyp8Wmnsa0aPzTjHTA+Ddu7MErvoDFA41NOYxs1fmDG22F8CrZ3YJTe TiONMTU+6TTeqsauZrwNxidhextG6W00Bmh8wmlsrcb3zdgexidgewtGaXsaAzQ+7jTeosb3zNgO xsdhexNGaTsaaYyp8TGn8WY1vmvGtjA+BtsbMErb0higsaPT2EqN75ixDYwdYXsdRmkbGgM0Puo0 tlTj22a8FcZHYXsNRumtNNIYU+MjTuNNanzLjK1hfAS2V2GUtqYxQOPDTmMLNb5pxltgfBi2LjBK b6ExQONDTuONanzDjDfD+BBsnWGU3kwjjTE1Pug03qDG183YCsYHYesEo7QVjQEaH3Aar1fja2Zs CeMDsL0Co7QljQEa73car1Pjq2a8Ccb7YXsZRulNNNIYU2MHp/FaNXYxYwsYO8D2EozSFjQGaLzP aWyuxs5mvBHG+2B7EUbpjTQGaLzXabxGjZ3MeAOM98L2AozSG2ikMabGe5zGZmp8xYzXw3hP9Pq5 qdFeT2OAxrudxqvV+LIZr4Px7ui1ZVOjvY7GAI13OY1N1fiSGa+F8a7otWVTo72WRhpjarzTabxK jS+asTmMd0avn5sabXMaAzTe4TQ2UeMLZrwGxjui15ZNjfYaGmmMqfF2p7GxGp83YzMYb49ePzc1 2mY0Bmi8zWlspMbnzHg1jLdFr5+bGu3VNAZobO80NlTjs2ZsCmP76LVlU6NtSiONMTW2cxobqPEZ M14FY7vo9XNTo72KxgCNbZ3GK9X4tBmbwNg2em3Z1Gib0BigsY3TeIUanzJjYxjbRK8tmxptYxpp jKnxVqfxcjU+acZGMN4avX5uarSNaAzQ2NpprK/GJ8zYEMbW0WvLpkbbkMYAjbc4jZep8XEzNoDx lui1ZVOjbRCXxvRCPmO/QhnGDYV+N6YXapC0utAtSemFHk4aHC2NNMbWeLPTeKkaHzPjlTDeDNtD MEqvpJHGmBpbOY311NjRjFfA2Aq2B2GUXkEjjTRm0djSabxEjY+a8XIYW8L2AIzSy2mkMabGm5zG ump8xIz1YbwJtvthlNankUYas2hs4TTWUePDZrwMxhawdYBRehmNNMbUeKPTWFuND5nxUhhvhO0+ GKWX0kgjjVk03uA0XqzGB81YD8YbYLsXRmk9GmmkMYvG653Gi9T4gBkvgfF62O6BUXoJjTTG1Hid 03ihGu83Y10Yr4PtbhildWmkkcYsGq91Gi9QYwcz1oHxWtjuglFah0YaY2ps7jTWUuN9ZqwNY3PY 7oRRWptGGmnMovEap7GmGu8148UwXgPbHTBKL6aRxpgamzmNNdR4jxkvgrEZbLfDKL2IRhppzKLx aqexuhrvNuOFMF4N220wSi+kkcaYGps6jdXUeJcZL4CxKWztYZReQCONNGbReJXTWFWNd5qxFoxX wdYORmktGmmMqbGJ01hFjXeYsSaMTWBrC6O0Jo000phFY2On8Xw13m7GGjA2hq0NjNIaNNIYU2Mj p7GyGm8zY3UYG8F2K4zS6jTSSGMWjQ2dxkpqbG/GajA2hK01jNJqNNIYU2MDp7GiGtuZsSqMDWC7 BUZpVRpppDGLxiudxvPU2NaMVWC8ErabYZRWoZHGmBqvcBorqLGNGc+H8QrYWsEoPZ9GGmnMovFy p/FcNd5qxsowXg5bSxillWmkkcYsGus7jeeosbUZK8FYH7abYJRWopHGmBovcxrPVuMtZqwI42Ww tYBRWpFGGmnMovFSp/EsNd5sxvNgvBS2G2GUnkcjjTE11nMaz1RjKzNWgLEebDfAKK1AI400ZtF4 idNYXo0tzXgujJfAdj2M0nNppDGmxrpO4xlqvMmM58BYF7brYJSeQyONNGbRWMdpPF2NLcx4Nox1 YLsWRunZNNIYU2Ntp/E0Nd5oxrNgrA1bcxilZ9FII41ZNF7sNJZT4w1mPBPGi2G7BkbpmTTSGFPj RU7jqWq83ozlYbwItmYwSsvTSCONWTRe6DSeosbrzHgGjBfCdjWM0jNopDGmxgucxrJqvNaMp8N4 AWxNYZSeTiONNGbRWMtpLKPG5mY8DcZasF0Fo/Q0GmmMqbGm03iyGq8xYzkYa8LWBEZpORpppDGL xhpO40lqbGbGU2GsAVtjGKWn0khjTI3VncYT1Xi1GU+BsTpsjWCUnkIjjTRm0VjNaSytxqZmLAtj NdgawigtSyONMTVWdRpPUONVZiwDY1XYGsAoLUMjjTRm0VjFaSylxiZmPBnGKrBdCaP0ZBpppDGL xvOdxpJqbGzGk2A8H7YrYJSeRCONMTVWdhpLqLGRGU+EsTJsl8MoPZFGGmnMorGS01hcjQ3NWBrG SrDVh1FamkYaY2qs6DQWU2MDM54AY0XYLoNRegKNNNKYReN5TmNRNV5pxlIwngfbpTBKS9FIY0yN FZzGImq8wowlYawAWz0YpSVppJHGLBrPdRpT1Hi5GUvAeC5sl8AoLUEjjTE1nuM0FlZjfTMWh/Ec 2OrCKC1OI400ZtF4ttNYSI2XmbEYjGfDVgdGaTEaaYyp8SynsaAaLzVjURjPgq02jNKiNNJIYxaN ZzqNyWqsZ8YiMJ4J28UwSovQSGNMjeWdxgJqvMSMKTCWh+0iGKUpNNJIYxaNZziN+dVY14yFYTwD tgthlBamkcaYGk93GvOpsY4ZC8F4OmwXwCgtRCONNGbReJrTmFeNtc1YEMbTYKsFo7QgjTTG1FjO acyjxovNmAxjOdhqwihNppFGGrNoPNVpzK3Gi8xYAMZTYasBo7RAXBr7pfiM3VMyjJNTfjf2SymQ NDnl1KR+KTWSekRLI4000kijGE9xGnOp8UIz5ofxFNiqwyjNTyONNNJIY0iMZZ3GnGq8wIz5YCwL WzUYpflopJFGGmkMibGM05hDjbXMmBfGMrBVhVGal0YaaaSRxpAYT3Yas6uxphnzwHgybFVglOah kUYaaaQxJMaTnMZsaqxhxtwwngTb+TBKc9NII4000hgS44lOY5Iaq5sxF4wnwlYZRmkuGmmkkUYa Q2Is7TQmqrGaGXPCWBq2SjBKc9JII4000hgS4wlOY4Iaq5oxB4wnwFYRRmkOGmmkkUYaQ2Is5TRG 1FjFjNlhLAXbeTBKs9NII4000hgSY0mn8WhihvF8M2aDsSRsFWCUZqORRhpppDEkxhJO4xE1VjZj EowlYDsXRmkSjTTSSCONITEWdxoPq7GSGRNhLA7bOTBKE2mkkUYaaQyJsZjTeEiNFc2YAGMx2M6G UZpAI4000khjSIxFncaDajzPjBEYi8J2FozSCI000kgjjSExFnEaD6ixghmPJk5OKQLbmTBKjybS SCONNNIYDmOK07hfjeea8QiMKbCVh1F6hEYaaaSRxpAYCzuN+9R4jhkPw1gYtjNglB6mkUYaaaQx JMZCTuNeNZ5txkMwFoLtdBilh2ikkUYaaaTxf8ZY0Gnco8azzHgQxoKwnQaj9CCNNNJII40hMSY7 jbvVeKYZD8CYDFs5GKUHaKSRRhppDImxgNO4S43lzbgfxgKwnQqjdD+NNNJII40hMeZ3Gneq8Qwz 7oMxP2ynwCjdRyONNNJIY0iM+ZzGHWo83Yx7YcwHW1kYpXtppJFGGmkMiTGv07hdjaeZcQ+MeWEr A6N0D4000kgjjSEx5nEat6mxnBl3w5gHtpNhlO6mkUYaaaQxJMbcTuNWNZ5qxl0w5obtJBilu2ik kUYaaQyJMZfTuEWNp5hxJ4y5YDsRRulOGmmkkUYaQ2LM6TRuVmNZM+6AMSdspWGU7qCRRhpppDEk xhxO4yY1ljHjdhhzwHYCjNLtNNJII400hsSY3WncqMaTzbgNxuywlYJRuo1GGmmkkcaQGLM5jRvU eJIZt8KYDbaSMEq30kgjjTTSGBJjktO4Xo0nmnELjEmwlYBRuoVGGmmkkcaQGBOdxnVqLG3GzTAm wlYcRulmGmmkkUYaQ2JMcBrXqvEEM26CMQG2YjBKN9FII4000hgSY8RpXKPGUmbcCGMEtqIwSjfS SCONNNIYEuPRRJ9xtRpLmnEDjEcT+6UUgVG6gUYaaaSRRhr/Z4xHnMZVaixhxvUwHoEtBUbpehpp pJFGGkNiPOw0rlRjcTOug/EwbIVhlK6jkUYaaaQxJMZDTuMKNRYz41oYD8FWCEbpWhpppJFGGkNi POg0LldjUTOugfEgbAVhlK6hkUYaaaQxJMYDTuMyNRYx42oYD8CWDKN0NY000kgjjSEx7ncal6ox xYyrYNwPWwEYpatopJFGGmkMiXGf07hEjYXNuBLGfbDlh1G6kkYaaaSRxpAY9zqNi9VYyIwrYNwL Wz4YpStopJFGGmkMiXGP07hIjQXNuBzGPbDlhVG6nEYaaaSRxpAYdzuNC9WYbMZlMO6GLQ+M0mU0 0kgjjTSGxLjLaVygxgJmXArjLthywyhdSiONNNJIY0iMO53G+WrMb8YlMO6ELReM0iU00kgjjTSG xLjDaZynxnxmXAzjDthywihdTCONNNJIY0iM253GuWrMa8ZFMG6HLQeM0kU00kgjjTSGxLjNaZyj xjxmXAjjNtiywyhdSCONNNJIY0iMW53G2WrMbcYFMG6FLRuM0gU00kgjjTSGxLjFaZylxlxmnA/j FtiSYJTOp5FGGmmkMSTGzU7jTDXmNOM8GDfDlgijdB6NNNJII400/s8YNzmNM9SYw4xzYdwEWwKM 0rk00kgjjTSGxLjRaZyuxuxmnAPjRtgiMErn0EgjjTTSGBLjBqcxXY3ZzDgbxg2wHU3sEe1sGmmk kUYaQ2Jc7zROU2OSGWfBuB62IzBKZ9FII4000hgS4zqnMU2NiWacCeM62A7DKJ1JI4000khjSIxr ncapakww4wwY18J2CEbpDBpppJFGGkNiXOM0TlFjxIzTYVwD20EYpdNppJFGGmkMiXG10zhZjUcT jxnTYVwN2wEYpek00kgjjTSGxLjKaZykxiNmnAbjKtj2wyidRiONNNJIY0iMK53GiWo8bMY0GFfC tg9GaRqNNNJII40hMa5wGieo8ZAZp8K4Ara9MEqn0kgjjTTSGBLjcqdxvBoPmnEKjMth2wOjdAqN NNJII40hMS5zGsep8YAZJ8O4DLbdMEon00gjjTTSGBLjUqdxrBr3m3ESjEth2wWjdBKNNNJII40h MS5xGseocZ8ZJ8K4BLadMEon0kgjjTTSGBLjYqdxtBr3mnECjIth2wGjdAKNNNJII40hMS5yGkep cY8Zx8O4CLbtMErH00gjjTTSGBLjQqdxpBp3m3EcjAth2wajdByNNNJII400/s8YFziNI9S4y4xj YVwA21YYpWNppJFGGmkMiXG+0zhcjTvNOAbG+bBtgVE6hkYaaaSRxpAY5zmNw9S4w4yjYZwH22YY paNppJFGGmkMiXGu0zhUjdvNOArGubBtglE6ikYaaaSRxpAY5ziNQ9S4zYwjYZwD20YYpSNppJFG GmkMiXG20zhYjVvNOALG2bBtgFE6gkYaaaSRxpAYZzmNg9S4xYzDYZwF23oYpcNppJFGGmkMiXGm 0zhQjZvNOAzGmbCtg1E6jEYaaaSRxpAYZziNA9S4yYxDYZwB21oYpUNppJFGGmkMiXG609hfjRvN OATG6bCtgVE6hEYaaaSRxpAY053GfmrcYMbBMKbDthpG6WAaaaSRRhpDYpzmNPZV43ozDoJxGmyr YJQOopFGGmmkMSTGNKexjxrXmXEgjGmwrYRROpBGGmmkkcaQGKc6jb+pca0ZB8A4FbYVMEoH0Egj jTTSGBLjFKextxrXmLE/jFNgWw6jtD+N/2VjPGzLNGxLt4C35djtwmKRSJVkbsvfbUuJTMuX/H3M f3luJGBqjukeTLuwj5th5hIs2DN/xrzeXTvVadiwU51j8+R8aRT54+2o3m6InmMVMFWMbn8FTMW1 MjXQse7XsSrkxTYUjUS65P3rWDIvx3HGqpxptAqO8XLnzhivXe6/jifzjjdelX9zvNU5Msark/Ov 48m8441X7d8cb2S2jPFKZ//reDLveOPVcI73mI7XHQdtraIZ/2fXn8eTeTn/YbyWuF8pOtYfjxfP uFIZd2bkr+M+FvGMW9k97n/jvJZzM/M5G+RrjHdb/um1RKZU7IuJ+TPew8oV+ON+OjYv4R/2U9Po fsrYD7I+OT5r5c94XNf8f13nsXmJx11nRdu/st7WmGblyHhsq5x/Xe+xeUn/sN7mdiz/8ViSz7fD 1CGSsY7TE/66/mPzsrnWX/EP668Qp8dnQqb15M+0LZ7P/6eOhCw4quC1vzb2SyO856QX+Odj+31M dbD8tViuNpbv86f9eWxevn/Yn3JMNI20x78HIw9FyuD1W+6VidSNXBOpnmnflsn0mnR+ps/JxzUx VY/T5/Pvjov/D8fC5XhfqYFzfh66M+ffHwvN5H03IeProZ6yMtxeSsqY5Boy0Ru+MamLPXtn5Nbo 11f/6e2pGSmRMskJFR8vXDZH7nKRSK9ZKdHtKjGkV97I6Is/eufkhIoJ5csua7M+JZJHjlEsL/fH DOuV98Dd2zsOwceVlkcqLqvSK++yVidFHsU8WVfZyKsJrav2yrsO8xu0Sagoy8u6j90ufbczXtIy 1iMffymvXzNTIqXT8laU+/KcyziyvhIzMyofl5mdkmnrt3ec9PX2jrJ9NbBMIXkf340DowWO5Yq7 O8rrb+OIjJLxHMs+Ko9pQSTjeWz3aHQY24fZ9TzsjKkF9lE97KuB6No/fY3VQj+X5x/Ow9bR9ZbB 6/NtehZmnJENMp1zpf90/mU+LzMfb+Uzbd//p3MynrYF63mu/L9YZ85Mn0/60/ObeRtz688Cjq33 2Db/3fZkfmwefeyx2/EeWz7T+2f5TM9J5nXWj37PkDH/ssb1zz6rDs4few6eqx39Ji46/X6/vh5z BfUxiXV+HxNvK9HzXl9aovf/D7vKk7NQABYkARckAUlmAQAAAAGWAAAhdgACaAE11gUAAQNMETXW BQECA0wRI3YAAkwROlYQAAKWbAAKdAAA4AEU9gEAABU2ATXWBQACA0wReXRFA+gAUAAWJAEXJAFJ ZgEAAAABlgAAIXYAAmgBNdYFAAEDTBE11gUBAgNMESN2AAJMETpWEAAClmwACnQAAOABFPYBAAAV NgE11gUAAgNMEXl0RQPoAFAAFiQBFyQBSWYBAAAAAZYAACF2AAJoATXWBQABA0wRNdYFAQIDTBEj dgACTBE6VhAAApZsAAp0AADgART2AQAAFTYBNdYFAAIDTBF5dEUD6ABQABYkARckAUlmAQAAAAGW AAAhdgACaAE11gUAAQNMETXWBQECA0wRI3YAAkwROlYQAAKWbAAKdAAA4AEU9gEAABU2ATXWBQAC A0wReXRFA+gAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AACGAhEAEgABAJwADwAEAAAAAwAAAAAABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAABEAABA8f8CAEQADAQAAAAAAAAAAAYATgBvAHIAbQBhAGwA AAACAAAAHABDShgAX0gBBGFKGABtSAkEbkgSBHNICQR0SBIEAAAAAAAAAAAAAAAAAAAAAAAARABB QPL/oQBEAAwFAAAAAAAAAAAWAEQAZQBmAGEAdQBsAHQAIABQAGEAcgBhAGcAcgBhAHAAaAAgAEYA bwBuAHQAAAAAAFIAaUDz/7MAUgAMBQAAAAAAAAAADABUAGEAYgBsAGUAIABOAG8AcgBtAGEAbAAA ABwAF/YDAAA01gYAAQoDbAA01gYAAQUDAABh9gMAAAIACwAAACgAawD0/8EAKAAABQAAAAAAAAAA BwBOAG8AIABMAGkAcwB0AAAAAgAAAAAAAAA2AFVAogDxADYADAQAAIcgNQAAAAkASAB5AHAAZQBy AGwAaQBuAGsAAAAMAD4qAUIqAnBoAAD/AGoAmkCzAAMBagAMBAAAhyA1AAAACgBUAGEAYgBsAGUA IABHAHIAaQBkAAAANwA6VhAAE9YwAAAA/wQBAAAAAAD/BAEAAAAAAP8EAQAAAAAA/wQBAAAAAAD/ BAEAAAAAAP8EAQAAAAIAEAAAAAAAAACeFwAABQAA+AAAAAD/////AAAAAAEAAAARAAAAEgAAABoA AABPAAAAUAAAAFoAAACDAAAAhAAAAJ4AAADSAAAA0wAAABUBAAAmAQAANQEAAEMBAABEAQAAZQEA AGsBAABsAQAAbQEAAG4BAAAKAgAACwIAAG0CAABuAgAA5AIAAOUCAAD3AgAA+AIAACQDAAAlAwAA LQMAADMDAAA+AwAAPwMAAEMDAABIAwAATQMAAE4DAABSAwAAVwMAAFwDAABdAwAAYQMAAGYDAABq AwAAawMAAG8DAAB0AwAAeAMAAHkDAAB9AwAAgQMAAIUDAACGAwAAigMAAI4DAACSAwAAkwMAAJcD AACbAwAAnwMAAKADAACkAwAAqAMAAKwDAACtAwAAsQMAALUDAAC5AwAAugMAAL4DAADCAwAAxgMA AMcDAADIAwAAyQMAANcEAADYBAAAPwUAAEAFAABQBQAAUQUAAHQFAAB4BQAAgAUAAIQFAACKBQAA lQUAAJYFAACbBQAAnwUAAMIFAADGBQAAygUAAMsFAADQBQAA1AUAAOoFAADuBQAA8gUAAPMFAAD4 BQAA/AUAABkGAAAdBgAAIQYAACIGAAAnBgAAKwYAAEAGAABEBgAASAYAAEkGAABOBgAAUgYAAGwG AABwBgAAdAYAAHUGAAB6BgAAfgYAAKsGAACvBgAAswYAALQGAAC5BgAAvQYAAN4GAADiBgAA5gYA AOcGAADtBgAA8QYAACQHAAAoBwAALAcAAC0HAAAyBwAANgcAAFYHAABaBwAAXgcAAF8HAABlBwAA aQcAAIUHAACJBwAAjQcAAI4HAACTBwAAlwcAAK0HAACxBwAAtQcAALYHAAC8BwAAwAcAAO8HAADz BwAA9wcAAPgHAAD9BwAAAQgAABMIAAAXCAAAGwgAABwIAAAhCAAAJQgAAFMIAABXCAAAWwgAAFwI AABhCAAAZQgAAIQIAACICAAAjAgAAI0IAACTCAAAlwgAALQIAAC4CAAAvAgAAL0IAADCCAAAxggA AOYIAADqCAAA7ggAAO8IAAD0CAAA+AgAAA4JAAASCQAAFgkAABcJAAAbCQAAHwkAAE8JAABTCQAA VwkAAFgJAABdCQAAYQkAAHoJAAB+CQAAggkAAIMJAACECQAAnwkAAKMJAACrCQAArwkAALUJAADA CQAAwQkAAMYJAADKCQAA6wkAAO8JAADzCQAA9AkAAPoJAAD+CQAALQoAADEKAAA1CgAANgoAADwK AABACgAAYwoAAGYKAABqCgAAawoAAHAKAAB0CgAAmwoAAJ4KAACiCgAAowoAAKkKAACtCgAA3AoA AN8KAADjCgAA5AoAAOoKAADuCgAAGgsAAB0LAAAhCwAAIgsAACgLAAAsCwAAWwsAAF4LAABiCwAA YwsAAGcLAABrCwAAfQsAAIALAACECwAAhQsAAIsLAACPCwAAswsAALYLAAC6CwAAuwsAAMELAADF CwAA+wsAAP4LAAACDAAAAwwAAAkMAAANDAAAPAwAAD8MAABDDAAARAwAAEkMAABNDAAAdQwAAHgM AAB8DAAAfQwAAIMMAACHDAAAqwwAAK4MAACyDAAAswwAALgMAAC8DAAA8gwAAPUMAAD5DAAA+gwA AAANAAAEDQAAKA0AACsNAAAvDQAAMA0AADYNAAA6DQAAaQ0AAGwNAABwDQAAcQ0AAHcNAAB7DQAA sQ0AALQNAAC4DQAAuQ0AAL8NAADDDQAA5w0AAOoNAADuDQAA7w0AAPUNAAD5DQAAIg4AACUOAAAp DgAAKg4AACsOAAAsDgAA6w8AAOwPAAALEAAAExAAABgQAAAdEAAAJxAAACgQAAAsEAAASRAAAE0Q AABTEAAAVBAAAFgQAABuEAAAchAAAHkQAAB6EAAAfhAAAJsQAACfEAAApRAAAKYQAACqEAAAtxAA ALsQAADCEAAAwxAAAMcQAADhEAAA5RAAAOwQAADtEAAA8RAAAAkRAAANEQAAFBEAABURAAAZEQAA PREAAEERAABHEQAASBEAAEwRAAB5EQAAfREAAIQRAACFEQAAiREAAKERAAClEQAAqxEAAKwRAACw EQAA2REAAN0RAADkEQAA5REAAOkRAAAAEgAABBIAAAsSAAAMEgAAEBIAACASAAAkEgAAKxIAACwS AAAwEgAAPhIAAEISAABJEgAAShIAAE4SAABuEgAAchIAAHkSAAB6EgAAfhIAAJASAACUEgAAmxIA AJwSAACgEgAAxRIAAMkSAADQEgAA0RIAANUSAADrEgAA7xIAAPYSAAD3EgAA+xIAABoTAAAeEwAA JRMAACYTAAAqEwAAVhMAAFoTAABhEwAAYhMAAGMTAABkEwAAgBMAAIUTAACLEwAAlhMAAJcTAACv EwAAsxMAALoTAAC7EwAA3xMAAOMTAADpEwAA6hMAAAIUAAAGFAAADBQAAA0UAAAtFAAAMRQAADgU AAA5FAAAZRQAAGkUAABwFAAAcRQAAIoUAACOFAAAlRQAAJYUAACuFAAAshQAALkUAAC6FAAAzhQA ANEUAADYFAAA2RQAAOAUAADjFAAA6hQAAOsUAAAGFQAACRUAABAVAAARFQAALBUAAC8VAAA2FQAA NxUAAE8VAABSFQAAWRUAAFoVAABuFQAAcRUAAHgVAAB5FQAAmBUAAJsVAACiFQAAoxUAAMcVAADK FQAA0BUAANEVAADzFQAA9hUAAPwVAAD9FQAAIxYAACYWAAAtFgAALhYAAFgWAABbFgAAYhYAAGMW AACLFgAAjhYAAJUWAACWFgAApxYAAKoWAACxFgAAshYAALMWAAC0FgAA3RYAAN8WAADgFgAA4RYA APwWAAD9FgAAIRcAADIXAAAzFwAAVhcAAGcXAABoFwAAixcAAJwXAACdFwAAoBcAAJgAAAAAMAAA AAAAAACAAAAAgAAAAAAAAAAAAACYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAAAwAAAA AAAAAIAAAACAAAAAAAAAAAAAAKkAAAAAMAAAAAAAAACAAAAAgAEAANAAAAAAIACpAAAAADAAAAAA AAAAgAAAAIABAADQAAAAACAAmQAAAAAwAAAAAAAAAIAAAACAAQAA1AAAAAAgAKkAAAAAMAAAAAAA AACAAAAAgAEAANAAAAAAIACpAAAAADAAAAAAAAAAgAAAAIABAADQAAAAACAAmQAAAAAwAAAAAAAA AIAAAACAAQAA1AAAAAAgAKkAAAAAMAAAAAAAAACAAAAAgAEAANAAAAAAIACpAAAAADAAAAAAAAAA gAAAAIABAADQAAAAACAAmQAAAAAwAAAAAAAAAIAAAACAAQAA1AAAAAAgAKkAAAAAMAAAAAAAAACA AAAAgAEAANAAAAAAIACpAAAAADAAAAAAAAAAgAAAAIABAADQAAAAAAAAqQAAAAAwAAAAAAAAAIAA AACAAQAA0AAAAAAAAKkAAAAAMAAAAAAAAACAAAAAgAEAANAAAAAAIACZAAAAADAAAAAAAAAAgAAA AIABAADUAAAAACAAqQAAAAAwAAAAAAAAAIAAAACAAQAA0AAAAAAgAKkAAAAAMAAAAAAAAACAAAAA gAEAANAAAAAAIACZAAAAADAAAAAAAAAAgAAAAIABAADUAAAAACAAmAAAAAAwAAAAAAAAAIAAAACA AAAAAAAAAAAAAJgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAAADAAAAAAAAAAgAAAAIAA AAAAAAAAAAAAmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAAMAAAAAAAAACAAAAAgAAA AAAAAAAAAACYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAAAwAAAAAAAAAIAAAACAAAAA AAAAAAAAAJgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAAADAAAAAAAAAAgAAAAIAAAAAA AAAAAAAAmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAAMAAAAAAAAACAAAAAgAAAAAAA AAAAAACYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAqQAAAAAwAAAAAAAAAIAAAACAAQAA0AAA AAAgAKkAAAAAMAAAAAAAAACAAAAAgAEAANAAAAAAIACpAAAAADAAAAAAAAAAgAAAAIABAADQAAAA ACAAmQAAAAAwAAAAAAAAAIAAAACAAQAA1AAAAAAgAKkAAAAAMAAAAAAAAACAAAAAgAEAANAAAAAA IACpAAAAADAAAAAAAAAAgAAAAIABAADQAAAAACAAqQAAAAAwAAAAAAAAAIAAAACAAQAA0AAAAAAg AJkAAAAAMAAAAAAAAACAAAAAgAEAANQAAAAAIACpAAAAADAAAAAAAAAAgAAAAIABAADQAAAAACAA qQAAAAAwAAAAAAAAAIAAAACAAQAA0AAAAAAgAKkAAAAAMAAAAAAAAACAAAAAgAEAANAAAAAAIACZ AAAAADAAAAAAAAAAgAAAAIABAADUAAAAACAAqQAAAAAwAAAAAAAAAIAAAACAAQAA0AAAAAAgAKkA AAAAMAAAAAAAAACAAAAAgAEAANAAAAAAIACpAAAAADAAAAAAAAAAgAAAAIABAADQAAAAACAAmQAA AAAwAAAAAAAAAIAAAACAAQAA1AAAAAAgAKkAAAAAMAAAAAAAAACAAAAAgAEAANAAAAAAIACpAAAA ADAAAAAAAAAAgAAAAIABAADQAAAAACAAqQAAAAAwAAAAAAAAAIAAAACAAQAA0AAAAAAgAJkAAAAA MAAAAAAAAACAAAAAgAEAANQAAAAAIACpAAAAADAAAAAAAAAAgAAAAIABAADQAAAAACAAqQAAAAAw AAAAAAAAAIAAAACAAQAA0AAAAAAgAKkAAAAAMAAAAAAAAACAAAAAgAEAANAAAAAAIACZAAAAADAA AAAAAAAAgAAAAIABAADUAAAAACAAqQAAAAAwAAAAAAAAAIAAAACAAQAA0AAAAAAgAKkAAAAAMAAA AAAAAACAAAAAgAEAANAAAAAAIACpAAAAADAAAAAAAAAAgAAAAIABAADQAAAAACAAmQAAAAAwAAAA AAAAAIAAAACAAQAA1AAAAAAgAKkAAAAAMAAAAAAAAACAAAAAgAEAANAAAAAAIACpAAAAADAAAAAA AAAAgAAAAIABAADQAAAAACAAqQAAAAAwAAAAAAAAAIAAAACAAQAA0AAAAAAgAJkAAAAAMAAAAAAA AACAAAAAgAEAANQAAAAAIACpAAAAADAAAAAAAAAAgAAAAIABAADQAAAAACAAqQAAAAAwAAAAAAAA AIAAAACAAQAA0AAAAAAgAKkAAAAAMAAAAAAAAACAAAAAgAEAANAAAAAAIACZAAAAADAAAAAAAAAA gAAAAIABAADUAAAAACAAqQAAAAAwAAAAAAAAAIAAAACAAQAA0AAAAAAgAKkAAAAAMAAAAAAAAACA AAAAgAEAANAAAAAAIACpAAAAADAAAAAAAAAAgAAAAIABAADQAAAAACAAmQAAAAAwAAAAAAAAAIAA AACAAQAA1AAAAAAgAKkAAAAAMAAAAAAAAACAAAAAgAEAANAAAAAAIACpAAAAADAAAAAAAAAAgAAA AIABAADQAAAAACAAqQAAAAAwAAAAAAAAAIAAAACAAQAA0AAAAAAgAJkAAAAAMAAAAAAAAACAAAAA gAEAANQAAAAAIACYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAAAwAAAAAAAAAIAAAACA AAAAAAAAAAAAAJgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAAADAAAAAAAAAAgAAAAIAA AAAAAAAAAAAAmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAAMAAAAAAAAACAAAAAgAAA AAAAAAAAAACYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAAAwAAAAAAAAAIAAAACAAAAA AAAAAAAAAJgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAACpAAAAADAAAAAAAAAAgAAAAIABAADQ AAAAACAAqQAAAAAwAAAAAAAAAIAAAACAAQAA0AAAAAAgAKkAAAAAMAAAAAAAAACAAAAAgAEAANAA AAAAIACpAAAAADAAAAAAAAAAgAAAAIABAADQAAAAACAAqQAAAAAwAAAAAAAAAIAAAACAAQAA0AAA AAAgAJkAAAAAMAAAAAAAAACAAAAAgAEAANQAAAAAIACpAAAAADAAAAAAAAAAgAAAAIABAADQAAAA ACAAqQAAAAAwAAAAAAAAAIAAAACAAQAA0AAAAAAgAKkAAAAAMAAAAAAAAACAAAAAgAEAANAAAAAA IACpAAAAADAAAAAAAAAAgAAAAIABAADQAAAAACAAqQAAAAAwAAAAAAAAAIAAAACAAQAA0AAAAAAg AJkAAAAAMAAAAAAAAACAAAAAgAEAANQAAAAAIACpAAAAADAAAAAAAAAAgAAAAIABAADQAAAAACAA qQAAAAAwAAAAAAAAAIAAAACAAQAA0AAAAAAgAKkAAAAAMAAAAAAAAACAAAAAgAEAANAAAAAAIACp AAAAADAAAAAAAAAAgAAAAIABAADQAAAAACAAqQAAAAAwAAAAAAAAAIAAAACAAQAA0AAAAAAgAJkA AAAAMAAAAAAAAACAAAAAgAEAANQAAAAAIACpAAAAADAAAAAAAAAAgAAAAIABAADQAAAAACAAqQAA AAAwAAAAAAAAAIAAAACAAQAA0AAAAAAgAKkAAAAAMAAAAAAAAACAAAAAgAEAANAAAAAAIACpAAAA ADAAAAAAAAAAgAAAAIABAADQAAAAACAAqQAAAAAwAAAAAAAAAIAAAACAAQAA0AAAAAAgAJkAAAAA MAAAAAAAAACAAAAAgAEAANQAAAAAIACpAAAAADAAAAAAAAAAgAAAAIABAADQAAAAACAAqQAAAAAw AAAAAAAAAIAAAACAAQAA0AAAAAAgAKkAAAAAMAAAAAAAAACAAAAAgAEAANAAAAAAIACpAAAAADAA AAAAAAAAgAAAAIABAADQAAAAACAAqQAAAAAwAAAAAAAAAIAAAACAAQAA0AAAAAAgAJkAAAAAMAAA AAAAAACAAAAAgAEAANQAAAAAIACpAAAAADAAAAAAAAAAgAAAAIABAADQAAAAACAAqQAAAAAwAAAA AAAAAIAAAACAAQAA0AAAAAAgAKkAAAAAMAAAAAAAAACAAAAAgAEAANAAAAAAIACpAAAAADAAAAAA AAAAgAAAAIABAADQAAAAACAAqQAAAAAwAAAAAAAAAIAAAACAAQAA0AAAAAAgAJkAAAAAMAAAAAAA AACAAAAAgAEAANQAAAAAIACpAAAAADAAAAAAAAAAgAAAAIABAADQAAAAACAAqQAAAAAwAAAAAAAA AIAAAACAAQAA0AAAAAAgAKkAAAAAMAAAAAAAAACAAAAAgAEAANAAAAAAIACpAAAAADAAAAAAAAAA gAAAAIABAADQAAAAACAAqQAAAAAwAAAAAAAAAIAAAACAAQAA0AAAAAAgAJkAAAAAMAAAAAAAAACA AAAAgAEAANQAAAAAIACpAAAAADAAAAAAAAAAgAAAAIABAADQAAAAACAAqQAAAAAwAAAAAAAAAIAA AACAAQAA0AAAAAAgAKkAAAAAMAAAAAAAAACAAAAAgAEAANAAAAAAIACpAAAAADAAAAAAAAAAgAAA AIABAADQAAAAACAAqQAAAAAwAAAAAAAAAIAAAACAAQAA0AAAAAAgAJkAAAAAMAAAAAAAAACAAAAA gAEAANQAAAAAIACpAAAAADAAAAAAAAAAgAAAAIABAADQAAAAACAAqQAAAAAwAAAAAAAAAIAAAACA AQAA0AAAAAAgAKkAAAAAMAAAAAAAAACAAAAAgAEAANAAAAAAIACpAAAAADAAAAAAAAAAgAAAAIAB AADQAAAAACAAqQAAAAAwAAAAAAAAAIAAAACAAQAA0AAAAAAgAJkAAAAAMAAAAAAAAACAAAAAgAEA ANQAAAAAIACpAAAAADAAAAAAAAAAgAAAAIABAADQAAAAACAAqQAAAAAwAAAAAAAAAIAAAACAAQAA 0AAAAAAgAKkAAAAAMAAAAAAAAACAAAAAgAEAANAAAAAAIACpAAAAADAAAAAAAAAAgAAAAIABAADQ AAAAACAAqQAAAAAwAAAAAAAAAIAAAACAAQAA0AAAAAAgAJkAAAAAMAAAAAAAAACAAAAAgAEAANQA AAAAIACpAAAAADAAAAAAAAAAgAAAAIABAADQAAAAACAAqQAAAAAwAAAAAAAAAIAAAACAAQAA0AAA AAAgAKkAAAAAMAAAAAAAAACAAAAAgAEAANAAAAAAIACpAAAAADAAAAAAAAAAgAAAAIABAADQAAAA ACAAqQAAAAAwAAAAAAAAAIAAAACAAQAA0AAAAAAgAJkAAAAAMAAAAAAAAACAAAAAgAEAANQAAAAA IACpAAAAADAAAAAAAAAAgAAAAIABAADQAAAAACAAqQAAAAAwAAAAAAAAAIAAAACAAQAA0AAAAAAg AKkAAAAAMAAAAAAAAACAAAAAgAEAANAAAAAAIACpAAAAADAAAAAAAAAAgAAAAIABAADQAAAAACAA qQAAAAAwAAAAAAAAAIAAAACAAQAA0AAAAAAgAJkAAAAAMAAAAAAAAACAAAAAgAEAANQAAAAAIACp AAAAADAAAAAAAAAAgAAAAIABAADQAAAAACAAqQAAAAAwAAAAAAAAAIAAAACAAQAA0AAAAAAgAKkA AAAAMAAAAAAAAACAAAAAgAEAANAAAAAAIACpAAAAADAAAAAAAAAAgAAAAIABAADQAAAAACAAqQAA AAAwAAAAAAAAAIAAAACAAQAA0AAAAAAgAJkAAAAAMAAAAAAAAACAAAAAgAEAANQAAAAAIACpAAAA ADAAAAAAAAAAgAAAAIABAADQAAAAACAAqQAAAAAwAAAAAAAAAIAAAACAAQAA0AAAAAAgAKkAAAAA MAAAAAAAAACAAAAAgAEAANAAAAAAIACpAAAAADAAAAAAAAAAgAAAAIABAADQAAAAACAAqQAAAAAw AAAAAAAAAIAAAACAAQAA0AAAAAAgAJkAAAAAMAAAAAAAAACAAAAAgAEAANQAAAAAIACpAAAAADAA AAAAAAAAgAAAAIABAADQAAAAACAAqQAAAAAwAAAAAAAAAIAAAACAAQAA0AAAAAAgAKkAAAAAMAAA AAAAAACAAAAAgAEAANAAAAAAIACpAAAAADAAAAAAAAAAgAAAAIABAADQAAAAACAAqQAAAAAwAAAA AAAAAIAAAACAAQAA0AAAAAAgAJkAAAAAMAAAAAAAAACAAAAAgAEAANQAAAAAIACpAAAAADAAAAAA AAAAgAAAAIABAADQAAAAACAAqQAAAAAwAAAAAAAAAIAAAACAAQAA0AAAAAAgAKkAAAAAMAAAAAAA AACAAAAAgAEAANAAAAAAIACpAAAAADAAAAAAAAAAgAAAAIABAADQAAAAACAAqQAAAAAwAAAAAAAA AIAAAACAAQAA0AAAAAAgAJkAAAAAMAAAAAAAAACAAAAAgAEAANQAAAAAIACpAAAAADAAAAAAAAAA gAAAAIABAADQAAAAACAAqQAAAAAwAAAAAAAAAIAAAACAAQAA0AAAAAAgAKkAAAAAMAAAAAAAAACA AAAAgAEAANAAAAAAIACpAAAAADAAAAAAAAAAgAAAAIABAADQAAAAACAAqQAAAAAwAAAAAAAAAIAA AACAAQAA0AAAAAAgAJkAAAAAMAAAAAAAAACAAAAAgAEAANQAAAAAIACpAAAAADAAAAAAAAAAgAAA AIABAADQAAAAACAAqQAAAAAwAAAAAAAAAIAAAACAAQAA0AAAAAAgAKkAAAAAMAAAAAAAAACAAAAA gAEAANAAAAAAIACpAAAAADAAAAAAAAAAgAAAAIABAADQAAAAACAAqQAAAAAwAAAAAAAAAIAAAACA AQAA0AAAAAAgAJkAAAAAMAAAAAAAAACAAAAAgAEAANQAAAAAIACpAAAAADAAAAAAAAAAgAAAAIAB AADQAAAAACAAqQAAAAAwAAAAAAAAAIAAAACAAQAA0AAAAAAgAKkAAAAAMAAAAAAAAACAAAAAgAEA ANAAAAAAIACpAAAAADAAAAAAAAAAgAAAAIABAADQAAAAACAAqQAAAAAwAAAAAAAAAIAAAACAAQAA 0AAAAAAgAJkAAAAAMAAAAAAAAACAAAAAgAEAANQAAAAAIACpAAAAADAAAAAAAAAAgAAAAIABAADQ AAAAACAAqQAAAAAwAAAAAAAAAIAAAACAAQAA0AAAAAAgAKkAAAAAMAAAAAAAAACAAAAAgAEAANAA AAAAIACpAAAAADAAAAAAAAAAgAAAAIABAADQAAAAACAAqQAAAAAwAAAAAAAAAIAAAACAAQAA0AAA AAAgAJkAAAAAMAAAAAAAAACAAAAAgAEAANQAAAAAIACpAAAAADAAAAAAAAAAgAAAAIABAADQAAAA ACAAqQAAAAAwAAAAAAAAAIAAAACAAQAA0AAAAAAgAKkAAAAAMAAAAAAAAACAAAAAgAEAANAAAAAA IACpAAAAADAAAAAAAAAAgAAAAIABAADQAAAAACAAqQAAAAAwAAAAAAAAAIAAAACAAQAA0AAAAAAg AJkAAAAAMAAAAAAAAACAAAAAgAEAANQAAAAAIACYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAAA mAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAKkAAAAAMAAAAAAAAACAAAAAgAEAANAAAAAAIACp AAAAADAAAAAAAAAAgAAAAIABAADQAAAAACAAqQAAAAAwAAAAAAAAAIAAAACAAQAA0AAAAAAgAKkA AAAAMAAAAAAAAACAAAAAgAEAANAAAAAAIACpAAAAADAAAAAAAAAAgAAAAIABAADQAAAAACAAmQAA AAAwAAAAAAAAAIAAAACAAQAA1AAAAAAgAKkAAAAAMAAAAAAAAACAAAAAgAEAANAAAAAAIACpAAAA ADAAAAAAAAAAgAAAAIABAADQAAAAACAAqQAAAAAwAAAAAAAAAIAAAACAAQAA0AAAAAAgAKkAAAAA MAAAAAAAAACAAAAAgAEAANAAAAAAIACpAAAAADAAAAAAAAAAgAAAAIABAADQAAAAACAAmQAAAAAw AAAAAAAAAIAAAACAAQAA1AAAAAAgAKkAAAAAMAAAAAAAAACAAAAAgAEAANAAAAAAIACpAAAAADAA AAAAAAAAgAAAAIABAADQAAAAACAAqQAAAAAwAAAAAAAAAIAAAACAAQAA0AAAAAAgAKkAAAAAMAAA AAAAAACAAAAAgAEAANAAAAAAIACpAAAAADAAAAAAAAAAgAAAAIABAADQAAAAACAAmQAAAAAwAAAA AAAAAIAAAACAAQAA1AAAAAAgAKkAAAAAMAAAAAAAAACAAAAAgAEAANAAAAAAIACpAAAAADAAAAAA AAAAgAAAAIABAADQAAAAACAAqQAAAAAwAAAAAAAAAIAAAACAAQAA0AAAAAAgAKkAAAAAMAAAAAAA AACAAAAAgAEAANAAAAAAIACpAAAAADAAAAAAAAAAgAAAAIABAADQAAAAACAAmQAAAAAwAAAAAAAA AIAAAACAAQAA1AAAAAAgAKkAAAAAMAAAAAAAAACAAAAAgAEAANAAAAAAIACpAAAAADAAAAAAAAAA gAAAAIABAADQAAAAACAAqQAAAAAwAAAAAAAAAIAAAACAAQAA0AAAAAAgAKkAAAAAMAAAAAAAAACA AAAAgAEAANAAAAAAIACpAAAAADAAAAAAAAAAgAAAAIABAADQAAAAACAAmQAAAAAwAAAAAAAAAIAA AACAAQAA1AAAAAAgAKkAAAAAMAAAAAAAAACAAAAAgAEAANAAAAAAIACpAAAAADAAAAAAAAAAgAAA AIABAADQAAAAACAAqQAAAAAwAAAAAAAAAIAAAACAAQAA0AAAAAAgAKkAAAAAMAAAAAAAAACAAAAA gAEAANAAAAAAIACpAAAAADAAAAAAAAAAgAAAAIABAADQAAAAACAAmQAAAAAwAAAAAAAAAIAAAACA AQAA1AAAAAAgAKkAAAAAMAAAAAAAAACAAAAAgAEAANAAAAAAIACpAAAAADAAAAAAAAAAgAAAAIAB AADQAAAAACAAqQAAAAAwAAAAAAAAAIAAAACAAQAA0AAAAAAgAKkAAAAAMAAAAAAAAACAAAAAgAEA ANAAAAAAIACpAAAAADAAAAAAAAAAgAAAAIABAADQAAAAACAAmQAAAAAwAAAAAAAAAIAAAACAAQAA 1AAAAAAgAKkAAAAAMAAAAAAAAACAAAAAgAEAANAAAAAAIACpAAAAADAAAAAAAAAAgAAAAIABAADQ AAAAACAAqQAAAAAwAAAAAAAAAIAAAACAAQAA0AAAAAAgAKkAAAAAMAAAAAAAAACAAAAAgAEAANAA AAAAIACpAAAAADAAAAAAAAAAgAAAAIABAADQAAAAACAAmQAAAAAwAAAAAAAAAIAAAACAAQAA1AAA AAAgAKkAAAAAMAAAAAAAAACAAAAAgAEAANAAAAAAIACpAAAAADAAAAAAAAAAgAAAAIABAADQAAAA ACAAqQAAAAAwAAAAAAAAAIAAAACAAQAA0AAAAAAgAKkAAAAAMAAAAAAAAACAAAAAgAEAANAAAAAA IACpAAAAADAAAAAAAAAAgAAAAIABAADQAAAAACAAmQAAAAAwAAAAAAAAAIAAAACAAQAA1AAAAAAg AKkAAAAAMAAAAAAAAACAAAAAgAEAANAAAAAAIACpAAAAADAAAAAAAAAAgAAAAIABAADQAAAAACAA qQAAAAAwAAAAAAAAAIAAAACAAQAA0AAAAAAgAKkAAAAAMAAAAAAAAACAAAAAgAEAANAAAAAAIACp AAAAADAAAAAAAAAAgAAAAIABAADQAAAAACAAmQAAAAAwAAAAAAAAAIAAAACAAQAA1AAAAAAgAKkA AAAAMAAAAAAAAACAAAAAgAEAANAAAAAAIACpAAAAADAAAAAAAAAAgAAAAIABAADQAAAAACAAqQAA AAAwAAAAAAAAAIAAAACAAQAA0AAAAAAgAKkAAAAAMAAAAAAAAACAAAAAgAEAANAAAAAAIACpAAAA ADAAAAAAAAAAgAAAAIABAADQAAAAACAAmQAAAAAwAAAAAAAAAIAAAACAAQAA1AAAAAAgAKkAAAAA MAAAAAAAAACAAAAAgAEAANAAAAAAIACpAAAAADAAAAAAAAAAgAAAAIABAADQAAAAACAAqQAAAAAw AAAAAAAAAIAAAACAAQAA0AAAAAAgAKkAAAAAMAAAAAAAAACAAAAAgAEAANAAAAAAIACpAAAAADAA AAAAAAAAgAAAAIABAADQAAAAACAAmQAAAAAwAAAAAAAAAIAAAACAAQAA1AAAAAAgAKkAAAAAMAAA AAAAAACAAAAAgAEAANAAAAAAIACpAAAAADAAAAAAAAAAgAAAAIABAADQAAAAACAAqQAAAAAwAAAA AAAAAIAAAACAAQAA0AAAAAAgAKkAAAAAMAAAAAAAAACAAAAAgAEAANAAAAAAIACpAAAAADAAAAAA AAAAgAAAAIABAADQAAAAACAAmQAAAAAwAAAAAAAAAIAAAACAAQAA1AAAAAAgAKkAAAAAMAAAAAAA AACAAAAAgAEAANAAAAAAIACpAAAAADAAAAAAAAAAgAAAAIABAADQAAAAACAAqQAAAAAwAAAAAAAA AIAAAACAAQAA0AAAAAAgAKkAAAAAMAAAAAAAAACAAAAAgAEAANAAAAAAIACpAAAAADAAAAAAAAAA gAAAAIABAADQAAAAACAAmQAAAAAwAAAAAAAAAIAAAACAAQAA1AAAAAAgAKkAAAAAMAAAAAAAAACA AAAAgAEAANAAAAAAIACpAAAAADAAAAAAAAAAgAAAAIABAADQAAAAACAAqQAAAAAwAAAAAAAAAIAA AACAAQAA0AAAAAAgAKkAAAAAMAAAAAAAAACAAAAAgAEAANAAAAAAIACpAAAAADAAAAAAAAAAgAAA AIABAADQAAAAACAAmQAAAAAwAAAAAAAAAIAAAACAAQAA1AAAAAAgAKkAAAAAMAAAAAAAAACAAAAA gAEAANAAAAAAIACpAAAAADAAAAAAAAAAgAAAAIABAADQAAAAACAAqQAAAAAwAAAAAAAAAIAAAACA AQAA0AAAAAAgAKkAAAAAMAAAAAAAAACAAAAAgAEAANAAAAAAIACpAAAAADAAAAAAAAAAgAAAAIAB AADQAAAAACAAmQAAAAAwAAAAAAAAAIAAAACAAQAA1AAAAAAgAKkAAAAAMAAAAAAAAACAAAAAgAEA ANAAAAAAIACpAAAAADAAAAAAAAAAgAAAAIABAADQAAAAACAAqQAAAAAwAAAAAAAAAIAAAACAAQAA 0AAAAAAgAKkAAAAAMAAAAAAAAACAAAAAgAEAANAAAAAAIACpAAAAADAAAAAAAAAAgAAAAIABAADQ AAAAACAAmQAAAAAwAAAAAAAAAIAAAACAAQAA1AAAAAAgAKkAAAAAMAAAAAAAAACAAAAAgAEAANAA AAAAIACpAAAAADAAAAAAAAAAgAAAAIABAADQAAAAACAAqQAAAAAwAAAAAAAAAIAAAACAAQAA0AAA AAAgAKkAAAAAMAAAAAAAAACAAAAAgAEAANAAAAAAIACpAAAAADAAAAAAAAAAgAAAAIABAADQAAAA ACAAmQAAAAAwAAAAAAAAAIAAAACAAQAA1AAAAAAgAKkAAAAAMAAAAAAAAACAAAAAgAEAANAAAAAA IACpAAAAADAAAAAAAAAAgAAAAIABAADQAAAAACAAqQAAAAAwAAAAAAAAAIAAAACAAQAA0AAAAAAg AKkAAAAAMAAAAAAAAACAAAAAgAEAANAAAAAAIACpAAAAADAAAAAAAAAAgAAAAIABAADQAAAAACAA mQAAAAAwAAAAAAAAAIAAAACAAQAA1AAAAAAgAKkAAAAAMAAAAAAAAACAAAAAgAEAANAAAAAAIACp AAAAADAAAAAAAAAAgAAAAIABAADQAAAAACAAqQAAAAAwAAAAAAAAAIAAAACAAQAA0AAAAAAgAKkA AAAAMAAAAAAAAACAAAAAgAEAANAAAAAAIACpAAAAADAAAAAAAAAAgAAAAIABAADQAAAAACAAmQAA AAAwAAAAAAAAAIAAAACAAQAA1AAAAAAgAJgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAA ADAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAA MAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAqQAAAAAw AAAAAAAAAIAAAACAAQAA0AAAAAAgAKkAAAAAMAAAAAAAAACAAAAAgAEAANAAAAAAIACpAAAAADAA AAAAAAAAgAAAAIABAADQAAAAACAAqQAAAAAwAAAAAAAAAIAAAACAAQAA0AAAAAAgAJkAAAAAMAAA AAAAAACAAAAAgAEAANQAAAAAIACpAAAAADAAAAAAAAAAgAAAAIABAADQAAAAACAAqQAAAAAwAAAA AAAAAIAAAACAAQAA0AAAAAAgAKkAAAAAMAAAAAAAAACAAAAAgAEAANAAAAAAIACpAAAAADAAAAAA AAAAgAAAAIABAADQAAAAACAAmQAAAAAwAAAAAAAAAIAAAACAAQAA1AAAAAAgAKkAAAAAMAAAAAAA AACAAAAAgAEAANAAAAAAIACpAAAAADAAAAAAAAAAgAAAAIABAADQAAAAACAAqQAAAAAwAAAAAAAA AIAAAACAAQAA0AAAAAAgAKkAAAAAMAAAAAAAAACAAAAAgAEAANAAAAAAIACZAAAAADAAAAAAAAAA gAAAAIABAADUAAAAACAAqQAAAAAwAAAAAAAAAIAAAACAAQAA0AAAAAAgAKkAAAAAMAAAAAAAAACA AAAAgAEAANAAAAAAIACpAAAAADAAAAAAAAAAgAAAAIABAADQAAAAACAAqQAAAAAwAAAAAAAAAIAA AACAAQAA0AAAAAAgAJkAAAAAMAAAAAAAAACAAAAAgAEAANQAAAAAIACpAAAAADAAAAAAAAAAgAAA AIABAADQAAAAACAAqQAAAAAwAAAAAAAAAIAAAACAAQAA0AAAAAAgAKkAAAAAMAAAAAAAAACAAAAA gAEAANAAAAAAIACpAAAAADAAAAAAAAAAgAAAAIABAADQAAAAACAAmQAAAAAwAAAAAAAAAIAAAACA AQAA1AAAAAAgAKkAAAAAMAAAAAAAAACAAAAAgAEAANAAAAAAIACpAAAAADAAAAAAAAAAgAAAAIAB AADQAAAAACAAqQAAAAAwAAAAAAAAAIAAAACAAQAA0AAAAAAgAKkAAAAAMAAAAAAAAACAAAAAgAEA ANAAAAAAIACZAAAAADAAAAAAAAAAgAAAAIABAADUAAAAACAAqQAAAAAwAAAAAAAAAIAAAACAAQAA 0AAAAAAgAKkAAAAAMAAAAAAAAACAAAAAgAEAANAAAAAAIACpAAAAADAAAAAAAAAAgAAAAIABAADQ AAAAACAAqQAAAAAwAAAAAAAAAIAAAACAAQAA0AAAAAAgAJkAAAAAMAAAAAAAAACAAAAAgAEAANQA AAAAIACpAAAAADAAAAAAAAAAgAAAAIABAADQAAAAACAAqQAAAAAwAAAAAAAAAIAAAACAAQAA0AAA AAAgAKkAAAAAMAAAAAAAAACAAAAAgAEAANAAAAAAIACpAAAAADAAAAAAAAAAgAAAAIABAADQAAAA ACAAmQAAAAAwAAAAAAAAAIAAAACAAQAA1AAAAAAgAKkAAAAAMAAAAAAAAACAAAAAgAEAANAAAAAA IACpAAAAADAAAAAAAAAAgAAAAIABAADQAAAAACAAqQAAAAAwAAAAAAAAAIAAAACAAQAA0AAAAAAg AKkAAAAAMAAAAAAAAACAAAAAgAEAANAAAAAAIACZAAAAADAAAAAAAAAAgAAAAIABAADUAAAAACAA qQAAAAAwAAAAAAAAAIAAAACAAQAA0AAAAAAgAKkAAAAAMAAAAAAAAACAAAAAgAEAANAAAAAAIACp AAAAADAAAAAAAAAAgAAAAIABAADQAAAAACAAqQAAAAAwAAAAAAAAAIAAAACAAQAA0AAAAAAgAJkA AAAAMAAAAAAAAACAAAAAgAEAANQAAAAAIACpAAAAADAAAAAAAAAAgAAAAIABAADQAAAAACAAqQAA AAAwAAAAAAAAAIAAAACAAQAA0AAAAAAgAKkAAAAAMAAAAAAAAACAAAAAgAEAANAAAAAAIACpAAAA ADAAAAAAAAAAgAAAAIABAADQAAAAACAAmQAAAAAwAAAAAAAAAIAAAACAAQAA1AAAAAAgAKkAAAAA MAAAAAAAAACAAAAAgAEAANAAAAAAIACpAAAAADAAAAAAAAAAgAAAAIABAADQAAAAACAAqQAAAAAw AAAAAAAAAIAAAACAAQAA0AAAAAAgAKkAAAAAMAAAAAAAAACAAAAAgAEAANAAAAAAIACZAAAAADAA AAAAAAAAgAAAAIABAADUAAAAACAAqQAAAAAwAAAAAAAAAIAAAACAAQAA0AAAAAAgAKkAAAAAMAAA AAAAAACAAAAAgAEAANAAAAAAIACpAAAAADAAAAAAAAAAgAAAAIABAADQAAAAACAAqQAAAAAwAAAA AAAAAIAAAACAAQAA0AAAAAAgAJkAAAAAMAAAAAAAAACAAAAAgAEAANQAAAAAIACpAAAAADAAAAAA AAAAgAAAAIABAADQAAAAACAAqQAAAAAwAAAAAAAAAIAAAACAAQAA0AAAAAAgAKkAAAAAMAAAAAAA AACAAAAAgAEAANAAAAAAIACpAAAAADAAAAAAAAAAgAAAAIABAADQAAAAACAAmQAAAAAwAAAAAAAA AIAAAACAAQAA1AAAAAAgAKkAAAAAMAAAAAAAAACAAAAAgAEAANAAAAAAIACpAAAAADAAAAAAAAAA gAAAAIABAADQAAAAACAAqQAAAAAwAAAAAAAAAIAAAACAAQAA0AAAAAAgAKkAAAAAMAAAAAAAAACA AAAAgAEAANAAAAAAIACZAAAAADAAAAAAAAAAgAAAAIABAADUAAAAACAAqQAAAAAwAAAAAAAAAIAA AACAAQAA0AAAAAAgAKkAAAAAMAAAAAAAAACAAAAAgAEAANAAAAAAIACpAAAAADAAAAAAAAAAgAAA AIABAADQAAAAACAAqQAAAAAwAAAAAAAAAIAAAACAAQAA0AAAAAAgAJkAAAAAMAAAAAAAAACAAAAA gAEAANQAAAAAIACpAAAAADAAAAAAAAAAgAAAAIABAADQAAAAACAAqQAAAAAwAAAAAAAAAIAAAACA AQAA0AAAAAAgAKkAAAAAMAAAAAAAAACAAAAAgAEAANAAAAAAIACpAAAAADAAAAAAAAAAgAAAAIAB AADQAAAAACAAmQAAAAAwAAAAAAAAAIAAAACAAQAA1AAAAAAgAKkAAAAAMAAAAAAAAACAAAAAgAEA ANAAAAAAIACpAAAAADAAAAAAAAAAgAAAAIABAADQAAAAACAAqQAAAAAwAAAAAAAAAIAAAACAAQAA 0AAAAAAgAKkAAAAAMAAAAAAAAACAAAAAgAEAANAAAAAAIACZAAAAADAAAAAAAAAAgAAAAIABAADU AAAAACAAqQAAAAAwAAAAAAAAAIAAAACAAQAA0AAAAAAgAKkAAAAAMAAAAAAAAACAAAAAgAEAANAA AAAAIACpAAAAADAAAAAAAAAAgAAAAIABAADQAAAAACAAqQAAAAAwAAAAAAAAAIAAAACAAQAA0AAA AAAgAJkAAAAAMAAAAAAAAACAAAAAgAEAANQAAAAAIACpAAAAADAAAAAAAAAAgAAAAIABAADQAAAA ACAAqQAAAAAwAAAAAAAAAIAAAACAAQAA0AAAAAAgAKkAAAAAMAAAAAAAAACAAAAAgAEAANAAAAAA IACpAAAAADAAAAAAAAAAgAAAAIABAADQAAAAACAAmQAAAAAwAAAAAAAAAIAAAACAAQAA1AAAAAAg AJgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAAA mAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAKkAAAAAMAAAAAAAAACAAAAAgAEAANAAAAAAIACp AAAAADAAAAAAAAAAgAAAAIABAADQAAAAACAAqQAAAAAwAAAAAAAAAIAAAACAAQAA0AAAAAAgAJkA AAAAMAAAAAAAAACAAAAAgAEAANQAAAAAIACpAAAAADAAAAAAAAAAgAAAAIABAADQAAAAACAAqQAA AAAwAAAAAAAAAIAAAACAAQAA0AAAAAAgAKkAAAAAMAAAAAAAAACAAAAAgAEAANAAAAAAIACZAAAA ADAAAAAAAAAAgAAAAIABAADUAAAAACAAqQAAAAAwAAAAAAAAAIAAAACAAQAA0AAAAAAgAKkAAAAA MAAAAAAAAACAAAAAgAEAANAAAAAAIACpAAAAADAAAAAAAAAAgAAAAIABAADQAAAAACAAmQAAAAAw AAAAAAAAAIAAAACAAQAA1AAAAAAgAKkAAAAAMAAAAAAAAACAAAAAgAEAANAAAAAAIACpAAAAADAA AAAAAAAAgAAAAIABAADQAAAAACAAqQAAAAAwAAAAAAAAAIAAAACAAQAA0AAAAAAgAJkAAAAAMAAA AAAAAACAAAAAgAEAANQAAAAAIACpAAAAADAAAAAAAAAAgAAAAIABAADQAAAAACAAqQAAAAAwAAAA AAAAAIAAAACAAQAA0AAAAAAgAKkAAAAAMAAAAAAAAACAAAAAgAEAANAAAAAAIACZAAAAADAAAAAA AAAAgAAAAIABAADUAAAAACAAqQAAAAAwAAAAAAAAAIAAAACAAQAA0AAAAAAgAKkAAAAAMAAAAAAA AACAAAAAgAEAANAAAAAAIACpAAAAADAAAAAAAAAAgAAAAIABAADQAAAAACAAmQAAAAAwAAAAAAAA AIAAAACAAQAA1AAAAAAgAKkAAAAAMAAAAAAAAACAAAAAgAEAANAAAAAAIACpAAAAADAAAAAAAAAA gAAAAIABAADQAAAAACAAqQAAAAAwAAAAAAAAAIAAAACAAQAA0AAAAAAgAJkAAAAAMAAAAAAAAACA AAAAgAEAANQAAAAAIACpAAAAADAAAAAAAAAAgAAAAIABAADQAAAAACAAqQAAAAAwAAAAAAAAAIAA AACAAQAA0AAAAAAgAKkAAAAAMAAAAAAAAACAAAAAgAEAANAAAAAAIACZAAAAADAAAAAAAAAAgAAA AIABAADUAAAAACAAqQAAAAAwAAAAAAAAAIAAAACAAQAA0AAAAAAgAKkAAAAAMAAAAAAAAACAAAAA gAEAANAAAAAAIACpAAAAADAAAAAAAAAAgAAAAIABAADQAAAAACAAmQAAAAAwAAAAAAAAAIAAAACA AQAA1AAAAAAgAKkAAAAAMAAAAAAAAACAAAAAgAEAANAAAAAAIACpAAAAADAAAAAAAAAAgAAAAIAB AADQAAAAACAAqQAAAAAwAAAAAAAAAIAAAACAAQAA0AAAAAAgAJkAAAAAMAAAAAAAAACAAAAAgAEA ANQAAAAAIACpAAAAADAAAAAAAAAAgAAAAIABAADQAAAAACAAqQAAAAAwAAAAAAAAAIAAAACAAQAA 0AAAAAAgAKkAAAAAMAAAAAAAAACAAAAAgAEAANAAAAAAIACZAAAAADAAAAAAAAAAgAAAAIABAADU AAAAACAAqQAAAAAwAAAAAAAAAIAAAACAAQAA0AAAAAAgAKkAAAAAMAAAAAAAAACAAAAAgAEAANAA AAAAIACpAAAAADAAAAAAAAAAgAAAAIABAADQAAAAACAAmQAAAAAwAAAAAAAAAIAAAACAAQAA1AAA AAAgAKkAAAAAMAAAAAAAAACAAAAAgAEAANAAAAAAIACpAAAAADAAAAAAAAAAgAAAAIABAADQAAAA ACAAqQAAAAAwAAAAAAAAAIAAAACAAQAA0AAAAAAgAJkAAAAAMAAAAAAAAACAAAAAgAEAANQAAAAA IACpAAAAADAAAAAAAAAAgAAAAIABAADQAAAAACAAqQAAAAAwAAAAAAAAAIAAAACAAQAA0AAAAAAg AKkAAAAAMAAAAAAAAACAAAAAgAEAANAAAAAAIACZAAAAADAAAAAAAAAAgAAAAIABAADUAAAAACAA qQAAAAAwAAAAAAAAAIAAAACAAQAA0AAAAAAgAKkAAAAAMAAAAAAAAACAAAAAgAEAANAAAAAAIACp AAAAADAAAAAAAAAAgAAAAIABAADQAAAAACAAmQAAAAAwAAAAAAAAAIAAAACAAQAA1AAAAAAgAKkA AAAAMAAAAAAAAACAAAAAgAEAANAAAAAAIACpAAAAADAAAAAAAAAAgAAAAIABAADQAAAAACAAqQAA AAAwAAAAAAAAAIAAAACAAQAA0AAAAAAgAJkAAAAAMAAAAAAAAACAAAAAgAEAANQAAAAAIACpAAAA ADAAAAAAAAAAgAAAAIABAADQAAAAACAAqQAAAAAwAAAAAAAAAIAAAACAAQAA0AAAAAAgAKkAAAAA MAAAAAAAAACAAAAAgAEAANAAAAAAIACZAAAAADAAAAAAAAAAgAAAAIABAADUAAAAACAAqQAAAAAw AAAAAAAAAIAAAACAAQAA0AAAAAAgAKkAAAAAMAAAAAAAAACAAAAAgAEAANAAAAAAIACpAAAAADAA AAAAAAAAgAAAAIABAADQAAAAACAAmQAAAAAwAAAAAAAAAIAAAACAAQAA1AAAAAAgAKkAAAAAMAAA AAAAAACAAAAAgAEAANAAAAAAIACpAAAAADAAAAAAAAAAgAAAAIABAADQAAAAACAAqQAAAAAwAAAA AAAAAIAAAACAAQAA0AAAAAAgAJkAAAAAMAAAAAAAAACAAAAAgAEAANQAAAAAIACpAAAAADAAAAAA AAAAgAAAAIABAADQAAAAACAAqQAAAAAwAAAAAAAAAIAAAACAAQAA0AAAAAAgAKkAAAAAMAAAAAAA AACAAAAAgAEAANAAAAAAIACZAAAAADAAAAAAAAAAgAAAAIABAADUAAAAACAAqQAAAAAwAAAAAAAA AIAAAACAAQAA0AAAAAAgAKkAAAAAMAAAAAAAAACAAAAAgAEAANAAAAAAIACpAAAAADAAAAAAAAAA gAAAAIABAADQAAAAACAAmQAAAAAwAAAAAAAAAIAAAACAAQAA1AAAAAAgAJgAAAAAMAAAAAAAAACA AAAAgAAAAAAAAAAAAACYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAAAwAAAAAAAAAIAA AACAAAAAAAAAAAAAAJgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAAADAAAAAAAAAAgAAA AIAAAAAAAAAAAAAAqQAAAAAwAAAAAAAAAIAAAACAAQAA0AAAAAAgAKkAAAAAMAAAAAAAAACAAAAA gAEAANAAAAAAIACZAAAAADAAAAAAAAAAgAAAAIABAADUAAAAACAAqQAAAAAwAAAAAAAAAIAAAACA AQAAqAAAAAAgAKkAAAAAMAAAAAAAAACAAAAAgAEAAKgAAAAAIACZAAAAADAAAAAAAAAAgAAAAIAB AACsAAAAACAAqQAAAAAwAAAAAAAAAIAAAACAAQAA0AAAAAAgAKkAAAAAMAAAAAAAAACAAAAAgAEA ANAAAAAAIAGZAAAAADAAAAAAAAAAgAAAAIABAADUAAAAACAAqQAAAAAwAAAAAAAAAIAAAACAAQAA 0AAAAAAgAKkAAAAAMAAAAAAAAACAAAAAgAEAANAAAAAAIAGZAAAAADAAAAAAAAAAgAAAAIABAADU AAAAACAAmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAAAAAAASAAAAGgAAAE8AAABQAAAAWgAA AIMAAACEAAAAngAAANIAAADTAAAAFQEAACYBAAA1AQAAQwEAAEQBAABlAQAAawEAAGwBAABuAQAA CgIAAAsCAAAtAwAAMwMAAD4DAAA/AwAAQwMAAEgDAABNAwAATgMAAFIDAABXAwAAXAMAAF0DAABh AwAAZgMAAGoDAABrAwAAbwMAAHQDAAB4AwAAeQMAAH0DAACBAwAAhQMAAIYDAACKAwAAjgMAAJID AACTAwAAlwMAAJsDAACfAwAAoAMAAKQDAACoAwAArAMAAK0DAACxAwAAtQMAALkDAAC6AwAAvgMA AMIDAADGAwAAxwMAAMgDAADJAwAAeAUAAIAFAACEBQAAigUAAJUFAACWBQAAmwUAAJ8FAADCBQAA xgUAAMoFAADLBQAA0AUAANQFAADqBQAA7gUAAPIFAADzBQAA+AUAAPwFAAAZBgAAHQYAACEGAAAi BgAAJwYAACsGAABABgAARAYAAEgGAABJBgAATgYAAFIGAABsBgAAcAYAAHQGAAB1BgAAegYAAH4G AACrBgAArwYAALMGAAC0BgAAuQYAAL0GAADeBgAA4gYAAOYGAADnBgAA7QYAAPEGAAAkBwAAKAcA ACwHAAAtBwAAMgcAADYHAABWBwAAWgcAAF4HAABfBwAAZQcAAGkHAACFBwAAiQcAAI0HAACOBwAA kwcAAJcHAACtBwAAsQcAALUHAAC2BwAAvAcAAMAHAADvBwAA8wcAAPcHAAD4BwAA/QcAAAEIAAAT CAAAFwgAABsIAAAcCAAAIQgAACUIAABTCAAAVwgAAFsIAABcCAAAYQgAAGUIAACECAAAiAgAAIwI AACNCAAAkwgAAJcIAAC0CAAAuAgAALwIAAC9CAAAwggAAMYIAADmCAAA6ggAAO4IAADvCAAA9AgA APgIAAAOCQAAEgkAABYJAAAXCQAAGwkAAB8JAABPCQAAUwkAAFcJAABYCQAAXQkAAGEJAAB6CQAA fgkAAIIJAACDCQAAowkAAKsJAACvCQAAtQkAAMAJAADGCQAAygkAAOsJAADvCQAA8wkAAPQJAAD6 CQAA/gkAAC0KAAAxCgAANQoAADYKAAA8CgAAQAoAAGMKAABmCgAAagoAAGsKAABwCgAAdAoAAJsK AACeCgAAogoAAKMKAACpCgAArQoAANwKAADfCgAA4woAAOQKAADqCgAA7goAABoLAAAdCwAAIQsA ACILAAAoCwAALAsAAFsLAABeCwAAYgsAAGMLAABnCwAAawsAAH0LAACACwAAhAsAAIULAACLCwAA jwsAALMLAAC2CwAAugsAALsLAADBCwAAxQsAAPsLAAD+CwAAAgwAAAMMAAAJDAAADQwAADwMAAA/ DAAAQwwAAEQMAABJDAAATQwAAHUMAAB4DAAAfAwAAH0MAACDDAAAhwwAAKsMAACuDAAAsgwAALMM AAC4DAAAvAwAAPIMAAD1DAAA+QwAAPoMAAAADQAABA0AACgNAAArDQAALw0AADANAAA2DQAAOg0A AGkNAABsDQAAcA0AAHENAAB3DQAAew0AALENAAC0DQAAuA0AALkNAAC/DQAAww0AAOcNAADqDQAA 7g0AAO8NAAD1DQAA+Q0AACIOAAAlDgAAKQ4AACoOAAArDgAALA4AAOsPAAATEAAAGBAAAB0QAAAn EAAAKBAAACwQAABJEAAATRAAAFMQAABUEAAAWBAAAG4QAAByEAAAeRAAAHoQAAB+EAAAmxAAAJ8Q AAClEAAAphAAAKoQAAC3EAAAuxAAAMIQAADDEAAAxxAAAOEQAADlEAAA7BAAAO0QAADxEAAACREA AA0RAAAUEQAAFREAABkRAAA9EQAAQREAAEcRAABIEQAATBEAAHkRAAB9EQAAhBEAAIURAACJEQAA oREAAKURAACrEQAArBEAALARAADZEQAA3REAAOQRAADlEQAA6REAAAASAAAEEgAACxIAAAwSAAAQ EgAAIBIAACQSAAArEgAALBIAADASAAA+EgAAQhIAAEkSAABKEgAAThIAAG4SAAByEgAAeRIAAHoS AAB+EgAAkBIAAJQSAACbEgAAnBIAAKASAADFEgAAyRIAANASAADREgAA1RIAAOsSAADvEgAA9hIA APcSAAD7EgAAGhMAAB4TAAAlEwAAJhMAACoTAABWEwAAWhMAAGETAABiEwAAhRMAAIsTAACWEwAA lxMAAK8TAACzEwAAuhMAALsTAADfEwAA4xMAAOkTAADqEwAAAhQAAAYUAAAMFAAADRQAAC0UAAAx FAAAOBQAADkUAABlFAAAaRQAAHAUAABxFAAAihQAAI4UAACVFAAAlhQAAK4UAACyFAAAuRQAALoU AADOFAAA0RQAANgUAADZFAAA4BQAAOMUAADqFAAA6xQAAAYVAAAJFQAAEBUAABEVAAAsFQAALxUA ADYVAAA3FQAATxUAAFIVAABZFQAAWhUAAG4VAABxFQAAeBUAAHkVAACYFQAAmxUAAKIVAACjFQAA xxUAAMoVAADQFQAA0RUAAPMVAAD2FQAA/BUAAP0VAAAjFgAAJhYAAC0WAAAuFgAAWBYAAFsWAABi FgAAYxYAAIsWAACOFgAAlRYAAJYWAACnFgAAqhYAALEWAACyFgAAsxYAALQWAADdFgAA/BYAAP0W AAAhFwAAMhcAADMXAABWFwAAZxcAAGgXAACLFwAAnBcAAJ0XAACgFwAAWpEAMAAwAAAAAAAAAQAA AAUAAAABAAAAKIgPB1qRADAFMAAAAAAAAAIAAAACAAEAAAAAAAAAIAdakQAwBTAAAAAAAAACAAAA AgABAAAAAAAAACAHWpEAMAAwAAAAAAAAAQAAAAAAAQAABAAAAACgB1qRADAIMAAAAAAAAAIAAAAC AAEAAAAAAAAAIAdakQAwCDAAAAAAAAACAAAAAgABAAAAAAAAACAHWpEAMAAwAAAAAAAAAQAAAAAA AQAABAAAAACgB1qRADALMAAAAAAAAAIAAAACAAEAAAAAAAAAIAdakQAwCzAAAAAAAAACAAAAAgAB AAAAAAAAACAHWpEAMAAwAAAAAAAAAQAAAAAAAQAABAAAAACgB1qRADAKMAAAAAAAAAIAAAAFAAEA AAAAAAAAIAdakQAwCjAAAAAAAAACAAAABQABAAAAAAAAAAAHWpEAMAowAAAAAAAAAgAAAAUAAQAA AAAAAAAAB1qRADAKMAAAAAAAAAIAAAAFAAEAAAAAAAAAIAdakQAwCjAAAAAAAAACAAAAAgABAAAA AAAAACAHWpEAMAowAAAAAAAAAgAAAAIAAQAAAAAAAAAgB1qRADAKMAAAAAAAAAIAAAACAAEAAAAA AAAAIAdakQAwADAAAAAAAAABAAAAAAAAAAAAAACkDqAHWpEAMBIwAAAAAAAAAQAAAAUAAAATAAAA ACwPB1qRADASMAAAAAAAAAEAAAAEAAAAAAAAAAAAAAdakQAwEjAAAAAAAAABAAAAAwAAAAAAAAAA AAAHWtEAMAAwAAAAAAAAAQAAAA0AAQAAAAAAAAC2B1rRADAAMAAAAAAAAAEAAAANAAEAAAAAAAAA tgda0QAwADAAAAAAAAABAAAADQABAAAAAAAAALYHmUAAAAAwAAAAAAAAAIAAAACAAQAAXAAAAAAg AVjRADACMAAAAAAAAAEAAAAMAAEAAAAAAAAAtgNY0QAwAjAAAAAAAAABAAAADAABAAAAAAAAALYD WtEAMAIwAAAAAAAAAQAAAAwAAQAAAAAAAAC2B5lAAAAAMAAAAAAAAACAAAAAgAEAAFwAAAAAIAFY 0QAwBDAAAAAAAAABAAAACwABAAAAAAAAALYDWNEAMAQwAAAAAAAAAQAAAAsAAQAAAAAAAAC2A1rR ADAEMAAAAAAAAAEAAAALAAEAAAAAAAAAtgeZQAAAADAAAAAAAAAAgAAAAIABAABcAAAAACABWNEA MAYwAAAAAAAAAQAAAAoAAQAAAAAAAAC2A1jRADAGMAAAAAAAAAEAAAAKAAEAAAAAAAAAtgNa0QAw BjAAAAAAAAABAAAACgABAAAAAAAAALYHmUAAAAAwAAAAAAAAAIAAAACAAQAAXAAAAAAgAVjRADAI MAAAAAAAAAEAAAAJAAEAAAAAAAAAtgNY0QAwCDAAAAAAAAABAAAACQABAAAAAAAAALYDWtEAMAgw AAAAAAAAAQAAAAkAAQAAAAAAAAC2B5lAAAAAMAAAAAAAAACAAAAAgAEAAFwAAAAAIAFY0QAwCjAA AAAAAAABAAAACAABAAAAAAAAALYDWNEAMAowAAAAAAAAAQAAAAgAAQAAAAAAAAC2A1rRADAKMAAA AAAAAAEAAAAIAAEAAAAAAAAAtgeZQAAAADAAAAAAAAAAgAAAAIABAABcAAAAACABWNEAMAwwAAAA AAAAAQAAAAcAAQAAAAAAAAC2A1jRADAMMAAAAAAAAAEAAAAHAAEAAAAAAAAAtgNa0QAwDDAAAAAA AAABAAAABwABAAAAAAAAALYHmUAAAAAwAAAAAAAAAIAAAACAAQAAXAAAAAAgAVjRADAOMAAAAAAA AAEAAAAGAAEAAAAAAAAAtgNY0QAwDjAAAAAAAAABAAAABgABAAAAAAAAALYDWtEAMA4wAAAAAAAA AQAAAAYAAQAAAAAAAAC2B5lAAAAAMAAAAAAAAACAAAAAgAEAAFwAAAAAIAFY0QAwEDAAAAAAAAAB AAAABQABAAAAAAAAALYDWNEAMBAwAAAAAAAAAQAAAAUAAQAAAAAAAAC2A1rRADAQMAAAAAAAAAEA AAAFAAEAAAAAAAAAtgeZQAAAADAAAAAAAAAAgAAAAIABAABcAAAAACABWNEAMBIwAAAAAAAAAQAA AAQAAQAAAAAAAAC2A1jRADASMAAAAAAAAAEAAAAEAAEAAAAAAAAAtgNY0QAwEjAAAAAAAAABAAAA BAABAAAAAAAAALYDmUAAAAAwAAAAAAAAAIAAAACAAQAAXAAAAAAgAVjRADAUMAAAAAAAAAEAAAAD AAEAAAAAAAAAoAFY0QAwFDAAAAAAAAABAAAAAwABAAAAAAAAAKABWtEAMBQwAAAAAAAAAQAAAAMA AQAAAAAAAACgB5lAAAAAMAAAAAAAAACAAAAAgAEAAFwAAAAAIAFakQAwADAAAAAAAAABAAAAAAAA AAAAAAAAAIAHWpEAMAAwAAAAAAAAAQAAAAAAAAAAAAAAAACAB1rRADAAMAAAAAAAAAEAAAAXAAEA AAAAAAAAAQdY0QAwADAAAAAAAAABAAAAFwABAAAAAAAAAAEDWNEAMAAwAAAAAAAAAQAAABcAAQAA AAAAAAABA1rRADAAMAAAAAAAAAEAAAAXAAEAAAAAAAAAAQda0QAwADAAAAAAAAABAAAAFwABAAAA AAAAAAEHmUAAAAAwAAAAAAAAAIAAAACAAQAABAAAAAAgAVjRADACMAAAAAAAAAEAAAAWAAEAAAAA AAAAAQNY0QAwAjAAAAAAAAABAAAAFgABAAAAAAAAAAEDWNEAMAIwAAAAAAAAAQAAABYAAQAAAAAA AAABA1jRADACMAAAAAAAAAEAAAAWAAEAAAAAAAAAAQNY0QAwAjAAAAAAAAABAAAAFgABAAAAAAAA AAEDmUAAAAAwAAAAAAAAAIAAAACAAQAABAAAAAAgAVjRADAEMAAAAAAAAAEAAAAVAAEAAAAAAAAA AQNY0QAwBDAAAAAAAAABAAAAFQABAAAAAAAAAAEDWNEAMAQwAAAAAAAAAQAAABUAAQAAAAAAAAAB A1jRADAEMAAAAAAAAAEAAAAVAAEAAAAAAAAAAQNY0QAwBDAAAAAAAAABAAAAFQABAAAAAAAAAAED mUAAAAAwAAAAAAAAAIAAAACAAQAABAAAAAAgAVjRADAGMAAAAAAAAAEAAAAUAAEAAAAAAAAAAQNY 0QAwBjAAAAAAAAABAAAAFAABAAAAAAAAAAEDWNEAMAYwAAAAAAAAAQAAABQAAQAAAAAAAAABA1jR ADAGMAAAAAAAAAEAAAAUAAEAAAAAAAAAAQNY0QAwBjAAAAAAAAABAAAAFAABAAAAAAAAAAEDmUAA AAAwAAAAAAAAAIAAAACAAQAABAAAAAAgAVjRADAIMAAAAAAAAAEAAAATAAEAAAAAAAAAAQNY0QAw CDAAAAAAAAABAAAAEwABAAAAAAAAAAEDWNEAMAgwAAAAAAAAAQAAABMAAQAAAAAAAAABA1jRADAI MAAAAAAAAAEAAAATAAEAAAAAAAAAAQNY0QAwCDAAAAAAAAABAAAAEwABAAAAAAAAAAEDmUAAAAAw AAAAAAAAAIAAAACAAQAABAAAAAAgAVjRADAKMAAAAAAAAAEAAAASAAEAAAAAAAAAAQNY0QAwCjAA AAAAAAABAAAAEgABAAAAAAAAAAEDWNEAMAowAAAAAAAAAQAAABIAAQAAAAAAAAABA1jRADAKMAAA AAAAAAEAAAASAAEAAAAAAAAAAQNY0QAwCjAAAAAAAAABAAAAEgABAAAAAAAAAAEDmUAAAAAwAAAA AAAAAIAAAACAAQAABAAAAAAgAVjRADAMMAAAAAAAAAEAAAARAAEAAAAAAAAAAQNY0QAwDDAAAAAA AAABAAAAEQABAAAAAAAAAAEDWNEAMAwwAAAAAAAAAQAAABEAAQAAAAAAAAABA1jRADAMMAAAAAAA AAEAAAARAAEAAAAAAAAAAQNY0QAwDDAAAAAAAAABAAAAEQABAAAAAAAAAAEDmUAAAAAwAAAAAAAA AIAAAACAAQAABAAAAAAgAVjRADAOMAAAAAAAAAEAAAAQAAEAAAAAAAAAAQNY0QAwDjAAAAAAAAAB AAAAEAABAAAAAAAAAAEDWNEAMA4wAAAAAAAAAQAAABAAAQAAAAAAAAABA1jRADAOMAAAAAAAAAEA AAAQAAEAAAAAAAAAAQNY0QAwDjAAAAAAAAABAAAAEAABAAAAAAAAAAEDmUAAAAAwAAAAAAAAAIAA AACAAQAABAAAAAAgAVjRADAQMAAAAAAAAAEAAAAPAAEAAAAAAAAAAQNY0QAwEDAAAAAAAAABAAAA DwABAAAAAAAAAAEDWNEAMBAwAAAAAAAAAQAAAA8AAQAAAAAAAAABA1jRADAQMAAAAAAAAAEAAAAP AAEAAAAAAAAAAQNY0QAwEDAAAAAAAAABAAAADwABAAAAAAAAAAEDmUAAAAAwAAAAAAAAAIAAAACA AQAABAAAAAAgAVjRADASMAAAAAAAAAEAAAAOAAEAAAAAAAAAAQNY0QAwEjAAAAAAAAABAAAADgAB AAAAAAAAAAEDWNEAMBIwAAAAAAAAAQAAAA4AAQAAAAAAAAABA1jRADASMAAAAAAAAAEAAAAOAAEA AAAAAAAAAQNY0QAwEjAAAAAAAAABAAAADgABAAAAAAAAAAEDmUAAAAAwAAAAAAAAAIAAAACAAQAA BAAAAAAgAVjRADAUMAAAAAAAAAEAAAANAAEAAAAAAAAAAQNY0QAwFDAAAAAAAAABAAAADQABAAAA AAAAAAEDWNEAMBQwAAAAAAAAAQAAAA0AAQAAAAAAAAABA1jRADAUMAAAAAAAAAEAAAANAAEAAAAA AAAAAQNY0QAwFDAAAAAAAAABAAAADQABAAAAAAAAAAEDmUAAAAAwAAAAAAAAAIAAAACAAQAABAAA AAAgAVjRADAWMAAAAAAAAAEAAAAMAAEAAAAAAAAAAQNY0QAwFjAAAAAAAAABAAAADAABAAAAAAAA AAEDWNEAMBYwAAAAAAAAAQAAAAwAAQAAAAAAAAABA1jRADAWMAAAAAAAAAEAAAAMAAEAAAAAAAAA AQNY0QAwFjAAAAAAAAABAAAADAABAAAAAAAAAAEDmUAAAAAwAAAAAAAAAIAAAACAAQAABAAAAAAg AVjRADAYMAAAAAAAAAEAAAALAAEAAAAAAAAAAQNY0QAwGDAAAAAAAAABAAAACwABAAAAAAAAAAED WNEAMBgwAAAAAAAAAQAAAAsAAQAAAAAAAAABA1jRADAYMAAAAAAAAAEAAAALAAEAAAAAAAAAAQNY 0QAwGDAAAAAAAAABAAAACwABAAAAAAAAAAEDmUAAAAAwAAAAAAAAAIAAAACAAQAABAAAAAAgAVjR ADAaMAAAAAAAAAEAAAAKAAEAAAAAAAAAAQNY0QAwGjAAAAAAAAABAAAACgABAAAAAAAAAAEDWNEA MBowAAAAAAAAAQAAAAoAAQAAAAAAAAABA1jRADAaMAAAAAAAAAEAAAAKAAEAAAAAAAAAAQNY0QAw GjAAAAAAAAABAAAACgABAAAAAAAAAAEDmUAAAAAwAAAAAAAAAIAAAACAAQAABAAAAAAgAVjRADAc MAAAAAAAAAEAAAAJAAEAAAAAAAAAAQNY0QAwHDAAAAAAAAABAAAACQABAAAAAAAAAAEDWNEAMBww AAAAAAAAAQAAAAkAAQAAAAAAAAABA1jRADAcMAAAAAAAAAEAAAAJAAEAAAAAAAAAAQNY0QAwHDAA AAAAAAABAAAACQABAAAAAAAAAAEDmUAAAAAwAAAAAAAAAIAAAACAAQAABAAAAAAgAVjRADAeMAAA AAAAAAEAAAAIAAEAAAAAAAAAAQNY0QAwHjAAAAAAAAABAAAACAABAAAAAAAAAAEDWNEAMB4wAAAA AAAAAQAAAAgAAQAAAAAAAAABA1jRADAeMAAAAAAAAAEAAAAIAAEAAAAAAAAAAQNY0QAwHjAAAAAA AAABAAAACAABAAAAAAAAAAEDmUAAAAAwAAAAAAAAAIAAAACAAQAABAAAAAAgAVjRADAgMAAAAAAA AAEAAAAHAAEAAAAAAAAAAQNY0QAwIDAAAAAAAAABAAAABwABAAAAAAAAAAEDWNEAMCAwAAAAAAAA AQAAAAcAAQAAAAAAAAABA1jRADAgMAAAAAAAAAEAAAAHAAEAAAAAAAAAAQNY0QAwIDAAAAAAAAAB AAAABwABAAAAAAAAAAEDmUAAAAAwAAAAAAAAAIAAAACAAQAABAAAAAAgAVjRADAiMAAAAAAAAAEA AAAGAAEAAAAAAAAAAQNY0QAwIjAAAAAAAAABAAAABgABAAAAAAAAAAEDWNEAMCIwAAAAAAAAAQAA AAYAAQAAAAAAAAABA1jRADAiMAAAAAAAAAEAAAAGAAEAAAAAAAAAAQNY0QAwIjAAAAAAAAABAAAA BgABAAAAAAAAAAEDmUAAAAAwAAAAAAAAAIAAAACAAQAABAAAAAAgAVjRADAkMAAAAAAAAAEAAAAF AAEAAAAAAAAAAQNY0QAwJDAAAAAAAAABAAAABQABAAAAAAAAAAEDWNEAMCQwAAAAAAAAAQAAAAUA AQAAAAAAAAABA1jRADAkMAAAAAAAAAEAAAAFAAEAAAAAAAAAAQNY0QAwJDAAAAAAAAABAAAABQAB AAAAAAAAAAEDmUAAAAAwAAAAAAAAAIAAAACAAQAABAAAAAAgAVjRADAmMAAAAAAAAAEAAAAEAAEA AAAAAAAAAQNY0QAwJjAAAAAAAAABAAAABAABAAAAAAAAAAEDWNEAMCYwAAAAAAAAAQAAAAQAAQAA AAAAAAABA1jRADAmMAAAAAAAAAEAAAAEAAEAAAAAAAAAAQNY0QAwJjAAAAAAAAABAAAABAABAAAA AAAAAAEDmUAAAAAwAAAAAAAAAIAAAACAAQAABAAAAAAgAVjRADAoMAAAAAAAAAEAAAADAAEAAAAA AAAAAQNY0QAwKDAAAAAAAAABAAAAAwABAAAAAAAAAAEDWNEAMCgwAAAAAAAAAQAAAAMAAQAAAAAA AAAgAVjRADAoMAAAAAAAAAEAAAADAAEAAAAAAAAAIAFY0QAwKDAAAAAAAAABAAAAAwABAAAAAAAA ACABmUAAAAAwAAAAAAAAAIAAAACAAQAABAAAAAAgAVrRADAAMAAAAAAAAAEAAAAWAAEAAAAAAAAA AQNY0QAwADAAAAAAAAABAAAAFgABAAAAAAAAAAEDWNEAMAAwAAAAAAAAAQAAABYAAQAAAAAAAAAB A1rRADAAMAAAAAAAAAEAAAAWAAEAAAAAAAAAAQda0QAwADAAAAAAAAABAAAAFgABAAAAAAAAAAEH WtEAMAIwAAAAAAAAAQAAABUAAQAAAAAAAAABA1jRADACMAAAAAAAAAEAAAAVAAEAAAAAAAAAAQNY 0QAwAjAAAAAAAAABAAAAFQABAAAAAAAAAAEDWNEAMAIwAAAAAAAAAQAAABUAAQAAAAAAAAABA1jR ADACMAAAAAAAAAEAAAAVAAEAAAAAAAAAAQOZQAAAADAAAAAAAAAAgAAAAIABAAAEAAAAACABWNEA MAQwAAAAAAAAAQAAABQAAQAAAAAAAAABA1jRADAEMAAAAAAAAAEAAAAUAAEAAAAAAAAAAQNY0QAw BDAAAAAAAAABAAAAFAABAAAAAAAAAAEDWNEAMAQwAAAAAAAAAQAAABQAAQAAAAAAAAABA1jRADAE MAAAAAAAAAEAAAAUAAEAAAAAAAAAAQOZQAAAADAAAAAAAAAAgAAAAIABAAAEAAAAACABWNEAMAYw AAAAAAAAAQAAABMAAQAAAAAAAAABA1jRADAGMAAAAAAAAAEAAAATAAEAAAAAAAAAAQNY0QAwBjAA AAAAAAABAAAAEwABAAAAAAAAAAEDWNEAMAYwAAAAAAAAAQAAABMAAQAAAAAAAAABA1jRADAGMAAA AAAAAAEAAAATAAEAAAAAAAAAAQOZQAAAADAAAAAAAAAAgAAAAIABAAAEAAAAACABWNEAMAgwAAAA AAAAAQAAABIAAQAAAAAAAAABA1jRADAIMAAAAAAAAAEAAAASAAEAAAAAAAAAAQNY0QAwCDAAAAAA AAABAAAAEgABAAAAAAAAAAEDWNEAMAgwAAAAAAAAAQAAABIAAQAAAAAAAAABA1jRADAIMAAAAAAA AAEAAAASAAEAAAAAAAAAAQOZQAAAADAAAAAAAAAAgAAAAIABAAAEAAAAACABWNEAMAowAAAAAAAA AQAAABEAAQAAAAAAAAABA1jRADAKMAAAAAAAAAEAAAARAAEAAAAAAAAAAQNY0QAwCjAAAAAAAAAB AAAAEQABAAAAAAAAAAEDWNEAMAowAAAAAAAAAQAAABEAAQAAAAAAAAABA1jRADAKMAAAAAAAAAEA AAARAAEAAAAAAAAAAQOZQAAAADAAAAAAAAAAgAAAAIABAAAEAAAAACABWNEAMAwwAAAAAAAAAQAA ABAAAQAAAAAAAAABA1jRADAMMAAAAAAAAAEAAAAQAAEAAAAAAAAAAQNY0QAwDDAAAAAAAAABAAAA EAABAAAAAAAAAAEDWNEAMAwwAAAAAAAAAQAAABAAAQAAAAAAAAABA1jRADAMMAAAAAAAAAEAAAAQ AAEAAAAAAAAAAQOZQAAAADAAAAAAAAAAgAAAAIABAAAEAAAAACABWNEAMA4wAAAAAAAAAQAAAA8A AQAAAAAAAAABA1jRADAOMAAAAAAAAAEAAAAPAAEAAAAAAAAAAQNY0QAwDjAAAAAAAAABAAAADwAB AAAAAAAAAAEDWNEAMA4wAAAAAAAAAQAAAA8AAQAAAAAAAAABA1jRADAOMAAAAAAAAAEAAAAPAAEA AAAAAAAAAQOZQAAAADAAAAAAAAAAgAAAAIABAAAEAAAAACABWNEAMBAwAAAAAAAAAQAAAA4AAQAA AAAAAAABA1jRADAQMAAAAAAAAAEAAAAOAAEAAAAAAAAAAQNY0QAwEDAAAAAAAAABAAAADgABAAAA AAAAAAEDWNEAMBAwAAAAAAAAAQAAAA4AAQAAAAAAAAABA1jRADAQMAAAAAAAAAEAAAAOAAEAAAAA AAAAAQOZQAAAADAAAAAAAAAAgAAAAIABAAAEAAAAACABWNEAMBIwAAAAAAAAAQAAAA0AAQAAAAAA AAABA1jRADASMAAAAAAAAAEAAAANAAEAAAAAAAAAAQNY0QAwEjAAAAAAAAABAAAADQABAAAAAAAA AAEDWNEAMBIwAAAAAAAAAQAAAA0AAQAAAAAAAAABA1jRADASMAAAAAAAAAEAAAANAAEAAAAAAAAA AQOZQAAAADAAAAAAAAAAgAAAAIABAAAEAAAAACABWNEAMBQwAAAAAAAAAQAAAAwAAQAAAAAAAAAB A1jRADAUMAAAAAAAAAEAAAAMAAEAAAAAAAAAAQNY0QAwFDAAAAAAAAABAAAADAABAAAAAAAAAAED WNEAMBQwAAAAAAAAAQAAAAwAAQAAAAAAAAABA1jRADAUMAAAAAAAAAEAAAAMAAEAAAAAAAAAAQOZ QAAAADAAAAAAAAAAgAAAAIABAAAEAAAAACABWNEAMBYwAAAAAAAAAQAAAAsAAQAAAAAAAAABA1jR ADAWMAAAAAAAAAEAAAALAAEAAAAAAAAAAQNY0QAwFjAAAAAAAAABAAAACwABAAAAAAAAAAEDWNEA MBYwAAAAAAAAAQAAAAsAAQAAAAAAAAABA1jRADAWMAAAAAAAAAEAAAALAAEAAAAAAAAAAQOZQAAA ADAAAAAAAAAAgAAAAIABAAAEAAAAACABWNEAMBgwAAAAAAAAAQAAAAoAAQAAAAAAAAABA1jRADAY MAAAAAAAAAEAAAAKAAEAAAAAAAAAAQNY0QAwGDAAAAAAAAABAAAACgABAAAAAAAAAAEDWNEAMBgw AAAAAAAAAQAAAAoAAQAAAAAAAAABA1jRADAYMAAAAAAAAAEAAAAKAAEAAAAAAAAAAQOZQAAAADAA AAAAAAAAgAAAAIABAAAEAAAAACABWNEAMBowAAAAAAAAAQAAAAkAAQAAAAAAAAABA1jRADAaMAAA AAAAAAEAAAAJAAEAAAAAAAAAAQNY0QAwGjAAAAAAAAABAAAACQABAAAAAAAAAAEDWNEAMBowAAAA AAAAAQAAAAkAAQAAAAAAAAABA1jRADAaMAAAAAAAAAEAAAAJAAEAAAAAAAAAAQOZQAAAADAAAAAA AAAAgAAAAIABAAAEAAAAACABWNEAMBwwAAAAAAAAAQAAAAgAAQAAAAAAAAABA1jRADAcMAAAAAAA AAEAAAAIAAEAAAAAAAAAAQNY0QAwHDAAAAAAAAABAAAACAABAAAAAAAAAAEDWNEAMBwwAAAAAAAA AQAAAAgAAQAAAAAAAAABA1jRADAcMAAAAAAAAAEAAAAIAAEAAAAAAAAAAQOZQAAAADAAAAAAAAAA gAAAAIABAAAEAAAAACABWNEAMB4wAAAAAAAAAQAAAAcAAQAAAAAAAAABA1jRADAeMAAAAAAAAAEA AAAHAAEAAAAAAAAAAQNY0QAwHjAAAAAAAAABAAAABwABAAAAAAAAAAEDWNEAMB4wAAAAAAAAAQAA AAcAAQAAAAAAAAABA1jRADAeMAAAAAAAAAEAAAAHAAEAAAAAAAAAAQOZQAAAADAAAAAAAAAAgAAA AIABAAAEAAAAACABWNEAMCAwAAAAAAAAAQAAAAYAAQAAAAAAAAABA1jRADAgMAAAAAAAAAEAAAAG AAEAAAAAAAAAAQNY0QAwIDAAAAAAAAABAAAABgABAAAAAAAAAAEDWNEAMCAwAAAAAAAAAQAAAAYA AQAAAAAAAAABA1jRADAgMAAAAAAAAAEAAAAGAAEAAAAAAAAAAQOZQAAAADAAAAAAAAAAgAAAAIAB AAAEAAAAACABWNEAMCIwAAAAAAAAAQAAAAUAAQAAAAAAAAABA1jRADAiMAAAAAAAAAEAAAAFAAEA AAAAAAAAAQNY0QAwIjAAAAAAAAABAAAABQABAAAAAAAAAAEDWNEAMCIwAAAAAAAAAQAAAAUAAQAA AAAAAAABA1jRADAiMAAAAAAAAAEAAAAFAAEAAAAAAAAAAQOZQAAAADAAAAAAAAAAgAAAAIABAAAE AAAAACABWNEAMCQwAAAAAAAAAQAAAAQAAQAAAAAAAAABA1jRADAkMAAAAAAAAAEAAAAEAAEAAAAA AAAAAQNY0QAwJDAAAAAAAAABAAAABAABAAAAAAAAAAEDWNEAMCQwAAAAAAAAAQAAAAQAAQAAAAAA AAABA1jRADAkMAAAAAAAAAEAAAAEAAEAAAAAAAAAAQOZQAAAADAAAAAAAAAAgAAAAIABAAAEAAAA ACABWNEAMCYwAAAAAAAAAQAAAAMAAQAAAAAAAAABA1jRADAmMAAAAAAAAAEAAAADAAEAAAAAAAAA AQNY0QAwJjAAAAAAAAABAAAAAwABAAAAAAAAACABWNEAMCYwAAAAAAAAAQAAAAMAAQAAAAAAAAAg AVjRADAmMAAAAAAAAAEAAAADAAEAAAAAAAAAIAGZQAAAADAAAAAAAAAAgAAAAIABAAAEAAAAACAB WNEAMAAwAAAAAAAAAQAAABYAAAAAAAAAAAAAAVjRADAAMAAAAAAAAAEAAAAWAAAAAAAAAAAAAAFa 0QAwADAAAAAAAAABAAAAFgAAAAAAAAAAAAAHWNEAMAAwAAAAAAAAAQAAABYAAQAAAAAAAAABB1jR ADAAMAAAAAAAAAEAAAAWAAEAAAAAAAAAAQNa0QAwADAAAAAAAAABAAAAFgABAAAAAAAAAAEHWtEA MAAwAAAAAAAAAQAAABYAAQAAAAAAAAABB5lAAAAAMAAAAAAAAACAAAAAgAEAAAQAAAAAIAFY0QAw AjAAAAAAAAABAAAAFQABAAAAAAAAAAEDWNEAMAIwAAAAAAAAAQAAABUAAQAAAAAAAAABA1jRADAC MAAAAAAAAAEAAAAVAAEAAAAAAAAAAQNY0QAwAjAAAAAAAAABAAAAFQABAAAAAAAAAAEDmUAAAAAw AAAAAAAAAIAAAACAAQAABAAAAAAgAVjRADAEMAAAAAAAAAEAAAAUAAEAAAAAAAAAAQNY0QAwBDAA AAAAAAABAAAAFAABAAAAAAAAAAEDWNEAMAQwAAAAAAAAAQAAABQAAQAAAAAAAAABA1jRADAEMAAA AAAAAAEAAAAUAAEAAAAAAAAAAQOZQAAAADAAAAAAAAAAgAAAAIABAAAEAAAAACABWNEAMAYwAAAA AAAAAQAAABMAAQAAAAAAAAABA1jRADAGMAAAAAAAAAEAAAATAAEAAAAAAAAAAQNY0QAwBjAAAAAA AAABAAAAEwABAAAAAAAAAAEDWNEAMAYwAAAAAAAAAQAAABMAAQAAAAAAAAABA5lAAAAAMAAAAAAA AACAAAAAgAEAAAQAAAAAIAFY0QAwCDAAAAAAAAABAAAAEgABAAAAAAAAAAEDWNEAMAgwAAAAAAAA AQAAABIAAQAAAAAAAAABA1jRADAIMAAAAAAAAAEAAAASAAEAAAAAAAAAAQNY0QAwCDAAAAAAAAAB AAAAEgABAAAAAAAAAAEDmUAAAAAwAAAAAAAAAIAAAACAAQAABAAAAAAgAVjRADAKMAAAAAAAAAEA AAARAAEAAAAAAAAAAQNY0QAwCjAAAAAAAAABAAAAEQABAAAAAAAAAAEDWNEAMAowAAAAAAAAAQAA ABEAAQAAAAAAAAABA1jRADAKMAAAAAAAAAEAAAARAAEAAAAAAAAAAQOZQAAAADAAAAAAAAAAgAAA AIABAAAEAAAAACABWNEAMAwwAAAAAAAAAQAAABAAAQAAAAAAAAABA1jRADAMMAAAAAAAAAEAAAAQ AAEAAAAAAAAAAQNY0QAwDDAAAAAAAAABAAAAEAABAAAAAAAAAAEDWNEAMAwwAAAAAAAAAQAAABAA AQAAAAAAAAABA5lAAAAAMAAAAAAAAACAAAAAgAEAAAQAAAAAIAFY0QAwDjAAAAAAAAABAAAADwAB AAAAAAAAAAEDWNEAMA4wAAAAAAAAAQAAAA8AAQAAAAAAAAABA1jRADAOMAAAAAAAAAEAAAAPAAEA AAAAAAAAAQNY0QAwDjAAAAAAAAABAAAADwABAAAAAAAAAAEDmUAAAAAwAAAAAAAAAIAAAACAAQAA BAAAAAAgAVjRADAQMAAAAAAAAAEAAAAOAAEAAAAAAAAAAQNY0QAwEDAAAAAAAAABAAAADgABAAAA AAAAAAEDWNEAMBAwAAAAAAAAAQAAAA4AAQAAAAAAAAABA1jRADAQMAAAAAAAAAEAAAAOAAEAAAAA AAAAAQOZQAAAADAAAAAAAAAAgAAAAIABAAAEAAAAACABWNEAMBIwAAAAAAAAAQAAAA0AAQAAAAAA AAABA1jRADASMAAAAAAAAAEAAAANAAEAAAAAAAAAAQNY0QAwEjAAAAAAAAABAAAADQABAAAAAAAA AAEDWNEAMBIwAAAAAAAAAQAAAA0AAQAAAAAAAAABA5lAAAAAMAAAAAAAAACAAAAAgAEAAAQAAAAA IAFY0QAwFDAAAAAAAAABAAAADAABAAAAAAAAAAEDWNEAMBQwAAAAAAAAAQAAAAwAAQAAAAAAAAAB A1jRADAUMAAAAAAAAAEAAAAMAAEAAAAAAAAAAQNY0QAwFDAAAAAAAAABAAAADAABAAAAAAAAAAED mUAAAAAwAAAAAAAAAIAAAACAAQAABAAAAAAgAVjRADAWMAAAAAAAAAEAAAALAAEAAAAAAAAAAQNY 0QAwFjAAAAAAAAABAAAACwABAAAAAAAAAAEDWNEAMBYwAAAAAAAAAQAAAAsAAQAAAAAAAAABA1jR ADAWMAAAAAAAAAEAAAALAAEAAAAAAAAAAQOZQAAAADAAAAAAAAAAgAAAAIABAAAEAAAAACABWNEA MBgwAAAAAAAAAQAAAAoAAQAAAAAAAAABA1jRADAYMAAAAAAAAAEAAAAKAAEAAAAAAAAAAQNY0QAw GDAAAAAAAAABAAAACgABAAAAAAAAAAEDWNEAMBgwAAAAAAAAAQAAAAoAAQAAAAAAAAABA5lAAAAA MAAAAAAAAACAAAAAgAEAAAQAAAAAIAFY0QAwGjAAAAAAAAABAAAACQABAAAAAAAAAAEDWNEAMBow AAAAAAAAAQAAAAkAAQAAAAAAAAABA1jRADAaMAAAAAAAAAEAAAAJAAEAAAAAAAAAAQNY0QAwGjAA AAAAAAABAAAACQABAAAAAAAAAAEDmUAAAAAwAAAAAAAAAIAAAACAAQAABAAAAAAgAVjRADAcMAAA AAAAAAEAAAAIAAEAAAAAAAAAAQNY0QAwHDAAAAAAAAABAAAACAABAAAAAAAAAAEDWNEAMBwwAAAA AAAAAQAAAAgAAQAAAAAAAAABA1jRADAcMAAAAAAAAAEAAAAIAAEAAAAAAAAAAQOZQAAAADAAAAAA AAAAgAAAAIABAAAEAAAAACABWNEAMB4wAAAAAAAAAQAAAAcAAQAAAAAAAAABA1jRADAeMAAAAAAA AAEAAAAHAAEAAAAAAAAAAQNY0QAwHjAAAAAAAAABAAAABwABAAAAAAAAAAEDWNEAMB4wAAAAAAAA AQAAAAcAAQAAAAAAAAABA5lAAAAAMAAAAAAAAACAAAAAgAEAAAQAAAAAIAFY0QAwIDAAAAAAAAAB AAAABgABAAAAAAAAAAEDWNEAMCAwAAAAAAAAAQAAAAYAAQAAAAAAAAABA1jRADAgMAAAAAAAAAEA AAAGAAEAAAAAAAAAAQNY0QAwIDAAAAAAAAABAAAABgABAAAAAAAAAAEDmUAAAAAwAAAAAAAAAIAA AACAAQAABAAAAAAgAVjRADAiMAAAAAAAAAEAAAAFAAEAAAAAAAAAAQNY0QAwIjAAAAAAAAABAAAA BQABAAAAAAAAAAEDWNEAMCIwAAAAAAAAAQAAAAUAAQAAAAAAAAABA1jRADAiMAAAAAAAAAEAAAAF AAEAAAAAAAAAAQOZQAAAADAAAAAAAAAAgAAAAIABAAAEAAAAACABWNEAMCQwAAAAAAAAAQAAAAQA AQAAAAAAAAABA1jRADAkMAAAAAAAAAEAAAAEAAEAAAAAAAAAAQNY0QAwJDAAAAAAAAABAAAABAAB AAAAAAAAAAEDWNEAMCQwAAAAAAAAAQAAAAQAAQAAAAAAAAABA5lAAAAAMAAAAAAAAACAAAAAgAEA AAQAAAAAIAFY0QAwJjAAAAAAAAABAAAAAwABAAAAAAAAAAEDWNEAMCYwAAAAAAAAAQAAAAMAAQAA AAAAAAAgAVjRADAmMAAAAAAAAAEAAAADAAEAAAAAAAAAIAFY0QAwJjAAAAAAAAABAAAAAwABAAAA AAAAACABmUAAAAAwAAAAAAAAAIAAAACAAQAABAAAAAAgAVrRADAAMAAAAAAAAAEAAAAXAAEAAAAA AAAAAQda0QAwADAAAAAAAAABAAAAFwABAAAAAAAAAAEHWtEAMAAwAAAAAAAAAQAAABcAAQAAAAAA AAABB5lAAAAAMAAAAAAAAACAAAAAgAEAAAQAAAAAIAFY0QAwAjAAAAAAAAABAAAAFgABAAAAAAAA AAEDWNEAMAIwAAAAAAAAAQAAABYAAQAAAAAAAAABA1jRADACMAAAAAAAAAEAAAAWAAEAAAAAAAAA AQOZQAAAADAAAAAAAAAAgAAAAIABAAAEAAAAACABWNEAMAQwAAAAAAAAAQAAABUAAQAAAAAAAAAB A1jRADAEMAAAAAAAAAEAAAAVAAEAAAAAAAAAAQNY0QAwBDAAAAAAAAABAAAAFQABAAAAAAAAAAED mUAAAAAwAAAAAAAAAIAAAACAAQAABAAAAAAgAVjRADAGMAAAAAAAAAEAAAAUAAEAAAAAAAAAAQNY 0QAwBjAAAAAAAAABAAAAFAABAAAAAAAAAAEDWNEAMAYwAAAAAAAAAQAAABQAAQAAAAAAAAABA5lA AAAAMAAAAAAAAACAAAAAgAEAAAQAAAAAIAFY0QAwCDAAAAAAAAABAAAAEwABAAAAAAAAAAEDWNEA MAgwAAAAAAAAAQAAABMAAQAAAAAAAAABA1jRADAIMAAAAAAAAAEAAAATAAEAAAAAAAAAAQOZQAAA ADAAAAAAAAAAgAAAAIABAAAEAAAAACABWNEAMAowAAAAAAAAAQAAABIAAQAAAAAAAAABA1jRADAK MAAAAAAAAAEAAAASAAEAAAAAAAAAAQNY0QAwCjAAAAAAAAABAAAAEgABAAAAAAAAAAEDmUAAAAAw AAAAAAAAAIAAAACAAQAABAAAAAAgAVjRADAMMAAAAAAAAAEAAAARAAEAAAAAAAAAAQNY0QAwDDAA AAAAAAABAAAAEQABAAAAAAAAAAEDWNEAMAwwAAAAAAAAAQAAABEAAQAAAAAAAAABA5lAAAAAMAAA AAAAAACAAAAAgAEAAAQAAAAAIAFY0QAwDjAAAAAAAAABAAAAEAABAAAAAAAAAAEDWNEAMA4wAAAA AAAAAQAAABAAAQAAAAAAAAABA1jRADAOMAAAAAAAAAEAAAAQAAEAAAAAAAAAAQOZQAAAADAAAAAA AAAAgAAAAIABAAAEAAAAACABWNEAMBAwAAAAAAAAAQAAAA8AAQAAAAAAAAABA1jRADAQMAAAAAAA AAEAAAAPAAEAAAAAAAAAAQNY0QAwEDAAAAAAAAABAAAADwABAAAAAAAAAAEDmUAAAAAwAAAAAAAA AIAAAACAAQAABAAAAAAgAVjRADASMAAAAAAAAAEAAAAOAAEAAAAAAAAAAQNY0QAwEjAAAAAAAAAB AAAADgABAAAAAAAAAAEDWNEAMBIwAAAAAAAAAQAAAA4AAQAAAAAAAAABA5lAAAAAMAAAAAAAAACA AAAAgAEAAAQAAAAAIAFY0QAwFDAAAAAAAAABAAAADQABAAAAAAAAAAEDWNEAMBQwAAAAAAAAAQAA AA0AAQAAAAAAAAABA1jRADAUMAAAAAAAAAEAAAANAAEAAAAAAAAAAQOZQAAAADAAAAAAAAAAgAAA AIABAAAEAAAAACABWNEAMBYwAAAAAAAAAQAAAAwAAQAAAAAAAAABA1jRADAWMAAAAAAAAAEAAAAM AAEAAAAAAAAAAQNY0QAwFjAAAAAAAAABAAAADAABAAAAAAAAAAEDmUAAAAAwAAAAAAAAAIAAAACA AQAABAAAAAAgAVjRADAYMAAAAAAAAAEAAAALAAEAAAAAAAAAAQNY0QAwGDAAAAAAAAABAAAACwAB AAAAAAAAAAEDWNEAMBgwAAAAAAAAAQAAAAsAAQAAAAAAAAABA5lAAAAAMAAAAAAAAACAAAAAgAEA AAQAAAAAIAFY0QAwGjAAAAAAAAABAAAACgABAAAAAAAAAAEDWNEAMBowAAAAAAAAAQAAAAoAAQAA AAAAAAABA1jRADAaMAAAAAAAAAEAAAAKAAEAAAAAAAAAAQOZQAAAADAAAAAAAAAAgAAAAIABAAAE AAAAACABWNEAMBwwAAAAAAAAAQAAAAkAAQAAAAAAAAABA1jRADAcMAAAAAAAAAEAAAAJAAEAAAAA AAAAAQNY0QAwHDAAAAAAAAABAAAACQABAAAAAAAAAAEDmUAAAAAwAAAAAAAAAIAAAACAAQAABAAA AAAgAVjRADAeMAAAAAAAAAEAAAAIAAEAAAAAAAAAAQNY0QAwHjAAAAAAAAABAAAACAABAAAAAAAA AAEDWNEAMB4wAAAAAAAAAQAAAAgAAQAAAAAAAAABA5lAAAAAMAAAAAAAAACAAAAAgAEAAAQAAAAA IAFY0QAwIDAAAAAAAAABAAAABwABAAAAAAAAAAEDWNEAMCAwAAAAAAAAAQAAAAcAAQAAAAAAAAAB A1jRADAgMAAAAAAAAAEAAAAHAAEAAAAAAAAAAQOZQAAAADAAAAAAAAAAgAAAAIABAAAEAAAAACAB WNEAMCIwAAAAAAAAAQAAAAYAAQAAAAAAAAABA1jRADAiMAAAAAAAAAEAAAAGAAEAAAAAAAAAAQNY 0QAwIjAAAAAAAAABAAAABgABAAAAAAAAAAEDmUAAAAAwAAAAAAAAAIAAAACAAQAABAAAAAAgAVjR ADAkMAAAAAAAAAEAAAAFAAEAAAAAAAAAAQNY0QAwJDAAAAAAAAABAAAABQABAAAAAAAAAAEDWNEA MCQwAAAAAAAAAQAAAAUAAQAAAAAAAAABA5lAAAAAMAAAAAAAAACAAAAAgAEAAAQAAAAAIAFY0QAw JjAAAAAAAAABAAAABAABAAAAAAAAAAEDWNEAMCYwAAAAAAAAAQAAAAQAAQAAAAAAAAABA1jRADAm MAAAAAAAAAEAAAAEAAEAAAAAAAAAAQOZQAAAADAAAAAAAAAAgAAAAIABAAAEAAAAACABWNEAMCgw AAAAAAAAAQAAAAMAAQAAAAAAAAAgAVjRADAoMAAAAAAAAAEAAAADAAEAAAAAAAAAIAFY0QAwKDAA AAAAAAABAAAAAwABAAAAAAAAACABmUAAAAAwAAAAAAAAAIAAAACAAQAABAAAAAAgAViRADDzMQAA AAAAAAEAAAAEAAAAAAAAAAAAAAFYkQAw8zEAAAAAAAACAAAAAgAAAAAAAAAAAAABWJEAMAAwAAAA AAAAAQAAAAAAAAAAAAAAAACAAViRADD2MQAAAAAAAAIAAAAEAAAA9wEAANBAEAdYkQAwADAAAAAA AAABAAAAAAABAAAEAAAAACABWJEAMPgxAAAAAAAAAQAAAAQAAQAAAAAAAAAgAViRADD2MQAAAAAA AAIAAAACAAEAAAAAAAAAIAFYkQAwADAAAAAAAAABAAAAAAABAAAEAAAAAKABWJEAMPsxAAAAAAAA AgAAAAIAAQAAAAAAAAAgAVqRADD7MQAAAAAAAAIAAAACAAEAAAAAAAAAIAdYkQAwADAAAAAAAAAB AAAAAAABAAAEAAAAAKABWpEAMP4RAAAAAAAAAgAAAAIAAQAAAAAAAAAgB1qRADD+AQAAAAAAAAIA AAACAAAA/wEAALBBEAdYkQAwADAAAAAAAAABAAAAAAAAAAAAAACkDqAFWJEAMAAwAAAAAAAAAQAA AAAAAAAAAAAAAACABwAGAAA+CwAAhBAAACcYAACWHgAAnh8AABAAAAAYAAAAMgAAAE4AAAB2AAAA AAYAAIMIAADSCAAAQwkAAGsJAAAtCwAATQsAAFwLAABqCwAAeAsAAIULAACSCwAAnwsAAKwLAAC5 CwAAxgsAAIoNAADKDQAA8g0AACEOAABIDgAAdA4AALMOAADmDgAALA8AAF4PAACNDwAAtQ8AAPcP AAAbEAAAWxAAAIwQAAC8EAAA7hAAABYRAABXEQAAghEAAMARAADzEQAANRIAAGoSAACiEgAA4xIA ACETAABiEwAAhBMAALoTAAACFAAAQxQAAHwUAACyFAAA+RQAAC8VAABwFQAAuBUAAO4VAAApFgAA GBgAAFMYAAB5GAAApRgAAMIYAADsGAAAFBkAAEcZAACEGQAAqxkAAOQZAAALGgAAKxoAAEkaAAB5 GgAAmxoAANAaAAD2GgAAJRsAAGEbAACWGwAAuhsAAOkbAAAMHAAAOBwAAHAcAACVHAAAuRwAANgc AADqHAAAEB0AADYdAABZHQAAeB0AAKIdAADQHQAA/B0AAC0eAABiHgAAlR4AALEeAAD8HgAAMh8A AGcfAACcHwAAnh8AABEAAAATAAAAFAAAABUAAAAWAAAAFwAAABkAAAAaAAAAGwAAABwAAAAdAAAA HgAAAB8AAAAgAAAAIQAAACIAAAAjAAAAJAAAACUAAAAmAAAAJwAAACgAAAApAAAAKgAAACsAAAAs AAAALQAAAC4AAAAvAAAAMAAAADEAAAAzAAAANAAAADUAAAA2AAAANwAAADgAAAA5AAAAOgAAADsA AAA8AAAAPQAAAD4AAAA/AAAAQAAAAEEAAABCAAAAQwAAAEQAAABFAAAARgAAAEcAAABIAAAASQAA AEoAAABLAAAATAAAAE0AAABPAAAAUAAAAFEAAABSAAAAUwAAAFQAAABVAAAAVgAAAFcAAABYAAAA WQAAAFoAAABbAAAAXAAAAF0AAABeAAAAXwAAAGAAAABhAAAAYgAAAGMAAABkAAAAZQAAAGYAAABn AAAAaAAAAGkAAABqAAAAawAAAGwAAABtAAAAbgAAAG8AAABwAAAAcQAAAHIAAABzAAAAdAAAAHUA AAB3AAAAeAAAAHkAAAB6AAAAewAAAAAGAACeHwAAEgAAAA8AAPA4AAAAAAAG8BgAAAACCAAAAgAA AAEAAAABAAAAAQAAAAIAAABAAB7xEAAAAP//AAAAAP8AgICAAPcAABAADwAC8JIAAAAQAAjwCAAA AAEAAAABBAAADwAD8DAAAAAPAATwKAAAAAEACfAQAAAAAAAAAAAAAAAAAAAAAAAAAAIACvAIAAAA AAQAAAUAAAAPAATwQgAAABIACvAIAAAAAQQAAAAOAABTAAvwHgAAAL8BAAAQAMsBAAAAAP8BAAAI AAQDCQAAAD8DAQABAAAAEfAEAAAAAQAAAP//AwAAAAkATwBMAEUAXwBMAEkATgBLADcACQBPAEwA RQBfAEwASQBOAEsAOAAJAE8ATABFAF8ATABJAE4ASwA5AAAAAAA5FAAAORQAAKAXAAAAAAAAAQAA AAIAAADKAwAAZBQAAGQUAACgFwAA//8YAAAABgCGVHsCEQABABxECggGAIdUewIQAAEAHEMKCAYA iFR7AhEAAQAcPwoIBgCJVHsCEQABAFxDCggGAIpUewIQAAEAnEQKCAYAi1R7AhAAAQBcPwoIBgCM VHsCEQABANxCCggGAI1UewIQAAEA3EQKCAYAjlR7AhEAAQAcQQoIBgCPVHsCEAABAJxBCggGAJBU ewIRAAEAXEQKCAYAkVR7AhAAAQAcRQoIBgCSVHsCEQABAFxFCggGAJNUewIRAAEAnEUKCAYAlFR7 AhAAAQDcRQoIBgCVVHsCEQABABxGCggGAJZUewIRAAEAXEYKCAYAl1R7AhAAAQCcRgoIBgCYVHsC EQABANxGCggGAJlUewIRAAEAHEcKCAYAmlR7AhAAAQBcRwoIBgCbVHsCEQABAJxHCggGAJxUewIR AAEA3EcKCAYAnVR7AhAAAQAcSAoI0QEAANEBAADEBAAAzwQAAM8EAABPBwAATwcAAKoHAACqBwAA rQgAAK0IAACbCQAAmwkAAOkRAAD5EQAA+REAADASAAA7EgAAOxIAANUSAADkEgAA5BIAAHwTAAB8 EwAAoBcAAAAAAAACAAEAAAACAAIAAAABAAMAAAACAAQAAAACAAUAAAACAAYAAAACAAcAAAACAAgA AAACAAkAAAACAAoAAAACAAsAAAACAAwAAAACAA0AAAABAA4AAAACAA8AAAACABAAAAABABEAAAAC ABIAAAACABMAAAABABQAAAACABUAAAACABYAAAACABcAAAACANcBAADXAQAAygQAANUEAADVBAAA VQcAAFUHAACsBwAArAcAALMIAACzCAAAngkAAJ4JAADvEQAA/xEAAP8RAAAyEgAAPRIAAD0SAADb EgAA6hIAAOoSAAB/EwAAfxMAAKAXAAAAAAAAAQAAAAIAAAADAAAABAAAAAUAAAAGAAAABwAAAAgA AAAJAAAACgAAAAsAAAAMAAAADQAAAA4AAAAPAAAAEAAAABEAAAASAAAAEwAAABQAAAAVAAAAFgAA ABcAAAACAAAAQgAAABgAAAAqgHVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOnNtYXJ0 dGFncw6AY291bnRyeS1yZWdpb24AgDkAAAAXAAAAKoB1cm46c2NoZW1hcy1taWNyb3NvZnQtY29t Om9mZmljZTpzbWFydHRhZ3MFgHBsYWNlAIAMAAAB1F4xAgAAAAAYAAAAAAAXAAAAAAAYAAAAAAAY AAAAAAAXAAAAAAAXAAAAAAAYAAAAAAAXAAAAAAAYAAAAAAAXAAAAAAAYAAAAAAAXAAAAAAAYAAAA AAAYAAAAAAAXAAAAAAAYAAAAAAAYAAAAAAAXAAAAAAAYAAAAAAAYAAAAAAAXAAAAAAAYAAAAAAAY AAAAAAAXAAAAAAAAAAAAUAAAAFkAAABcAQAAYwEAAHQFAAB3BQAAgAUAAIMFAACoBQAArQUAANgF AADbBQAABgYAAA4GAABaBgAAYQYAAIsGAACUBgAA/gYAAAYHAABGBwAATgcAAKIHAACpBwAA0AcA ANcHAAAFCAAACAgAAGUIAACDCAAA/AgAAP8IAABoCQAAcQkAAJQJAACXCQAAnwkAAKIJAACrCQAA rgkAAA4KAAAVCgAAqAsAAK4LAACgDAAApgwAAB0NAAAjDQAAlw0AAKENAADcDQAA4g0AABcOAAAd DgAAQw4AAEYOAACPDwAAkg8AAC8QAAA0EAAAXBAAAF8QAACIEAAAkBAAAM8QAADWEAAA/hAAAAQR AABZEQAAYhEAALMRAAC7EQAA8BEAAPgRAAAzEgAAOhIAAE8SAABWEgAAghIAAIUSAAD7EgAAGRMA AKQTAACqEwAADhQAABUUAAASFQAAHBUAAFsVAABhFQAAehUAAIQVAACkFQAArhUAANcWAADaFgAA BhcAAAkXAAA8FwAAPxcAAHEXAAB0FwAAoBcAAAcAHAAHABwABwAcAAcAHAAHABwABwAbAAcAHAAH ABwABwAcAAcAHAAHABwABwAcAAcAHAAHABsABwAFAAcAGwAHABwABwAcAAcAHAAHABwABwAcAAcA HAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAGwAHABwABwAcAAcAHAAHABwABwAc AAcAHAAHABwABwAcAAcAGwAHAAUABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwA BwAcAAcAAAAAAAEAAAAQAAAArwEAALMBAABaAgAAawIAANkCAADjAgAA5QIAAPYCAAAmBAAAMAQA AH0EAADWBAAAZQgAAIMIAABDDgAASA4AAOsOAABlDwAAjw8AAJIPAAD7EgAAGRMAANcWAADcFgAA oBcAAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHAAUABwAzAAcAMwAHADMABwAFAAcAMwAH AAAAAAABAAAAGgAAAFAAAADTAAAAFQEAAEQBAABlAQAAbAEAAOUCAAD2AgAAJQMAAMkDAABABQAA UAUAAFEFAACfBQAAwgUAAH4GAACrBgAAvQYAAN4GAADxBgAAJAcAAMAHAADvBwAAJQgAAFMIAABl CAAAhAgAAJcIAAC0CAAAHwkAAE8JAABhCQAAegkAAIMJAACECQAAwAkAAMEJAADKCQAA6wkAAP4J AAAtCgAAdAoAAJsKAACtCgAA3AoAAO4KAAAaCwAALAsAAFsLAACPCwAAswsAAMULAAD7CwAADQwA ADwMAABNDAAAdQwAAIcMAACrDAAAvAwAAPIMAAAEDQAAKA0AADoNAABpDQAAww0AAOcNAAD5DQAA Ig4AACoOAABNEAAATBEAAHkRAACwEQAA2REAAKASAADFEgAA+xIAABoTAAAqEwAAVhMAADkUAABl FAAA/RUAACMWAAAuFgAAWBYAALIWAADhFgAA/RYAACEXAAAzFwAAVhcAAGgXAACLFwAAnRcAAKAX AAAHAAUABwAFAAcABQAHAAUABwAFAAcABQAHAAUABwAFAAcABQAHAAUABwAFAAcABQAHAAUABwAF AAcABQAHAAUABwAFAAcABQAHAAUABwAFAAcABQAHAAUABwAFAAcABQAHAAUABwAFAAcABQAHAAUA BwAFAAcABQAHAAUABwAFAAcABQAHAAUABwAFAAcABQAHAAUABwAFAAcABQAHAAUABwAFAAcABQAH AAUABwAFAAcABQAHAAUABwAFAAcABQAHAAUABwAAAAAA7BYAAPsWAAD9FgAABhcAAAgXAAAJFwAA KBcAADEXAAAzFwAAVRcAAFYXAABmFwAAaBcAAIoXAACLFwAAmxcAAJ0XAACgFwAAAwAEAAMABAAD AAQAAwAEAAMABAADAAQAAwAEAAMABAADAAcACQAnADcKAAAAAAAAAAAAAQIAAgDVU+wQAAAAAAAA AAAAAQIAAgAhBBoaAAAAAAAAAAAAAQIAAgBxGgAlAAAAAAAAAAAAAQIAAgAJX2w3AAAAAAAAAAAA AQIAAgBVHStOAAAAAAAAAAAAAQIAAgAzbEZpAAAAAAAAAAAAAQIAAgAmfQVrAAAAAAAAAAAAAQIA AgCnIXB4AAAAAAAAAAAAAQIAAgB5AAAABAAAAAgAAADlAAAAAAAAAHgAAABjKAEAlzAHAAR3DQAV aw4ArnAPAOA1EADJVBAA8HURALg4FQDAORkAxxMbACcFHAAufh4AxHMfAN45IQC3aiIAJQ0kAAcu JACDMyQA2TkkAD0DLQAUCi0AhyA1ABhINQChdzUA/345AFEoPAD/Tz4ABCs/ABEOQQC3MkEA4G5B AMcPRABvX0QA/xtGAOgkUgBAIlMAfiVUAD49VACVL1UATERWADRDWACLIVoA731bAA0zXADMWl0A vjNlANd9agBDK2wA8hRuAChZcQBKYnEA5yByAHYpdgBqJHsAEwB+AGdHfwAReH8AV3qEABNYhwAT XYgAtW6IADQ0jwCHVJQAwRWVAPEtlQBqUJgANG+YAB5ZmgDACpwAqWaiAJNPowBhH6UAoRCmAEY2 pwBzVKcANEmoADkOqQAneqwAqgKwAGRzsgAdC7MA7iS2ABJSwQC5CcIAjSbHAGd+xwCMM8gA9XfJ AGIsygCoccsA9gLNACsozQB9Ks0A4WvOAHRB0QCoBdIAjQ/UADkP2ABJDNsAH0fcADVH3QCcJuEA VEPhAKts4wAZNOcARQPoADQy6QAacOoAoyvrAOgz7ABVZ+wAmibzABUo8wAwZPcAwzn7ABVQ/ACO Mf0AAiX+AOZU/gDcZf4AAAAAABIAAAAaAAAATwAAAFAAAABaAAAAgwAAAIQAAACeAAAA0gAAANMA AAAVAQAAQwEAAEQBAABlAQAAawEAAGwBAAAlAwAALQMAADMDAAA+AwAAPwMAAEMDAABIAwAATQMA AE4DAABSAwAAVwMAAFwDAABdAwAAYQMAAGYDAABqAwAAawMAAG8DAAB0AwAAeAMAAHkDAAB9AwAA gQMAAIUDAACGAwAAigMAAI4DAACSAwAAkwMAAJcDAACbAwAAnwMAAKADAACkAwAAqAMAAKwDAACt AwAAsQMAALUDAAC5AwAAugMAAL4DAADCAwAAxgMAAMcDAAB0BQAAeAUAAIAFAACEBQAAigUAAJUF AACWBQAAmwUAAJ8FAADCBQAAxgUAAMoFAADLBQAA0AUAANQFAADqBQAA7gUAAPIFAADzBQAA+AUA APwFAAAZBgAAHQYAACEGAAAiBgAAJwYAACsGAABABgAARAYAAEgGAABJBgAATgYAAFIGAABsBgAA cAYAAHQGAAB1BgAAegYAAH4GAACrBgAArwYAALMGAAC0BgAAuQYAAL0GAADeBgAA4gYAAOYGAADn BgAA7QYAAPEGAAAkBwAAKAcAACwHAAAtBwAAMgcAADYHAABWBwAAWgcAAF4HAABfBwAAZQcAAGkH AACFBwAAiQcAAI0HAACOBwAAkwcAAJcHAACtBwAAsQcAALUHAAC2BwAAvAcAAMAHAADvBwAA8wcA APcHAAD4BwAA/QcAAAEIAAATCAAAFwgAABsIAAAcCAAAIQgAACUIAABTCAAAVwgAAFsIAABcCAAA YQgAAGUIAACECAAAiAgAAIwIAACNCAAAkwgAAJcIAAC0CAAAuAgAALwIAAC9CAAAwggAAMYIAADm CAAA6ggAAO4IAADvCAAA9AgAAPgIAAAOCQAAEgkAABYJAAAXCQAAGwkAAB8JAABPCQAAUwkAAFcJ AABYCQAAXQkAAGEJAAB6CQAAfgkAAIIJAACDCQAAnwkAAKMJAACrCQAArwkAALUJAADACQAAwQkA AMYJAADKCQAA6wkAAO8JAADzCQAA9AkAAPoJAAD+CQAALQoAADEKAAA1CgAANgoAADwKAABACgAA YwoAAGYKAABqCgAAawoAAHAKAAB0CgAAmwoAAJ4KAACiCgAAowoAAKkKAACtCgAA3AoAAN8KAADj CgAA5AoAAOoKAADuCgAAGgsAAB0LAAAhCwAAIgsAACgLAAAsCwAAWwsAAF4LAABiCwAAYwsAAGcL AABrCwAAfQsAAIALAACECwAAhQsAAIsLAACPCwAAswsAALYLAAC6CwAAuwsAAMELAADFCwAA+wsA AP4LAAACDAAAAwwAAAkMAAANDAAAPAwAAD8MAABDDAAARAwAAEkMAABNDAAAdQwAAHgMAAB8DAAA fQwAAIMMAACHDAAAqwwAAK4MAACyDAAAswwAALgMAAC8DAAA8gwAAPUMAAD5DAAA+gwAAAANAAAE DQAAKA0AACsNAAAvDQAAMA0AADYNAAA6DQAAaQ0AAGwNAABwDQAAcQ0AAHcNAAB7DQAAsQ0AALQN AAC4DQAAuQ0AAL8NAADDDQAA5w0AAOoNAADuDQAA7w0AAPUNAAD5DQAAIg4AACUOAAApDgAAKg4A AAsQAAATEAAAGBAAAB0QAAAnEAAAKBAAACwQAABJEAAATRAAAFMQAABUEAAAWBAAAG4QAAByEAAA eRAAAHoQAAB+EAAAmxAAAJ8QAAClEAAAphAAAKoQAAC3EAAAuxAAAMIQAADDEAAAxxAAAOEQAADl EAAA7BAAAO0QAADxEAAACREAAA0RAAAUEQAAFREAABkRAAA9EQAAQREAAEcRAABIEQAATBEAAHkR AAB9EQAAhBEAAIURAACJEQAAoREAAKURAACrEQAArBEAALARAADZEQAA3REAAOQRAADlEQAA6REA AAASAAAEEgAACxIAAAwSAAAQEgAAIBIAACQSAAArEgAALBIAADASAAA+EgAAQhIAAEkSAABKEgAA ThIAAG4SAAByEgAAeRIAAHoSAAB+EgAAkBIAAJQSAACbEgAAnBIAAKASAADFEgAAyRIAANASAADR EgAA1RIAAOsSAADvEgAA9hIAAPcSAAD7EgAAGhMAAB4TAAAlEwAAJhMAACoTAABWEwAAWhMAAGET AABiEwAAgBMAAIUTAACLEwAAlhMAAJcTAACvEwAAsxMAALoTAAC7EwAA3xMAAOMTAADpEwAA6hMA AAIUAAAGFAAADBQAAA0UAAAtFAAAMRQAADgUAAA5FAAAZRQAAGkUAABwFAAAcRQAAIoUAACOFAAA lRQAAJYUAACuFAAAshQAALkUAAC6FAAAzhQAANEUAADYFAAA2RQAAOAUAADjFAAA6hQAAOsUAAAG FQAACRUAABAVAAARFQAALBUAAC8VAAA2FQAANxUAAE8VAABSFQAAWRUAAFoVAABuFQAAcRUAAHgV AAB5FQAAmBUAAJsVAACiFQAAoxUAAMcVAADKFQAA0BUAANEVAADzFQAA9hUAAPwVAAD9FQAAIxYA ACYWAAAtFgAALhYAAFgWAABbFgAAYhYAAGMWAACLFgAAjhYAAJUWAACWFgAApxYAAKoWAACxFgAA shYAAOAWAADhFgAA/BYAAP0WAAAhFwAAMhcAADMXAABWFwAAZxcAAGgXAACLFwAAnBcAAJ0XAACg FwAAAAAAAAgAAAACAQAAAgEAAJ4BAAACAQAAAgEAAJ4BAAACAQAAAgEAAJ4BAAACAQAAAgEAAJ4B AAACAQAAAgEAAJYBAAAIAAAAAgEAAAIBAAACAQAAngEAAAIBAAACAQAAAgEAAJ4BAAACAQAAAgEA AAIBAACeAQAAAgEAAAIBAAACAQAAngEAAAIBAAACAQAAAgEAAJ4BAAACAQAAAgEAAAIBAACeAQAA AgEAAAIBAAACAQAAngEAAAIBAAACAQAAAgEAAJ4BAAACAQAAAgEAAAIBAACeAQAAAgEAAAIBAAAC AQAAngEAAAIBAAACAQAAAgEAAJYBAAAIAAAAAgEAAAIBAAACAQAAAgEAAAIBAACeAQAAAgEAAAIB AAACAQAAAgEAAAIBAACeAQAAAgEAAAIBAAACAQAAAgEAAAIBAACeAQAAAgEAAAIBAAACAQAAAgEA AAIBAACeAQAAAgEAAAIBAAACAQAAAgEAAAIBAACeAQAAAgEAAAIBAAACAQAAAgEAAAIBAACeAQAA AgEAAAIBAAACAQAAAgEAAAIBAACeAQAAAgEAAAIBAAACAQAAAgEAAAIBAACeAQAAAgEAAAIBAAAC AQAAAgEAAAIBAACeAQAAAgEAAAIBAAACAQAAAgEAAAIBAACeAQAAAgEAAAIBAAACAQAAAgEAAAIB AACeAQAAAgEAAAIBAAACAQAAAgEAAAIBAACeAQAAAgEAAAIBAAACAQAAAgEAAAIBAACeAQAAAgEA AAIBAAACAQAAAgEAAAIBAACeAQAAAgEAAAIBAAACAQAAAgEAAAIBAACeAQAAAgEAAAIBAAACAQAA AgEAAAIBAACeAQAAAgEAAAIBAAACAQAAAgEAAAIBAACeAQAAAgEAAAIBAAACAQAAAgEAAAIBAACe AQAAAgEAAAIBAAACAQAAAgEAAAIBAACeAQAAAgEAAAIBAAACAQAAAgEAAAIBAACeAQAAAgEAAAIB AAACAQAAAgEAAAIBAACWAQAACAAAAAIBAAACAQAAAgEAAAIBAAACAQAAngEAAAIBAAACAQAAAgEA AAIBAAACAQAAngEAAAIBAAACAQAAAgEAAAIBAAACAQAAngEAAAIBAAACAQAAAgEAAAIBAAACAQAA ngEAAAIBAAACAQAAAgEAAAIBAAACAQAAngEAAAIBAAACAQAAAgEAAAIBAAACAQAAngEAAAIBAAAC AQAAAgEAAAIBAAACAQAAngEAAAIBAAACAQAAAgEAAAIBAAACAQAAngEAAAIBAAACAQAAAgEAAAIB AAACAQAAngEAAAIBAAACAQAAAgEAAAIBAAACAQAAngEAAAIBAAACAQAAAgEAAAIBAAACAQAAngEA AAIBAAACAQAAAgEAAAIBAAACAQAAngEAAAIBAAACAQAAAgEAAAIBAAACAQAAngEAAAIBAAACAQAA AgEAAAIBAAACAQAAngEAAAIBAAACAQAAAgEAAAIBAAACAQAAngEAAAIBAAACAQAAAgEAAAIBAAAC AQAAngEAAAIBAAACAQAAAgEAAAIBAAACAQAAngEAAAIBAAACAQAAAgEAAAIBAAACAQAAngEAAAIB AAACAQAAAgEAAAIBAAACAQAAngEAAAIBAAACAQAAAgEAAAIBAAACAQAAlgEAAAgAAAACAQAAAgEA AAIBAAACAQAAngEAAAIBAAACAQAAAgEAAAIBAACeAQAAAgEAAAIBAAACAQAAAgEAAJ4BAAACAQAA AgEAAAIBAAACAQAAngEAAAIBAAACAQAAAgEAAAIBAACeAQAAAgEAAAIBAAACAQAAAgEAAJ4BAAAC AQAAAgEAAAIBAAACAQAAngEAAAIBAAACAQAAAgEAAAIBAACeAQAAAgEAAAIBAAACAQAAAgEAAJ4B AAACAQAAAgEAAAIBAAACAQAAngEAAAIBAAACAQAAAgEAAAIBAACeAQAAAgEAAAIBAAACAQAAAgEA AJ4BAAACAQAAAgEAAAIBAAACAQAAngEAAAIBAAACAQAAAgEAAAIBAACeAQAAAgEAAAIBAAACAQAA AgEAAJ4BAAACAQAAAgEAAAIBAAACAQAAngEAAAIBAAACAQAAAgEAAAIBAACeAQAAAgEAAAIBAAAC AQAAAgEAAJ4BAAACAQAAAgEAAAIBAAACAQAAngEAAAIBAAACAQAAAgEAAAIBAACWAQAACAAAAAIB AAACAQAAAgEAAJ4BAAACAQAAAgEAAAIBAACeAQAAAgEAAAIBAAACAQAAngEAAAIBAAACAQAAAgEA AJ4BAAACAQAAAgEAAAIBAACeAQAAAgEAAAIBAAACAQAAngEAAAIBAAACAQAAAgEAAJ4BAAACAQAA AgEAAAIBAACeAQAAAgEAAAIBAAACAQAAngEAAAIBAAACAQAAAgEAAJ4BAAACAQAAAgEAAAIBAACe AQAAAgEAAAIBAAACAQAAngEAAAIBAAACAQAAAgEAAJ4BAAACAQAAAgEAAAIBAACeAQAAAgEAAAIB AAACAQAAngEAAAIBAAACAQAAAgEAAJ4BAAACAQAAAgEAAAIBAACeAQAAAgEAAAIBAAACAQAAngEA AAIBAAACAQAAAgEAAJ4BAAACAQAAAgEAAAIBAACeAQAAAgEAAAIBAAACAQAAlgEAAAgAAAACAQAA AgEAAJ4BAAACAQAAAgEAAJ4BAAACAQAAAgEAAJ4BAAACAQAAAgEAAJYBAAD/QACAAQAAAAAAAAAA APBo/AEBAAEAAAAAAAAAAAAAAAAAAAAAAAIQAAAAAAAAAJ4XAABQAAAQAEAAAP//AQAAAAcAVQBu AGsAbgBvAHcAbgD//wEACAAAAAAAAAAAAAAA//8BAAAAAAD//wAAAgD//wAAAAD//wAAAgD//wAA AAAEAAAARxaQAQAAAgIGAwUEBQIDBId6ACAAAACACAAAAAAAAAD/AQAAAAAAAFQAaQBtAGUAcwAg AE4AZQB3ACAAUgBvAG0AYQBuAAAANRaQAQIABQUBAgEHBgIFBwAAAAAAAAAQAAAAAAAAAAAAAACA AAAAAFMAeQBtAGIAbwBsAAAAMyaQAQAAAgsGBAICAgICBId6ACAAAACACAAAAAAAAAD/AQAAAAAA AEEAcgBpAGEAbAAAAFcBkAGBBwIDBgAAAQEBAQEBAAAAAAAGCRAAAAAAAAAAAAAIAAAAAABCAGEA dABhAG4AZwAAAEEAcgBpAGEAbAAgAFUAbgBpAGMAbwBkAGUAIABNAFMAAAAiAAQAcQiKGADw0AIA AGgBAAAAAO6LyAZBkMgmAAAAAAYADAIAAMMDAAD1EgAABACfAQAABAADENcBAADDAwAA9RIAAAQA nwEAANcBAAAAAAAAIQMA8BAAAAABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACAegBbQAtACBgTI0 AAAQABkAZAAAABkAAAB+FQAAfhUAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAIAAAAAAAAAAAAJMoNRAPAQAAgAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAEhYAAAAAAnw/w8BAAE/AADkBAAA////f////3////9/////f////3// //9/////fzBk9wAAAAAAMgAAAAAAAAAAAAAAAAAAAAAA//8SAAAAAAAAAA4AQwBvAGwAbABlAGMA dABlAGQAIABkAGEAdABhAAAAAAAAAAwAUwB0AGEAcwAgAEsAaABpAHIAbQBhAG4ADABTAHQAYQBz ACAASwBoAGkAcgBtAGEAbgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAP7/AAAFAQIAAAAAAAAAAAAAAAAAAAAAAAEAAADg hZ/y+U9oEKuRCAArJ7PZMAAAAIgBAAARAAAAAQAAAJAAAAACAAAAmAAAAAMAAACwAAAABAAAALwA AAAFAAAA1AAAAAYAAADgAAAABwAAAOwAAAAIAAAAAAEAAAkAAAAYAQAAEgAAACQBAAAKAAAARAEA AAwAAABQAQAADQAAAFwBAAAOAAAAaAEAAA8AAABwAQAAEAAAAHgBAAATAAAAgAEAAAIAAADkBAAA HgAAABAAAABDb2xsZWN0ZWQgZGF0YQAAHgAAAAQAAAAAAAAAHgAAABAAAABTdGFzIEtoaXJtYW4A AAAAHgAAAAQAAAAAAAAAHgAAAAQAAAAAAAAAHgAAAAwAAABOb3JtYWwuZG90AAAeAAAAEAAAAFN0 YXMgS2hpcm1hbgAAAAAeAAAABAAAADYAAAAeAAAAGAAAAE1pY3Jvc29mdCBPZmZpY2UgV29yZAAA AEAAAAAASLMzSQAAAEAAAAAABAcFuwDJAUAAAAAAxl+NCAHJAQMAAAAEAAAAAwAAAMMDAAADAAAA 9RIAAAMAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAD+/wAABQECAAAAAAAAAAAAAAAAAAAAAAABAAAAAtXN1ZwuGxCT lwgAKyz5rjAAAAAIAQAADAAAAAEAAABoAAAADwAAAHAAAAAFAAAAjAAAAAYAAACUAAAAEQAAAJwA AAAXAAAApAAAAAsAAACsAAAAEAAAALQAAAATAAAAvAAAABYAAADEAAAADQAAAMwAAAAMAAAA5wAA AAIAAADkBAAAHgAAABQAAABLaGlybWFuICYgU29uLCBMTEMAAAMAAADXAQAAAwAAAJ8BAAADAAAA fhUAAAMAAAAPJwsACwAAAAAAAAALAAAAAAAAAAsAAAAAAAAACwAAAAAAAAAeEAAAAQAAAA8AAABD b2xsZWN0ZWQgZGF0YQAMEAAAAgAAAB4AAAAGAAAAVGl0bGUAAwAAAAEAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAQAAAAIAAAADAAAABAAAAAUAAAAGAAAABwAAAAgAAAAJAAAACgAAAAsAAAAM AAAADQAAAA4AAAAPAAAAEAAAABEAAAASAAAAEwAAABQAAAAVAAAAFgAAABcAAAAYAAAAGQAAABoA AAAbAAAAHAAAAB0AAAAeAAAAHwAAACAAAAAhAAAAIgAAACMAAAAkAAAAJQAAACYAAAAnAAAAKAAA ACkAAAAqAAAAKwAAACwAAAAtAAAALgAAAC8AAAAwAAAAMQAAADIAAAAzAAAANAAAADUAAAA2AAAA NwAAADgAAAA5AAAAOgAAADsAAAA8AAAAPQAAAD4AAAA/AAAAQAAAAEEAAABCAAAAQwAAAEQAAABF AAAARgAAAEcAAABIAAAASQAAAEoAAABLAAAATAAAAE0AAABOAAAATwAAAFAAAABRAAAAUgAAAFMA AABUAAAAVQAAAFYAAABXAAAAWAAAAFkAAABaAAAAWwAAAFwAAABdAAAAXgAAAF8AAABgAAAAYQAA AGIAAABjAAAAZAAAAGUAAABmAAAAZwAAAGgAAABpAAAAagAAAGsAAABsAAAAbQAAAG4AAABvAAAA cAAAAHEAAAByAAAAcwAAAHQAAAB1AAAAdgAAAHcAAAB4AAAAeQAAAHoAAAB7AAAAfAAAAP7///9+ AAAAfwAAAIAAAACBAAAAggAAAIMAAACEAAAAhQAAAIYAAACHAAAAiAAAAIkAAACKAAAAiwAAAIwA AACNAAAAjgAAAI8AAACQAAAAkQAAAJIAAACTAAAAlAAAAJUAAACWAAAAlwAAAJgAAACZAAAAmgAA AJsAAACcAAAAnQAAAJ4AAACfAAAAoAAAAKEAAACiAAAAowAAAKQAAAClAAAApgAAAKcAAACoAAAA qQAAAKoAAACrAAAArAAAAK0AAACuAAAArwAAALAAAACxAAAAsgAAALMAAAC0AAAAtQAAALYAAAC3 AAAAuAAAALkAAAC6AAAAuwAAALwAAAC9AAAAvgAAAL8AAADAAAAAwQAAAMIAAADDAAAAxAAAAMUA AADGAAAAxwAAAMgAAADJAAAAygAAAMsAAADMAAAAzQAAAM4AAADPAAAA0AAAANEAAADSAAAA0wAA ANQAAADVAAAA1gAAANcAAADYAAAA2QAAANoAAADbAAAA3AAAAN0AAADeAAAA3wAAAOAAAAD+//// 4gAAAOMAAADkAAAA5QAAAOYAAADnAAAA6AAAAOkAAADqAAAA6wAAAOwAAADtAAAA7gAAAO8AAADw AAAA8QAAAPIAAADzAAAA9AAAAPUAAAD2AAAA9wAAAPgAAAD5AAAA+gAAAPsAAAD8AAAA/QAAAP4A AAD/AAAAAAEAAAEBAAACAQAAAwEAAAQBAAAFAQAABgEAAAcBAAAIAQAACQEAAAoBAAALAQAADAEA AA0BAAAOAQAADwEAABABAAARAQAAEgEAABMBAAAUAQAAFQEAABYBAAAXAQAAGAEAABkBAAAaAQAA GwEAABwBAAAdAQAAHgEAAB8BAAAgAQAAIQEAACIBAAAjAQAAJAEAACUBAAAmAQAAJwEAACgBAAAp AQAAKgEAACsBAAAsAQAALQEAAC4BAAAvAQAAMAEAADEBAAAyAQAAMwEAADQBAAA1AQAANgEAADcB AAA4AQAA/v///zoBAAA7AQAAPAEAAD0BAAA+AQAAPwEAAEABAAD+////QgEAAEMBAABEAQAARQEA AEYBAABHAQAASAEAAP7////9/////f////3///9NAQAA/v////7////+//////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// ////////////UgBvAG8AdAAgAEUAbgB0AHIAeQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAABYABQH//////////wMAAAAGCQIAAAAAAMAAAAAAAABGAAAAAAAAAAAA AAAAAKOKrQgByQFPAQAAgAAAAAAAAABEAGEAdABhAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACgACAf///////////////wAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAH0AAAA/xgAAAAAAADEAVABhAGIAbABlAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAOAAIBAQAAAAYAAAD/ ////AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA4QAAAEGuAAAAAAAAVwBvAHIA ZABEAG8AYwB1AG0AZQBuAHQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA ABoAAgECAAAABQAAAP////8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA LvgAAAAAAAAFAFMAdQBtAG0AYQByAHkASQBuAGYAbwByAG0AYQB0AGkAbwBuAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAKAACAf///////////////wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAADkBAAAAEAAAAAAAAAUARABvAGMAdQBtAGUAbgB0AFMAdQBtAG0AYQByAHkASQBu AGYAbwByAG0AYQB0AGkAbwBuAAAAAAAAAAAAAAA4AAIBBAAAAP//////////AAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAQQEAAAAQAAAAAAAAAQBDAG8AbQBwAE8AYgBqAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABIAAgD///////////// //8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAcQAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAP///////////////wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAEAAAD+//////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// ////////AQD+/wMKAAD/////BgkCAAAAAADAAAAAAAAARh8AAABNaWNyb3NvZnQgT2ZmaWNlIFdv cmQgRG9jdW1lbnQACgAAAE1TV29yZERvYwAQAAAAV29yZC5Eb2N1bWVudC44APQ5snEAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAA= ------=_NextPart_000_0047_01C900CE.D7ECC090 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 ------=_NextPart_000_0047_01C900CE.D7ECC090-- From p2pi-bounces@ietf.org Mon Aug 18 02:44: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 566E43A6800; Mon, 18 Aug 2008 02:44: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 BA60B3A65A5 for ; Mon, 18 Aug 2008 02:44:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.298 X-Spam-Level: X-Spam-Status: No, score=-2.298 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_63=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 osEfVFlOTTtT for ; Mon, 18 Aug 2008 02:44:01 -0700 (PDT) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.225]) by core3.amsl.com (Postfix) with ESMTP id C86E83A6800 for ; Mon, 18 Aug 2008 02:44:01 -0700 (PDT) Received: by rv-out-0506.google.com with SMTP id b25so1597150rvf.49 for ; Mon, 18 Aug 2008 02:43:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type:references; bh=wvBBDxb03oFC3AFXcbG1bbImgZlm3XE8mE52CxYJTyg=; b=rKhT5if3ZEIz/tqVyfUnpB3qYbDeKlyB/8MOdHilJ4rHjgTxCqpnHk9n/EEca0g1lQ oNBGt3HQlZb0FooeQSHGCu/C3SuzwJ1c3H4hOiX5FWY6eyl5NgLuAx/jKzJehShZRNWQ VmzmWcYSUVMdihtxqqv0vMnaY9/FPHMYrNdyc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:references; b=Ud6WKTJV4bXwYPih3QMy1wkeXmziC7VqEWYDHGZjDaF/DS437Wl8/HS66PAfnBouHQ mSjBh0O2AITk8QzlKMpn2lCihvniC2jr48R0Oo1lJE41ayyS/Wv/s3M5yUuWn8JXMXk7 5OoiCk6Ea/OFsyb+yZdj0Cu3/UnBkQ4iVrd8Y= Received: by 10.141.49.6 with SMTP id b6mr3071643rvk.89.1219052604519; Mon, 18 Aug 2008 02:43:24 -0700 (PDT) Received: by 10.141.33.6 with HTTP; Mon, 18 Aug 2008 02:43:24 -0700 (PDT) Message-ID: Date: Mon, 18 Aug 2008 17:43:24 +0800 From: "Hao Chen" To: "Stas Khirman" In-Reply-To: <004601c90109$844b9890$6500a8c0@viceroy> MIME-Version: 1.0 References: <004601c90109$844b9890$6500a8c0@viceroy> Cc: p2pi@ietf.org, p4pwg@yahoogroups.com Subject: Re: [p2pi] Real life torrent statistics X-BeenThere: p2pi@ietf.org X-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="===============0421538333==" Sender: p2pi-bounces@ietf.org Errors-To: p2pi-bounces@ietf.org --===============0421538333== Content-Type: multipart/alternative; boundary="----=_Part_162675_212201.1219052604520" ------=_Part_162675_212201.1219052604520 Content-Type: text/plain; charset=WINDOWS-1252 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline How many ASes does the overlay span totally? It seems the hotspot effect is not very obvious as compared to previous study. What about cluster effect o= f overlay by which I mean the ratio of neighbors of the peer in the same AS o= r ISP? 2008/8/18 Stas Khirman > To estimate a feasibility of ALTO/P4P for real life torrents , I > collected information for peers from one of the most popular > "PirateBay" torrents ( almost 20k peers) and maped their IPs to correspon= ded > ASs. Please find attached my working notes with some interesting statisti= cs. > > > > In short =96 for such kind of swarm (20k peers), almost half of peers bel= ong > to ASs with 100 or more peers, almost 2/3 of peers belong to ASs with 50 = or > more peers. Less then 15% of peers belong to ASs with 10 or less > "neighbors". > > > > US broadband ISPs (Road Runner, Comcast, AT&T) have about 2-3% of total > peers each. > > > > Also, I find it surprising geo distribution of the peers =96 majority wer= e in > UK , not in US (probably because content is available in US theaters). > Places 3-5 taken by Sweden, Poland and Canada (in total =96 more peers t= hen > in US). > > > > Certainly, observed "heavy" neighboring of peers is a function of swarm > size. I intend to investigate a few medium/small size swarms to have a > multi-point picture for any future discussions. > > > > I would appreciate comments, corrections and additional ideas on data > collection and analysis. > > _______________________________________________ > p2pi mailing list > p2pi@ietf.org > https://www.ietf.org/mailman/listinfo/p2pi > > --=20 Cheers,Hao Fudan University ------=_Part_162675_212201.1219052604520 Content-Type: text/html; charset=WINDOWS-1252 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline
How many ASes does the overlay span totally? It seems the = hotspot effect is not very obvious as compared to previous study. What abou= t cluster effect of overlay by which I mean the ratio of neighbors of the p= eer in the same AS or ISP?
2008/8/18 Stas Khirman <stas@khirman.com>

To estimate a feasibility of ALTO/P4P for real life torrents , I collected <ip,port> information for peers from one of the most popular "PirateBay" torrents ( almost 20k peers) and maped their IPs to corresponded ASs. Please find attached my working notes with some interesting statistics.

 

In short =96 for such kind of swarm (20k peers), almost half of peers belong to ASs with 100 or more peers, almost 2/3 of peers bel= ong to ASs with 50 or more peers. Less then 15% of peers belong to ASs with 10 = or less "neighbors".

 

US broadband ISPs (Road Runner, Comcast, AT&T) have about 2-3% of total peers each.

 

Also, I find it surprising geo distribution of the peers =96 majority were in UK , not in US (probably because content is available in US theaters).  P= laces 3-5 taken by Sweden, Poland and Canada (in total =96 more peers then in US).

 

Certainly, observed "heavy" neighboring of peers is a function of swarm size. I intend to investigate a few medium/small siz= e swarms to have a multi-point picture for any future discussions.

 

I would appreciate comments, corrections and additional ideas on data collection and analysis.


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




--
Cheers,Hao

F= udan University
------=_Part_162675_212201.1219052604520-- --===============0421538333== 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 --===============0421538333==-- From p2pi-bounces@ietf.org Mon Aug 18 07:49:36 2008 Return-Path: X-Original-To: p2pi-archive@ietf.org Delivered-To: ietfarch-p2pi-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D8D4628C195; Mon, 18 Aug 2008 07:49: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 8A8EB28C14C for ; Mon, 18 Aug 2008 07:49:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.002 X-Spam-Level: X-Spam-Status: No, score=0.002 tagged_above=-999 required=5 tests=[BAYES_50=0.001, UNPARSEABLE_RELAY=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 Mxoq1bTl334y for ; Mon, 18 Aug 2008 07:49:33 -0700 (PDT) Received: from nikolai.ifi.uzh.ch (nikolai.ifi.uzh.ch [130.60.155.10]) by core3.amsl.com (Postfix) with ESMTP id 0CC2028C1A2 for ; Mon, 18 Aug 2008 07:49:28 -0700 (PDT) Received: from authenticated sender hecht by nikolai.ifi.uzh.ch (postfix) with ESMTP id 068C02A6B33; Mon, 18 Aug 2008 16:49:29 +0200 (CEST) From: Fabio Hecht To: Vinay Aggarwal In-Reply-To: <20080811165443.GB18911@net.t-labs.tu-berlin.de> References: <489B498B.4040804@telecomitalia.it> <20080811143531.GA18911@net.t-labs.tu-berlin.de> <20080811165443.GB18911@net.t-labs.tu-berlin.de> Organization: =?ISO-8859-1?Q?Universit=E4t?= =?ISO-8859-1?Q?_Z=FCrich?= Date: Mon, 18 Aug 2008 16:49:29 +0200 Message-Id: <1219070969.6961.37.camel@bart2> Mime-Version: 1.0 X-Mailer: Evolution 2.22.3.1 X-Virus-Scanned: ClamAV 0.93.1/8053/Mon Aug 18 14:42:12 2008 on nikolai.ifi.uzh.ch X-Virus-Status: Clean Cc: "p2pi@ietf.org" Subject: Re: [p2pi] Information in an ALTO protocol X-BeenThere: p2pi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: P2P Infrastructure Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Sender: p2pi-bounces@ietf.org Errors-To: p2pi-bounces@ietf.org SGVsbG8sCgppbiB0aGlzIGNhc2UsIHdvdWxkIGFuIEFMVE8gU2VydmVyIHF1ZXJ5IG90aGVyIEFM VE8gU2VydmVycyB0byBnYXRoZXIKdGhpcyBpbmZvcm1hdGlvbj8gQmVjYXVzZSwgZnJvbSBhbiBJ U1AgcG9pbnQgb2YgdmlldywgdGhlIEFMVE8gU2VydmVyCndvdWxkIG5vdCBrbm93IHdoYXQgdGhl IGxhc3QtaG9wIGJhbmR3aWR0aCBpcyBmb3IgZXZlcnkgb3RoZXIgcGVlci4KV291bGQgdGhlIHBy b3RvY29sIHRoZW4gYmUgdGhlIHNhbWUgdXNlZCBieSB0aGUgb3ZlcmxheSBhcHBsaWNhdGlvbnM/ CgpSZWdhcmRzCgpGYWJpbwoKT24gTW9uLCAyMDA4LTA4LTExIGF0IDE4OjU0ICswMjAwLCBWaW5h eSBBZ2dhcndhbCB3cm90ZToKPiBIaSwKPiAKPiByZWdhcmRpbmcgYmFuZHdpZHRoIGluZm9ybWF0 aW9uLAo+IGhlcmUgaXMgYSBwYXBlciB0aGF0IHNob3dzIHRoYXQgdGFraW5nIGxhc3QtaG9wIGJh bmR3aWR0aCBpbnRvIGFjY291bnQKPiBoZWxwcyB0byBpbXByb3ZlIHRoZSBkb3dubG9hZCBwZXJm b3JtYW5jZSBvZiBwZWVycy4gSW4gZmFjdCwgYmFuZHdpZHRoCj4gY29tZXMgb3V0IHRvIGJlIHRo ZSBzaWduaWZpY2FudCBmYWN0b3IgdG8gaW1wcm92ZSBkb3dubG9hZCB0aW1lcy4KPiAKPiBWaW5h eSBBZ2dhcndhbCwgT2JpIEFrb25qYW5nLCBBbmphIEZlbGRtYW5uLiBJbXByb3ZpbmcgVXNlciBh bmQgSVNQCj4gRXhwZXJpZW5jZSB0aHJvdWdoIElTUC1haWRlZCBQMlAgTG9jYWxpdHkuIEluIFBy b2NlZWRpbmdzIG9mIDExdGggSUVFRQo+IEdsb2JhbCBJbnRlcm5ldCBTeW1wb3NpdW0gMjAwOCAo R0knMDgpCj4gCj4gVGhlIHBhcGVyIChhbmQgb3RoZXIgcmVsYXRlZCBwYXBlcnMpIGFyZSBhdmFp bGFibGUgYXQ6Cj4gaHR0cDovL3d3dy5uZXQudC1sYWJzLnR1LWJlcmxpbi5kZS9yZXNlYXJjaC9p c3AtcDJwLwo+IAo+IEl0IHdvdWxkIG1ha2Ugc2Vuc2UgdG8gcHJvdmlkZSBpbmZvcm1hdGlvbiBh Ym91dCB0aGUgInVwbGluayIgYmFuZHdpZHRoLAo+IGFzIHRoYXQgaXMgbXVjaCBzbWFsbGVyIHRo YW4gImRvd25saW5rIiBiYW5kd2lkdGgsIGF0bGVhc3QgaW4gY2FzZSBvZiBEU0wsCj4gYW5kIGlz IHRodXMgYSBsaW1pdGluZyBmYWN0b3IuCj4gCj4gVGhlIEFMVE8gY2FuIGNvbnNpZGVyIHRoZSB1 cGxpbmsgYmFuZHdpZHRoIG9mIHBlZXJzLCBhbmQgdXNlIGl0IGluCj4gY29tYmluYXRpb24gd2l0 aCBnZW9ncmFwaGljIG9yIHBhcmVudCBBUyBpbmZvcm1hdGlvbiB0byBzb3J0IHRoZSBwZWVycy4K PiAKPiBJIGFncmVlIHRoYXQgc29tZSBJU1BzIHByZWZlciB0byBrZWVwIHRyYWZmaWMgd2l0aGlu IHRoZWlyIG5ldHdvcmssCj4gd2hpbGUgb3RoZXIgSVNQcyB3b3VsZCBzb21ldGltZXMgd2VsY29t ZSB0cmFmZmljIGdvaW5nIHRvIG90aGVyIElTUHMuCj4gVGhpcyBpcyBlc3BlY2lhbGx5IHRydWUg Zm9yIGxhcmdlIElTUHMsIHdobyBnZXQgcGFpZCBmb3IgdHJhZmZpYyBmbG93aW5nCj4gdG8gb3Ro ZXIgbmV0d29ya3MsIHR5cGljYWxseSB0aGVpciBjdXN0b21lcnMuIAo+IAo+IERlcGVuZGluZyBv biB0aGUgY2lyY3Vtc3RhbmNlcywgYW4gSVNQIGNhbiBwcmVmZXIgcGVlcnMgZWl0aGVyIHdpdGgK PiBsYXJnZSB1cGxpbmsgb3IgdGhvc2Ugd2l0aGluIGl0cyBuZXR3b3JrLCBvciBiZXR0ZXIgc3Rp bGwsIGJvdGghCj4gSW1wb3J0YW50IGlzIHRoYXQgdGhlIHVzZXIgc2hvdWxkIGV4cGVyaWVuY2Ug aW1wcm92ZWQgcGVyZm9ybWFuY2UuIAo+IAo+IElNSE8sIGNvbnNpZGVyaW5nIGp1c3QgdGhlIGFj dHVhbCB1cGxpbmsgYmFuZHdpZHRoIHdpbGwgaGVscCBhIGdyZWF0Cj4gZGVhbC4gV2hpbGUgZXN0 aW1hdGluZyB0aGUgY3VycmVudGx5ICJhdmFpbGFibGUiIGJhbmR3aWR0aCB3b3VsZCBiZQo+IHN0 aWxsIGJldHRlciwgdGhhdCBpcyBhIGxvdCBoYXJkZXIgdG8gYWNoaWV2ZS4gQnV0IGlmIHRoYXQg aXMgcmVhc29uYWJseQo+IHBvc3NpYmxlIHRvIGRvIGZvciB0aGUgQUxUTyBzZXJ2ZXIsIHRoYXQg aXMgYSBtdWNoIGJldHRlciBhbHRlcm5hdGl2ZQo+IHRoYW4gaGF2aW5nIHRoZSBwZWVyIHByb2Jp bmcgZm9yIHRoZSByZWFsIGF2YWlsYWJsZSBiYW5kd2lkdGggYW5kCj4gcGlja2luZyB0aGUgYmVz dCBvbmUuCj4gCj4gVmluYXkuCj4gCj4gCgotLSAKRmFiaW8gSGVjaHQKClVuaXZlcnNpdHkgb2Yg WnVyaWNoIC0gRGVwYXJ0bWVudCBvZiBJbmZvcm1hdGljcyAoSWZJKQpCaW56bcO8aGxlc3RyYXNz ZSAxNCBDSC04MDUwIFrDvHJpY2gsIFN3aXR6ZXJsYW5kClBoLjogKzQxIDQ0IDYzNTcxMjkgLyA2 MzUwODkyICBGYXg6ICs0MSA0NCA2MzU2ODA5ClZvSVAgc2lwOmhlY2h0QGlmaS51emguY2gKCl9f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fCnAycGkgbWFpbGlu ZyBsaXN0CnAycGlAaWV0Zi5vcmcKaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5m by9wMnBpCg== From p2pi-bounces@ietf.org Mon Aug 18 11:01:03 2008 Return-Path: X-Original-To: p2pi-archive@ietf.org Delivered-To: ietfarch-p2pi-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C9D3E3A6D59; Mon, 18 Aug 2008 11:01:03 -0700 (PDT) X-Original-To: p2pi@core3.amsl.com Delivered-To: p2pi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2FFDA3A6D59 for ; Mon, 18 Aug 2008 11:01:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.602 X-Spam-Level: X-Spam-Status: No, score=0.602 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HTML_MESSAGE=0.001, J_CHICKENPOX_63=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 4vbbZ648LUBZ for ; Mon, 18 Aug 2008 11:00:54 -0700 (PDT) Received: from mout.perfora.net (mout.perfora.net [74.208.4.197]) by core3.amsl.com (Postfix) with ESMTP id 011653A6A95 for ; Mon, 18 Aug 2008 11:00:54 -0700 (PDT) Received: from viceroy (adsl-69-228-190-230.dsl.snfc21.pacbell.net [69.228.190.230]) by mrelay.perfora.net (node=mrus1) with ESMTP (Nemesis) id 0MKpCa-1KV9292o9c-0005Iw; Mon, 18 Aug 2008 14:00:53 -0400 From: "Stas Khirman" To: "'Hao Chen'" References: <004601c90109$844b9890$6500a8c0@viceroy> Date: Mon, 18 Aug 2008 11:00:48 -0700 Message-ID: <00ff01c9015c$5aede950$6500a8c0@viceroy> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 Thread-Index: AckBFtwUid1CUVXvTjaokMj/8r31rQARF1Bw In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 X-Provags-ID: V01U2FsdGVkX1+G9JiMR7I9ZX2+gISizz36YxqScx9oFj4NRIi Qhke9K5dAL2/LDiejUEtkUtPjn8fA5AV/g3Njs1c9O5H7qKUgv pkmfhfOoM2l2H30stRkZg== Cc: p2pi@ietf.org, p4pwg@yahoogroups.com Subject: Re: [p2pi] Real life torrent statistics X-BeenThere: p2pi@ietf.org X-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="===============0650433778==" Sender: p2pi-bounces@ietf.org Errors-To: p2pi-bounces@ietf.org This is a multi-part message in MIME format. --===============0650433778== Content-Type: multipart/alternative; boundary="----=_NextPart_000_0100_01C90121.AE8F1150" This is a multi-part message in MIME format. ------=_NextPart_000_0100_01C90121.AE8F1150 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sorry that I missed this number in my notes . The dataset includes 19333 unique pairs ( some IPs are repeatable) from 1459 ASs. Or 13.25 peers/AS in average. While aggregated by "ISP name", I got 1368 unique ISP names ( not very accurate estimation by second part of AS name) or 14.1 peers per "ISP" _____ From: Hao Chen [mailto:chsoft@gmail.com] Sent: Monday, August 18, 2008 2:43 AM To: Stas Khirman Cc: p2pi@ietf.org; p4pwg@yahoogroups.com Subject: Re: [p2pi] Real life torrent statistics How many ASes does the overlay span totally? It seems the hotspot effect is not very obvious as compared to previous study. What about cluster effect of overlay by which I mean the ratio of neighbors of the peer in the same AS or ISP? 2008/8/18 Stas Khirman To estimate a feasibility of ALTO/P4P for real life torrents , I collected information for peers from one of the most popular "PirateBay" torrents ( almost 20k peers) and maped their IPs to corresponded ASs. Please find attached my working notes with some interesting statistics. In short - for such kind of swarm (20k peers), almost half of peers belong to ASs with 100 or more peers, almost 2/3 of peers belong to ASs with 50 or more peers. Less then 15% of peers belong to ASs with 10 or less "neighbors". US broadband ISPs (Road Runner, Comcast, AT&T) have about 2-3% of total peers each. Also, I find it surprising geo distribution of the peers - majority were in UK , not in US (probably because content is available in US theaters). Places 3-5 taken by Sweden, Poland and Canada (in total - more peers then in US). Certainly, observed "heavy" neighboring of peers is a function of swarm size. I intend to investigate a few medium/small size swarms to have a multi-point picture for any future discussions. I would appreciate comments, corrections and additional ideas on data collection and analysis. _______________________________________________ p2pi mailing list p2pi@ietf.org https://www.ietf.org/mailman/listinfo/p2pi -- Cheers,Hao Fudan University ------=_NextPart_000_0100_01C90121.AE8F1150 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Sorry that I missed this number in = my notes .

 

The dataset includes 19333 unique <ip,port> pairs ( some IPs are repeatable) from 1459 ASs. Or 13.25 peers/AS in average.

 

While aggregated by “ISP = name”, I got 1368 unique ISP names ( not very accurate estimation by second part of AS = name) or 14.1 peers per “ISP”

 

From: Hao = Chen [mailto:chsoft@gmail.com]
Sent: Monday, August 18, = 2008 2:43 AM
To: Stas Khirman
Cc: p2pi@ietf.org; p4pwg@yahoogroups.com
Subject: Re: [p2pi] Real = life torrent statistics

 

How many ASes does the overlay span totally? It seems the = hotspot effect is not very obvious as compared to previous study. What about = cluster effect of overlay by which I mean the ratio of neighbors of the peer in = the same AS or ISP?

2008/8/18 Stas Khirman <stas@khirman.com>

To estimate a feasibility of ALTO/P4P for real life torrents , I collected <ip,port> information for peers from one of the most popular "PirateBay" torrents ( almost 20k peers) and maped their IPs = to corresponded ASs. Please find attached my working notes with some = interesting statistics.

 

In short – for such kind of swarm (20k peers), almost half of peers = belong to ASs with 100 or more peers, almost 2/3 of peers belong to ASs with 50 or = more peers. Less then 15% of peers belong to ASs with 10 or less "neighbors".

 

US broadband ISPs (Road Runner, Comcast, AT&T) have about 2-3% of total = peers each.

 

Also, I find it surprising geo distribution of the peers – majority were = in UK , = not in US (probably because content is available in US theaters).  Places 3-5 = taken by Sweden, = Poland and Canada (in total – = more peers then in US).

 

Certainly, observed "heavy" neighboring of peers is a function of swarm = size. I intend to investigate a few medium/small size swarms to have a = multi-point picture for any future discussions.

 

I would appreciate comments, corrections and additional ideas on data = collection and analysis.


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




--
Cheers,Hao

Fudan = University

------=_NextPart_000_0100_01C90121.AE8F1150-- --===============0650433778== 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 --===============0650433778==-- From p2pi-bounces@ietf.org Mon Aug 18 12:02:50 2008 Return-Path: X-Original-To: p2pi-archive@ietf.org Delivered-To: ietfarch-p2pi-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E454F28C1E5; Mon, 18 Aug 2008 12:02:50 -0700 (PDT) X-Original-To: p2pi@core3.amsl.com Delivered-To: p2pi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F096D3A67C0 for ; Mon, 18 Aug 2008 11:55:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.111 X-Spam-Level: * X-Spam-Status: No, score=1.111 tagged_above=-999 required=5 tests=[AWL=1.110, 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 YG3VhtsRljN6 for ; Mon, 18 Aug 2008 11:55:23 -0700 (PDT) Received: from n65.bullet.mail.sp1.yahoo.com (n65.bullet.mail.sp1.yahoo.com [98.136.44.190]) by core3.amsl.com (Postfix) with SMTP id 5A5493A6AE6 for ; Mon, 18 Aug 2008 11:55:23 -0700 (PDT) Received: from [216.252.122.217] by n65.bullet.mail.sp1.yahoo.com with NNFMP; 18 Aug 2008 18:55:12 -0000 Received: from [69.147.65.156] by t2.bullet.sp1.yahoo.com with NNFMP; 18 Aug 2008 18:55:12 -0000 Received: from [127.0.0.1] by omp404.mail.sp1.yahoo.com with NNFMP; 18 Aug 2008 18:55:11 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 965589.32872.bm@omp404.mail.sp1.yahoo.com Received: (qmail 8174 invoked by uid 60001); 18 Aug 2008 18:55:09 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Received:X-Mailer:Date:From:Reply-To:Subject:To:Cc:MIME-Version:Content-Type:Content-Transfer-Encoding:Message-ID; b=GOwLG+LKRrB4DAos1wN6+W9sOfsm17UsEfbEZjF/jQr9PR2IaNUrwPL118/NvVqcaBQpRRJi1BboEdSxuAImGPF7rfb5lSpyoiIPra7VFP+qUaZIYHk4yWOHorgY2vvZPazYq53O9aj/QoOPP6PIemmOzq9udrqqtAx8Nxpc1RY=; Received: from [135.245.10.3] by web46212.mail.sp1.yahoo.com via HTTP; Mon, 18 Aug 2008 11:55:09 PDT X-Mailer: YahooMailWebService/0.7.218 Date: Mon, 18 Aug 2008 11:55:09 -0700 (PDT) From: Victor Semanic To: stas@khirman.com MIME-Version: 1.0 Message-ID: <687558.6112.qm@web46212.mail.sp1.yahoo.com> Cc: p2pi@ietf.org Subject: Re: [p2pi] Real life torrent statistics X-BeenThere: p2pi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: vsemanic@yahoo.com List-Id: P2P Infrastructure Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Sender: p2pi-bounces@ietf.org Errors-To: p2pi-bounces@ietf.org RGVhciBEci4gS2hpcm1hbjoKCllvdSB3cml0ZToKPiBUaGUgZGF0YXNldCBpbmNsdWRlcyAxOTMz MyB1bmlxdWUgPGlwLHBvcnQ+IHBhaXJzIChzb21lIElQcyBhcmUgCj4gcmVwZWF0YWJsZSkgZnJv bSAxNDU5IEFTcy4gIE9yIDEzLjI1IHBlZXJzL0FTIGluIGF2ZXJhZ2UuCj4gV2hpbGUgYWdncmVn YXRlZCBieSDigJxJU1AgbmFtZeKAnSwgSSBnb3QgMTM2OCB1bmlxdWUgSVNQIG5hbWVzIChub3Qg dmVyeSAKPiBhY2N1cmF0ZSBlc3RpbWF0aW9uIGJ5IHNlY29uZCBwYXJ0IG9mIEFTIG5hbWUpIG9y IDE0LjEgcGVlcnMgcGVyIOKAnElTUOKAnQoKQ2FuIHlvdSBraW5kbHkgcHJvdmlkZSBzb21lIG1v cmUgaW5mb3JtYXRpb24gb24gdGhlIHNwcmVhZD8gIFRoYXQgaXMsIHdoYXQgCndhcyB0aGUgc3Rh bmRhcmQgZGV2aWF0aW9uIGFuZCBtZWRpYW4gZm9yIHRoZSBwZWVycy9BUy4gIEkgbm90ZSBmcm9t IHlvdXIgCm9yaWdpbmFsIGVtYWlsIHRoYXQgdGhlIDIwIG1vc3QgcG9wdWxhciBBU3MgYWNjb3Vu dCBmb3IgYWJvdXQgMzUlIG9mIHRoZSAKdG90YWwgQVNzLiAgVGhlIGxhc3QgQVMgbGlzdGVkIGlu IHlvdXIgdGFibGUgaGFkIDAuOSUgb2YgdGhlIHRvdGFsLCBzbyBJIApzdXNwZWN0IHRoYXQgYXMg dGhlIEFTIGxpc3QgaW5jcmVhc2VzIHRoZXJlIGFyZSBzdWNjZXNzaXZlbHkgbGVzcyAKcGVyY2Vu dGFnZSBvZiBwZWVycyBpbiB0aGVtLiAgQXMgc3VjaCwgSSB3aWxsIGxpa2UgdG8gcHV0IGluIHBy ZXNwZWN0aXZlCnRoZSAxMy4yNSBwZWVycy9BUyBhdmVyYWdlIGluIGxpZ2h0IG9mIHRoZSAyMCBt b3N0IHBvcHVsYXIgQVNlcy4KClRoYW5rIHlvdSBpbiBhZHZhbmNlIGZvciB5b3VyIHRpbWUuCgoK ICAgICAgCgpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwpw MnBpIG1haWxpbmcgbGlzdApwMnBpQGlldGYub3JnCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxt YW4vbGlzdGluZm8vcDJwaQo= From p2pi-bounces@ietf.org Mon Aug 18 19:50:45 2008 Return-Path: X-Original-To: p2pi-archive@ietf.org Delivered-To: ietfarch-p2pi-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3E0483A6A00; Mon, 18 Aug 2008 19:50:45 -0700 (PDT) X-Original-To: p2pi@core3.amsl.com Delivered-To: p2pi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EF0EE3A682C for ; Mon, 18 Aug 2008 19:50:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.04 X-Spam-Level: X-Spam-Status: No, score=-0.04 tagged_above=-999 required=5 tests=[AWL=0.455, 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 3WylPl6n6DxL for ; Mon, 18 Aug 2008 19:50:43 -0700 (PDT) Received: from szxga02-in.huawei.com (unknown [119.145.14.65]) by core3.amsl.com (Postfix) with ESMTP id F40A73A6A00 for ; Mon, 18 Aug 2008 19:50:42 -0700 (PDT) Received: from huawei.com (szxga02-in [172.24.2.6]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0K5T00FJPUKF8U@szxga02-in.huawei.com> for p2pi@ietf.org; Tue, 19 Aug 2008 10:50:40 +0800 (CST) Received: from huawei.com ([172.24.1.18]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0K5T002PIUKFIM@szxga02-in.huawei.com> for p2pi@ietf.org; Tue, 19 Aug 2008 10:50:39 +0800 (CST) Received: from s64081 ([10.164.9.178]) by szxml03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0K5T005MHUKFRL@szxml03-in.huawei.com> for p2pi@ietf.org; Tue, 19 Aug 2008 10:50:39 +0800 (CST) Date: Tue, 19 Aug 2008 10:50:33 +0800 From: Song Haibin In-reply-to: <687558.6112.qm@web46212.mail.sp1.yahoo.com> To: vsemanic@yahoo.com, stas@khirman.com Message-id: <005701c901a6$59ca5140$b209a40a@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: AckBZQhW8E1DZoQzRDGl+lKi6rp32gAP+ahw Cc: p2pi@ietf.org Subject: Re: [p2pi] Real life torrent statistics X-BeenThere: p2pi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: P2P Infrastructure Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: p2pi-bounces@ietf.org Errors-To: p2pi-bounces@ietf.org Stas, Thanks for the valuable information. I think if we can collect the connection information between peers, and draw a map with the information of distribution of the peers and their connections, then it will be of great help. However, perhaps the connection information may not be collected from the tracker. Best Regards, Song Haibin Email: melodysong@huawei.com Skype: alexsonghw >-----Original Message----- >From: p2pi-bounces@ietf.org [mailto:p2pi-bounces@ietf.org] On Behalf Of Victor >Semanic >Sent: Tuesday, August 19, 2008 2:55 AM >To: stas@khirman.com >Cc: p2pi@ietf.org >Subject: Re: [p2pi] Real life torrent statistics > >Dear Dr. Khirman: > >You write: >> The dataset includes 19333 unique pairs (some IPs are >> repeatable) from 1459 ASs. Or 13.25 peers/AS in average. >> While aggregated by "ISP name", I got 1368 unique ISP names (not very >> accurate estimation by second part of AS name) or 14.1 peers per "ISP" > >Can you kindly provide some more information on the spread? That is, what >was the standard deviation and median for the peers/AS. I note from your >original email that the 20 most popular ASs account for about 35% of the >total ASs. The last AS listed in your table had 0.9% of the total, so I >suspect that as the AS list increases there are successively less >percentage of peers in them. As such, I will like to put in prespective >the 13.25 peers/AS average in light of the 20 most popular ASes. > >Thank you in advance for your time. > > > > >_______________________________________________ >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 Aug 18 20:07: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 5F1003A6A6C; Mon, 18 Aug 2008 20:07: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 CB7FA3A6A6C for ; Mon, 18 Aug 2008 20:07:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.901 X-Spam-Level: X-Spam-Status: No, score=-5.901 tagged_above=-999 required=5 tests=[AWL=-0.699, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sPWYUVsnxg17 for ; Mon, 18 Aug 2008 20:07:01 -0700 (PDT) Received: from exprod7og107.obsmtp.com (exprod7og107.obsmtp.com [64.18.2.167]) by core3.amsl.com (Postfix) with ESMTP id 0F0C83A6A00 for ; Mon, 18 Aug 2008 20:06:58 -0700 (PDT) Received: from source ([66.129.228.6]) by exprod7ob107.postini.com ([64.18.6.12]) with SMTP; Mon, 18 Aug 2008 20:06:54 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, 18 Aug 2008 20:06:24 -0700 Received: from antipi.jnpr.net ([10.10.2.34]) by p-emlb01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Mon, 18 Aug 2008 20:06:23 -0700 Received: from proton.jnpr.net ([10.10.2.37]) by antipi.jnpr.net with Microsoft SMTPSVC(6.0.3790.1830); Mon, 18 Aug 2008 23:06:22 -0400 Received: from 172.23.1.57 ([172.23.1.57]) by proton.jnpr.net ([10.10.2.37]) with Microsoft Exchange Server HTTP-DAV ; Tue, 19 Aug 2008 03:06:22 +0000 User-Agent: Microsoft-Entourage/12.11.0.080522 Date: Mon, 18 Aug 2008 20:06:06 -0700 From: Reinaldo Penno To: Stas Khirman , , Message-ID: Thread-Topic: [p2pi] Real life torrent statistics Thread-Index: AckBCYHpAk/nXoimStKiXtQgM06R5wAnwNuj In-Reply-To: <004601c90109$844b9890$6500a8c0@viceroy> Mime-version: 1.0 X-OriginalArrivalTime: 19 Aug 2008 03:06:22.0921 (UTC) FILETIME=[8F6D5390:01C901A8] Subject: Re: [p2pi] Real life torrent statistics X-BeenThere: p2pi@ietf.org X-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="===============0147924388==" Sender: p2pi-bounces@ietf.org Errors-To: p2pi-bounces@ietf.org > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --===============0147924388== Content-type: multipart/alternative; boundary="B_3301934766_10687092" > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3301934766_10687092 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Hello Stas, It is refreshing to get real life data like this instead of some Linux distribution or small legal file that has little relevance. I was wondering what kind of info we can get from your data that shed light on ALTO discussions. One that caught my attention was that pure localization will probably adversely affect certain swarms (even huge ones like this), since you do not have enough peers in certain ASs. If the connectivity of the swarm is not good, getting certain pieces might be difficult even if the ones =B3around=B2 you can be downloaded lightening fast. I wonder what is the distribution of seeders vs. AS. I=B9m thinking certain ASs might have enough peers but maybe no seeders. This is also a tricky situation for optimization where the swarm are islands connected by relay peers. =20 It seems a lot of the bw savings ALTO can deliver is probably a cumulative effect over many torrents and many peers instead of just one. Thanks, Reinaldo On 8/18/08 1:07 AM, "Stas Khirman" wrote: > To estimate a feasibility of ALTO/P4P for real life torrents , I collecte= d > information for peers from one of the most popular =B3PirateBay=B2 > torrents ( almost 20k peers) and maped their IPs to corresponded ASs. Ple= ase > find attached my working notes with some interesting statistics. > =20 > In short =AD for such kind of swarm (20k peers), almost half of peers belon= g to > ASs with 100 or more peers, almost 2/3 of peers belong to ASs with 50 or = more > peers. Less then 15% of peers belong to ASs with 10 or less =B3neighbors=B2. > =20 > US broadband ISPs (Road Runner, Comcast, AT&T) have about 2-3% of total p= eers > each. > =20 > Also, I find it surprising geo distribution of the peers =AD majority were = in UK > , not in US (probably because content is available in US theaters). Plac= es > 3-5 taken by Sweden, Poland and Canada (in total =AD more peers then in US)= . > =20 > Certainly, observed =B3heavy=B2 neighboring of peers is a function of swarm s= ize. > I intend to investigate a few medium/small size swarms to have a multi-po= int > picture for any future discussions. > =20 > I would appreciate comments, corrections and additional ideas on data > collection and analysis. >=20 >=20 > _______________________________________________ > p2pi mailing list > p2pi@ietf.org > https://www.ietf.org/mailman/listinfo/p2pi --B_3301934766_10687092 Content-type: text/html; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Re: [p2pi] Real life torrent statistics Hello Stas,

It is refreshing to get real life data like this instead of some Linux dist= ribution or small legal file that has little relevance. I was wondering what= kind of info we can get from your data that shed light on ALTO discussions.= One that caught my attention was that pure localization will probably adver= sely affect certain swarms (even huge ones like this), since you do not have= enough peers in certain ASs.  If the connectivity of the swarm is not = good, getting certain pieces might be difficult even if the ones “arou= nd” you can be downloaded lightening fast.  

I wonder what is the distribution of seeders vs. AS.  I’m thinki= ng certain ASs might have enough peers but maybe no seeders. This is also a = tricky situation for optimization where the swarm are islands connected by r= elay peers.  

It seems a lot of the bw savings ALTO can deliver is probably a cumulative = effect over many torrents and many peers instead of just one.

Thanks,

Reinaldo


On 8/18/08 1:07 AM, "Stas Khirman" <stas@khirman.com> wrote:

To estimate a feasibility of ALTO/P4P for real life torrents ,= I collected <ip,port> information for peers from one of the most popu= lar “PirateBay” torrents ( almost 20k peers) and maped their IPs= to corresponded ASs. Please find attached my working notes with some intere= sting statistics.
 
In short – for such kind of swarm (20k peers), almost half of peers b= elong to ASs with 100 or more peers, almost 2/3 of peers belong to ASs with = 50 or more peers. Less then 15% of peers belong to ASs with 10 or less ̶= 0;neighbors”.
 
US broadband ISPs (Road Runner, Comcast, AT&T) have about 2-3% of total= peers each.
 
Also, I find it surprising geo distribution of the peers – majority w= ere in UK , not in US (probably because content is available in US theaters)= .  Places 3-5 taken by Sweden, Poland and Canada (in total – more= peers then in US).
 
Certainly, observed “heavy” neighboring of peers is a function = of swarm size. I intend to investigate a few medium/small size swarms to hav= e a multi-point picture for any future discussions.
 
I would appreciate comments, corrections and additional ideas on data colle= ction and analysis.

___________= ____________________________________
p2pi mailing list
p2pi@ietf.org
https://www.ietf.org/m= ailman/listinfo/p2pi
--B_3301934766_10687092-- --===============0147924388== 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 --===============0147924388==-- From p2pi-bounces@ietf.org Mon Aug 18 20:14: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 D94893A6990; Mon, 18 Aug 2008 20:14: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 3A7AD3A6990 for ; Mon, 18 Aug 2008 20:14:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.267 X-Spam-Level: X-Spam-Status: No, score=-0.267 tagged_above=-999 required=5 tests=[AWL=0.228, 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 aO87RgHxAikU for ; Mon, 18 Aug 2008 20:14:12 -0700 (PDT) Received: from szxga02-in.huawei.com (unknown [119.145.14.65]) by core3.amsl.com (Postfix) with ESMTP id 16ED73A6862 for ; Mon, 18 Aug 2008 20:14:12 -0700 (PDT) Received: from huawei.com (szxga02-in [172.24.2.6]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0K5T00FPHVNK8U@szxga02-in.huawei.com> for p2pi@ietf.org; Tue, 19 Aug 2008 11:14:09 +0800 (CST) Received: from huawei.com ([172.24.1.12]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0K5T004QBVNKN0@szxga02-in.huawei.com> for p2pi@ietf.org; Tue, 19 Aug 2008 11:14:08 +0800 (CST) Received: from s64081 ([10.164.9.178]) by szxml05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0K5T00M4IVNKQV@szxml05-in.huawei.com> for p2pi@ietf.org; Tue, 19 Aug 2008 11:14:08 +0800 (CST) Date: Tue, 19 Aug 2008 11:14:02 +0800 From: Song Haibin In-reply-to: <1219070969.6961.37.camel@bart2> To: 'Fabio Hecht' , 'Vinay Aggarwal' Message-id: <005e01c901a9$a19bc190$b209a40a@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: AckBQauVEEAAI6nPRNOXmACAjtLn2QAZnhRQ Cc: p2pi@ietf.org Subject: Re: [p2pi] Information in an ALTO protocol X-BeenThere: p2pi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: P2P Infrastructure Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: p2pi-bounces@ietf.org Errors-To: p2pi-bounces@ietf.org >From: p2pi-bounces@ietf.org [mailto:p2pi-bounces@ietf.org] On Behalf Of Fabio >Hecht >Sent: Monday, August 18, 2008 10:49 PM >To: Vinay Aggarwal > >Hello, > >in this case, would an ALTO Server query other ALTO Servers to gather >this information? Because, from an ISP point of view, the ALTO Server >would not know what the last-hop bandwidth is for every other peer. >Would the protocol then be the same used by the overlay applications? I don't think we need the queries between ALTO servers. The overlay application can have some way to determine which ALTO server it will query, and then gather all this swarm peers' information needed including last-hop bandwidth information. BR, Song Haibin >Regards > >Fabio > >On Mon, 2008-08-11 at 18:54 +0200, Vinay Aggarwal wrote: >> Hi, >> >> regarding bandwidth information, >> here is a paper that shows that taking last-hop bandwidth into account >> helps to improve the download performance of peers. In fact, bandwidth >> comes out to be the significant factor to improve download times. >> >> Vinay Aggarwal, Obi Akonjang, Anja Feldmann. Improving User and ISP >> Experience through ISP-aided P2P Locality. In Proceedings of 11th IEEE >> Global Internet Symposium 2008 (GI'08) >> >> The paper (and other related papers) are available at: >> http://www.net.t-labs.tu-berlin.de/research/isp-p2p/ >> >> It would make sense to provide information about the "uplink" bandwidth, >> as that is much smaller than "downlink" bandwidth, atleast in case of DSL, >> and is thus a limiting factor. >> >> The ALTO can consider the uplink bandwidth of peers, and use it in >> combination with geographic or parent AS information to sort the peers. >> >> I agree that some ISPs prefer to keep traffic within their network, >> while other ISPs would sometimes welcome traffic going to other ISPs. >> This is especially true for large ISPs, who get paid for traffic flowing >> to other networks, typically their customers. >> >> Depending on the circumstances, an ISP can prefer peers either with >> large uplink or those within its network, or better still, both! >> Important is that the user should experience improved performance. >> >> IMHO, considering just the actual uplink bandwidth will help a great >> deal. While estimating the currently "available" bandwidth would be >> still better, that is a lot harder to achieve. But if that is reasonably >> possible to do for the ALTO server, that is a much better alternative >> than having the peer probing for the real available bandwidth and >> picking the best one. >> >> Vinay. >> >> > >-- >Fabio Hecht > >University of Zurich - Department of Informatics (IfI) >Binzm=FChlestrasse 14 CH-8050 Z=FCrich, Switzerland >Ph.: +41 44 6357129 / 6350892 Fax: +41 44 6356809 >VoIP sip:hecht@ifi.uzh.ch > >_______________________________________________ >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 Aug 18 21:36: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 AC15E3A6C26; Mon, 18 Aug 2008 21:36: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 84D663A6C14 for ; Mon, 18 Aug 2008 21:36:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.004 X-Spam-Level: X-Spam-Status: No, score=-103.004 tagged_above=-999 required=5 tests=[AWL=-0.005, BAYES_00=-2.599, J_CHICKENPOX_66=0.6, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KQOgOGOrNJjU for ; Mon, 18 Aug 2008 21:36:29 -0700 (PDT) Received: from multicasttech.com (lennon.multicasttech.com [63.105.122.7]) by core3.amsl.com (Postfix) with ESMTP id 419903A6C26 for ; Mon, 18 Aug 2008 21:36:29 -0700 (PDT) Received: from [63.105.122.7] (account marshall_eubanks HELO [IPv6:::1]) by multicasttech.com (CommuniGate Pro SMTP 3.4.8) with ESMTP-TLS id 12557273; Tue, 19 Aug 2008 00:36:36 -0400 Message-Id: <8B2A8C57-F3D9-48FB-B02A-E3F424B71F02@multicasttech.com> From: Marshall Eubanks To: Stas Khirman In-Reply-To: <004601c90109$844b9890$6500a8c0@viceroy> Mime-Version: 1.0 (Apple Message framework v926) Date: Tue, 19 Aug 2008 00:36:35 -0400 References: <004601c90109$844b9890$6500a8c0@viceroy> X-Mailer: Apple Mail (2.926) Cc: p2pi@ietf.org, p4pwg@yahoogroups.com Subject: Re: [p2pi] Real life torrent statistics X-BeenThere: p2pi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: P2P Infrastructure Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="windows-1252"; Format="flowed"; DelSp="yes" Sender: p2pi-bounces@ietf.org Errors-To: p2pi-bounces@ietf.org On Aug 18, 2008, at 4:07 AM, Stas Khirman wrote: > To estimate a feasibility of ALTO/P4P for real life torrents , I = > collected information for peers from one of the most = > popular =93PirateBay=94 torrents ( almost 20k peers) and maped their IPs = > to corresponded ASs. Please find attached my working notes with some = > interesting statistics. > > In short =96 for such kind of swarm (20k peers), almost half of peers = > belong to ASs with 100 or more peers, almost 2/3 of peers belong to = > ASs with 50 or more peers. Less then 15% of peers belong to ASs with = > 10 or less =93neighbors=94. > A pdf version of this is at http://www.americafree.tv/papers/torrent_distribution.pdf (Note, by the way, that some people block attachments sent through = IETF mail lists.) These data seem to follow a power law for part of their range and I = would hypothesize that the number of peers versus rank follows a Mandelbrot - Pareto distribution. Here is a plot of the top 20 with a power law superimposed: http://www.americafree.tv/papers/torrent.top_20.png Regards Marshall > > US broadband ISPs (Road Runner, Comcast, AT&T) have about 2-3% of = > total peers each. > > Also, I find it surprising geo distribution of the peers =96 majority = > were in UK , not in US (probably because content is available in US = > theaters). Places 3-5 taken by Sweden,Poland and Canada (in total =96 = > more peers then in US). > > Certainly, observed =93heavy=94 neighboring of peers is a function of = > swarm size. I intend to investigate a few medium/small size swarms = > to have a multi-point picture for any future discussions. > > I would appreciate comments, corrections and additional ideas on = > data collection and analysis. > > _______________________________________________ > 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 Aug 18 23:27: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 BA5793A69BB; Mon, 18 Aug 2008 23:27: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 4F3CB3A6905 for ; Mon, 18 Aug 2008 23:27:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.554 X-Spam-Level: X-Spam-Status: No, score=-0.554 tagged_above=-999 required=5 tests=[AWL=0.556, BAYES_05=-1.11] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N5tDQF67vLDr for ; Mon, 18 Aug 2008 23:27:06 -0700 (PDT) Received: from mout.perfora.net (mout.perfora.net [74.208.4.195]) by core3.amsl.com (Postfix) with ESMTP id F05573A6919 for ; Mon, 18 Aug 2008 23:26:49 -0700 (PDT) Received: from viceroy (c-24-130-57-189.hsd1.ca.comcast.net [24.130.57.189]) by mrelay.perfora.net (node=mrus0) with ESMTP (Nemesis) id 0MKp8S-1KVKdU1Qt7-0003as; Tue, 19 Aug 2008 02:24:12 -0400 From: "Stas Khirman" To: References: <687558.6112.qm@web46212.mail.sp1.yahoo.com> Date: Mon, 18 Aug 2008 23:24:08 -0700 Message-ID: <00c301c901c4$3235bc50$140aa8c0@viceroy> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <687558.6112.qm@web46212.mail.sp1.yahoo.com> Thread-Index: AckBZBlT0pFGhjAtTtu4T7M1MU+rgAAX3EWQ X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 X-Provags-ID: V01U2FsdGVkX1+3FZv8s0xhQtAjZ/MQrb3FKm2414wjxUk588+ opNfESGorqc9qcf7Swyft52AkAdf7TA8mkRig1v+tOzMwAFwKV 9NQ6f79RPFdNtjSW7J4fQ== Cc: p2pi@ietf.org Subject: Re: [p2pi] Real life torrent statistics X-BeenThere: p2pi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: P2P Infrastructure Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: p2pi-bounces@ietf.org Errors-To: p2pi-bounces@ietf.org Victor, For my AS dataset, standard deviation is 48.86, average - 13.26, median - 91 I will post full AS data on the web and send you a pointer, so you can evaluate it as well. Regards Stas > -----Original Message----- > From: Victor Semanic [mailto:vsemanic@yahoo.com] > Sent: Monday, August 18, 2008 11:55 AM > To: stas@khirman.com > Cc: p2pi@ietf.org > Subject: Re: [p2pi] Real life torrent statistics > > Dear Dr. Khirman: > > You write: > > The dataset includes 19333 unique pairs (some IPs are > > repeatable) from 1459 ASs. Or 13.25 peers/AS in average. > > While aggregated by "ISP name", I got 1368 unique ISP names (not very > > accurate estimation by second part of AS name) or 14.1 peers per "ISP" > > Can you kindly provide some more information on the spread? That is, what > was the standard deviation and median for the peers/AS. I note from your > original email that the 20 most popular ASs account for about 35% of the > total ASs. The last AS listed in your table had 0.9% of the total, so I > suspect that as the AS list increases there are successively less > percentage of peers in them. As such, I will like to put in prespective > the 13.25 peers/AS average in light of the 20 most popular ASes. > > Thank you in advance for your time. > > > _______________________________________________ p2pi mailing list p2pi@ietf.org https://www.ietf.org/mailman/listinfo/p2pi From p2pi-bounces@ietf.org Mon Aug 18 23:48: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 3E4A13A6A34; Mon, 18 Aug 2008 23:48: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 993A43A689C for ; Mon, 18 Aug 2008 23:48:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.193 X-Spam-Level: X-Spam-Status: No, score=0.193 tagged_above=-999 required=5 tests=[AWL=-0.748, BANG_GUAR=0.939, BAYES_50=0.001, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UMWFE2zhl8vJ for ; Mon, 18 Aug 2008 23:48:50 -0700 (PDT) Received: from mout.perfora.net (mout.perfora.net [74.208.4.196]) by core3.amsl.com (Postfix) with ESMTP id BCC583A6880 for ; Mon, 18 Aug 2008 23:48:50 -0700 (PDT) Received: from viceroy (c-24-130-57-189.hsd1.ca.comcast.net [24.130.57.189]) by mrelay.perfora.net (node=mrus0) with ESMTP (Nemesis) id 0MKp8S-1KVL1D0YWh-0003ZG; Tue, 19 Aug 2008 02:48:42 -0400 From: "Stas Khirman" To: "'Marshall Eubanks'" References: <004601c90109$844b9890$6500a8c0@viceroy> <8B2A8C57-F3D9-48FB-B02A-E3F424B71F02@multicasttech.com> Date: Mon, 18 Aug 2008 23:48:38 -0700 Message-ID: <00d701c901c7$9f0340c0$140aa8c0@viceroy> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <8B2A8C57-F3D9-48FB-B02A-E3F424B71F02@multicasttech.com> Thread-Index: AckBtS88DI/5LrVNSJiYuReQGjo6QQAD9MsA X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 X-Provags-ID: V01U2FsdGVkX18nf6oTCMlM94gRsjjYo98YNll0kQSK2/ycqj/ ctSo/yJEhWgGuluKDuuCtXnHy1U0W3U8pga81KFlFiwWqfd+Ov CFtNfPd8ivY+5Xy3zbuEQ== Cc: p2pi@ietf.org, p4pwg@yahoogroups.com Subject: Re: [p2pi] Real life torrent statistics X-BeenThere: p2pi@ietf.org X-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="===============2004206276==" Sender: p2pi-bounces@ietf.org Errors-To: p2pi-bounces@ietf.org This is a multi-part message in MIME format. --===============2004206276== Content-Type: multipart/alternative; boundary="----=_NextPart_000_00D8_01C9018C.F2A468C0" This is a multi-part message in MIME format. ------=_NextPart_000_00D8_01C9018C.F2A468C0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit > Here is a plot of the top 20 with a power law superimposed: > > http://www.americafree.tv/papers/torrent.top_20.png > > Regards > Marshall > [Stas Khirman] Marshall, Thank for your investigation, but unfortunately, when considering tail of the distribution I'm not sure it power distribution can be claimed - please check http://www.khirman.com/system/files/image/blog/torrent_distribution_blog_2.g if By popular demand, I just published major points and raw data on my blog : http://www.khirman.com/blog/p2p_localisation Working notes available at http://www.khirman.com/system/files/image/blog/torrent_distribution.pdf Raw AS data http://www.khirman.com/system/files/image/blog/asn_groups.csv - please feel free to "twist" it - will appreciate any input. Regards Stas Khirman P.S. For those who in Silicon Valley - would be glad if you join our Club event August 21 - http://www.khirman.com/ctc/20080821 . Hot controversial discussion and cold beer - guaranteed! (please sign-up if you plan to attend) ------=_NextPart_000_00D8_01C9018C.F2A468C0 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable

> Here is a plot of the top 20 with a power law = superimposed:

>

> = http://www.americafree.tv/papers/torrent.top_20.png

>

> Regards

> Marshall

>

[Stas Khirman] =

 

Marshall= ,

 

Thank for your investigation, but = unfortunately, when considering tail of the distribution I'm not sure it power = distribution can be claimed - please check

http://www.khirman.com/system/files/image/blog/torrent_dis= tribution_blog_2.gif

 

By popular demand, I just = published major points and raw data on my blog :

http://www.khirman.= com/blog/p2p_localisation

 

Working notes available at http://www.khirman.com/system/files/image/blog/torrent_distributi= on.pdf

 

Raw AS data ht= tp://www.khirman.com/system/files/image/blog/asn_groups.csv - please feel free to “twist” it – will appreciate any = input.

 

 

Regards

Stas = Khirman

P.S. For those who in Silicon Valley – would be glad if you join our Club event = August 21 - http://www.khirman.com/ctc/2= 0080821 . Hot controversial discussion and cold beer – guaranteed! (please sign-up if you plan to attend)

 

 

------=_NextPart_000_00D8_01C9018C.F2A468C0-- --===============2004206276== 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 --===============2004206276==-- From p2pi-bounces@ietf.org Tue Aug 19 07:18: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 E686C3A68D9; Tue, 19 Aug 2008 07:18: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 C018D3A69FC for ; Tue, 19 Aug 2008 07:18:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.854 X-Spam-Level: X-Spam-Status: No, score=-1.854 tagged_above=-999 required=5 tests=[AWL=-0.744, BAYES_05=-1.11] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vg7jPNfHqkT5 for ; Tue, 19 Aug 2008 07:18:10 -0700 (PDT) Received: from ihemail3.lucent.com (ihemail3.lucent.com [135.245.0.37]) by core3.amsl.com (Postfix) with ESMTP id 51BBD3A68D9 for ; Tue, 19 Aug 2008 07:18: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 m7JEHR0I026398 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 19 Aug 2008 09:17:27 -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 m7JEHDiF011107; Tue, 19 Aug 2008 09:17:21 -0500 (CDT) Message-ID: <48AAD5EF.5030303@alcatel-lucent.com> Date: Tue, 19 Aug 2008 09:17:19 -0500 From: "Vijay K. Gurbani" Organization: Bell Labs Security Technology Research Group User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Fabio Hecht References: <489B498B.4040804@telecomitalia.it> <20080811143531.GA18911@net.t-labs.tu-berlin.de> <20080811165443.GB18911@net.t-labs.tu-berlin.de> <1219070969.6961.37.camel@bart2> In-Reply-To: <1219070969.6961.37.camel@bart2> X-Scanned-By: MIMEDefang 2.57 on 135.245.2.37 Cc: "p2pi@ietf.org" Subject: Re: [p2pi] Information in an ALTO protocol X-BeenThere: p2pi@ietf.org 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 Fabio Hecht wrote: > in this case, would an ALTO Server query other ALTO Servers to gather > this information? Because, from an ISP point of view, the ALTO Server > would not know what the last-hop bandwidth is for every other peer. > Would the protocol then be the same used by the overlay applications? Fabio: At this point, not much thought has been given to an Inter-ALTO server protocol or what its form may be. We are trying to get our hands around the needed information that could serve as the building block for an ALTO server - ALTO client protocol. Thanks, - vijay -- Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent 2701 Lucent Lane, Rm. 9F-546, Lisle, Illinois 60532 (USA) Email: vkg@{alcatel-lucent.com,bell-labs.com,acm.org} WWW: http://www.alcatel-lucent.com/bell-labs _______________________________________________ p2pi mailing list p2pi@ietf.org https://www.ietf.org/mailman/listinfo/p2pi From p2pi-bounces@ietf.org Tue Aug 19 07:35: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 CD7A23A6ABA; Tue, 19 Aug 2008 07:35: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 D4AB03A6B33 for ; Tue, 19 Aug 2008 07:35:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.564 X-Spam-Level: X-Spam-Status: No, score=-101.564 tagged_above=-999 required=5 tests=[AWL=-1.504, BANG_GUAR=0.939, BAYES_50=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kKUXRfO8Wm+Q for ; Tue, 19 Aug 2008 07:35:46 -0700 (PDT) Received: from multicasttech.com (lennon.multicasttech.com [63.105.122.7]) by core3.amsl.com (Postfix) with ESMTP id B0CED3A6A34 for ; Tue, 19 Aug 2008 07:35:45 -0700 (PDT) Received: from [63.105.122.7] (account marshall_eubanks HELO [IPv6:::1]) by multicasttech.com (CommuniGate Pro SMTP 3.4.8) with ESMTP-TLS id 12564687; Tue, 19 Aug 2008 10:35:53 -0400 Message-Id: From: Marshall Eubanks To: "Stas Khirman" In-Reply-To: <00d701c901c7$9f0340c0$140aa8c0@viceroy> Mime-Version: 1.0 (Apple Message framework v926) Date: Tue, 19 Aug 2008 10:35:52 -0400 References: <004601c90109$844b9890$6500a8c0@viceroy> <8B2A8C57-F3D9-48FB-B02A-E3F424B71F02@multicasttech.com> <00d701c901c7$9f0340c0$140aa8c0@viceroy> X-Mailer: Apple Mail (2.926) Cc: p2pi@ietf.org, p4pwg@yahoogroups.com Subject: Re: [p2pi] Real life torrent statistics X-BeenThere: p2pi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: P2P Infrastructure Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="windows-1252"; Format="flowed"; DelSp="yes" Sender: p2pi-bounces@ietf.org Errors-To: p2pi-bounces@ietf.org On Aug 19, 2008, at 2:48 AM, Stas Khirman wrote: > > Here is a plot of the top 20 with a power law superimposed: > > > > http://www.americafree.tv/papers/torrent.top_20.png > > > > Regards > > Marshall > > > [Stas Khirman] > > Marshall, > > Thank for your investigation, but unfortunately, when considering = > tail of the distribution I'm not sure it power distribution can be = > claimed - please check > http://www.khirman.com/system/files/image/blog/torrent_distribution_blog_= 2.gif Well, you generally can't tell anything from a linear-linear plots in = these cases. However, it is common in these cases for there to be a flattening with = small rank (thus the Pareto-Mandelbrot or Zipf-Mandelbrot distribution), and a = lack of power as the numbers per bin get to be of order unity. Both of these can be seen with the full data set http://www.americafree.tv/papers/asn_groups.png http://www.americafree.tv/papers/asn_groups.2.png With only 3 degrees of freedom, the modified power law fits well for = about 2 decades of rank. This is not too surprising to me - similar Zipf type modified power = laws can be seen in the selection of video content (see http://www.imconf.net/imc-2007/papers/ = imc78.pdf ) and I would expect node selection to trace that. Regards Marshall >> > By popular demand, I just published major points and raw data on my = > blog : > http://www.khirman.com/blog/p2p_localisation > > Working notes available at http://www.khirman.com/system/files/image/blog= /torrent_distribution.pdf > > Raw AS data http://www.khirman.com/system/files/image/blog/asn_groups.csv = > - please feel free to =93twist=94 it =96 will appreciate any input. > > > Regards > Stas Khirman > P.S. For those who in Silicon Valley =96 would be glad if you join our = > Club event August 21 - http://www.khirman.com/ctc/20080821. Hot = > controversial discussion and cold beer =96 guaranteed! (please sign-up = > if you plan to attend) > > _______________________________________________ p2pi mailing list p2pi@ietf.org https://www.ietf.org/mailman/listinfo/p2pi From p2pi-bounces@ietf.org Tue Aug 19 10:49: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 0DA6628C1E0; Tue, 19 Aug 2008 10:49: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 66E0E3A682A for ; Tue, 19 Aug 2008 10:49:02 -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 wL+rr5zrRcy1 for ; Tue, 19 Aug 2008 10:49:00 -0700 (PDT) Received: from ihemail3.lucent.com (ihemail3.lucent.com [135.245.0.37]) by core3.amsl.com (Postfix) with ESMTP id 315B028C15A for ; Tue, 19 Aug 2008 10:49:00 -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 m7JHmJQx003829 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 19 Aug 2008 12:48:19 -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 m7JHmCrd005869; Tue, 19 Aug 2008 12:48:13 -0500 (CDT) Message-ID: <48AB0761.7070507@alcatel-lucent.com> Date: Tue, 19 Aug 2008 12:48: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: john@jlc.net References: <74CCBBDF76102846AFA7B29F3A98D3F60107C32A@PACDCEXCMB06.cable.comcast.com> <200808120901.m7C91q6H012752@bagheera.jungle.bt.co.uk> <48A48779.60507@alcatel-lucent.com> <20080814204249.GS25453@verdi> In-Reply-To: <20080814204249.GS25453@verdi> X-Scanned-By: MIMEDefang 2.57 on 135.245.2.37 Cc: "p2pi@ietf.org" Subject: Re: [p2pi] Information in an ALTO protocol X-BeenThere: p2pi@ietf.org 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 John Leslie wrote: > Vijay K. Gurbani wrote: >> I think that which parameters to gather will turn out to be an >> interesting topic to nail down. > > Interesting, certainly; but IMHO unwise to nail down too tightly. John: Agreed, and my intention was not to nail them down but continue discussion on which pieces of information are useful to guide work that will be done in the future. After all is said and done, one of the deliverables will be a schema document -- as extensible as it may be -- to communicate information between the pertinent entities. >> At present, we have the following discrete pieces of information >> mentioned in the post-BoF charter: >> >> (1) Routing preferences >> (2) Priority values > > These are a bit amorphous... Fair enough. Folks have suggested that preferences and priorities along the lines of: _is_better_than_ _is_better_than_ How do you see that we can make these a bit more concrete? >> (3) AS numbers > > Sometimes very useful; sometimes not... But arguably a low-hanging fruit that does indeed provide some information that is helpful in the absence of any other guidance. >> (4) Geographic location > > Often wildly inaccurate, and even more often quite unrelated to > network topology. Would be _very_ useful in an alternate universe where > routing found next-hops _physically_ closer to the destination... Probably needs a bit more discussion on whether or not this is valuable before discarding it. >> 6 can be provided by the network operator or approximated using >> synthetic coordinate systems and the like. > > Actual topology is likely to change without warning; so you should > be prepared for it to prove wildly inaccurate. More often than not, > it turns out to be only roughly approximated or hopelessly optimistic. Sure; synthetic coordinate systems have been designed with approximations and opportunistic optimism in mind. While the active guidance of an ISP in imparting topological information is best, we should not preclude third-party services from approximating the same to the best of their abilities. >> Information that has been deemed out of scope based on list >> discussion is: >> >> (1) Last hop bandwidth > > The most useful number yet listed, _if_ folks will give it to us > and we interpret it correctly... Hmmm ... so I suspect that it is premature to say that last-hop bandwidth is out of scope? What do others think? >> What other sort of information should be a focus of ALTO? > > It would be rather useful to have "characteristics that indicate > congestion" on a path. The applications are going to have to judge > instantaneous congestion anyway, and basing that judgment on > known characteristics rather than guesswork should speed progress > towards an optimal mix. > > Jitter in the latency will be of interest to certain applications. I believe that these will fall squarely in TANA, if not some other TSV WG. Thank you. - vijay -- Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent 2701 Lucent Lane, Rm. 9F-546, Lisle, Illinois 60532 (USA) Email: vkg@{alcatel-lucent.com,bell-labs.com,acm.org} WWW: http://www.alcatel-lucent.com/bell-labs _______________________________________________ p2pi mailing list p2pi@ietf.org https://www.ietf.org/mailman/listinfo/p2pi From p2pi-bounces@ietf.org Tue Aug 19 11:05: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 890A53A6B49; Tue, 19 Aug 2008 11:05: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 728003A6B49 for ; Tue, 19 Aug 2008 11:05:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R0JOYxwMscuo for ; Tue, 19 Aug 2008 11:05:36 -0700 (PDT) Received: from smtp.microsoft.com (mail1.microsoft.com [131.107.115.212]) by core3.amsl.com (Postfix) with ESMTP id B3A963A685E for ; Tue, 19 Aug 2008 11:05:36 -0700 (PDT) Received: from tk5-exhub-c104.redmond.corp.microsoft.com (157.54.88.97) by TK5-EXGWY-E801.partners.extranet.microsoft.com (10.251.56.50) with Microsoft SMTP Server (TLS) id 8.1.291.1; Tue, 19 Aug 2008 11:04:42 -0700 Received: from NA-EXMSG-C102.redmond.corp.microsoft.com ([157.54.110.49]) by tk5-exhub-c104.redmond.corp.microsoft.com ([157.54.88.97]) with mapi; Tue, 19 Aug 2008 11:04:42 -0700 From: Yu-Shun Wang To: "Vijay K. Gurbani" , "john@jlc.net" Date: Tue, 19 Aug 2008 11:04:41 -0700 Thread-Topic: [p2pi] Information in an ALTO protocol Thread-Index: AckCJBBIHk/Tjfa5QGqvcAucMEIgRQAARrpw Message-ID: <43AEA9A9F7768B42A89F554F0EBF7ED82B5FDCEE3A@NA-EXMSG-C102.redmond.corp.microsoft.com> References: <74CCBBDF76102846AFA7B29F3A98D3F60107C32A@PACDCEXCMB06.cable.comcast.com> <200808120901.m7C91q6H012752@bagheera.jungle.bt.co.uk> <48A48779.60507@alcatel-lucent.com> <20080814204249.GS25453@verdi> <48AB0761.7070507@alcatel-lucent.com> In-Reply-To: <48AB0761.7070507@alcatel-lucent.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 Cc: "p2pi@ietf.org" Subject: Re: [p2pi] Information in an ALTO protocol X-BeenThere: p2pi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: P2P Infrastructure Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: p2pi-bounces@ietf.org Errors-To: p2pi-bounces@ietf.org Short comment on this bit: > >> (4) Geographic location > > > > Often wildly inaccurate, and even more often quite unrelated to > > network topology. Would be _very_ useful in an alternate universe > > where routing found next-hops _physically_ closer to the > > destination... > > Probably needs a bit more discussion on whether or not this is > valuable before discarding it. This may have policy (distribution rights, etc.) implications. That said, not sure if we want to go there. Maybe worth retaining it, but leave the interpretation/usage up to the apps. yushun _______________________________________________ p2pi mailing list p2pi@ietf.org https://www.ietf.org/mailman/listinfo/p2pi From p2pi-bounces@ietf.org Tue Aug 19 13:34:50 2008 Return-Path: X-Original-To: p2pi-archive@ietf.org Delivered-To: ietfarch-p2pi-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D4D103A6839; Tue, 19 Aug 2008 13:34:50 -0700 (PDT) X-Original-To: p2pi@core3.amsl.com Delivered-To: p2pi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8DC8D3A6839 for ; Tue, 19 Aug 2008 13:34:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.83 X-Spam-Level: X-Spam-Status: No, score=-1.83 tagged_above=-999 required=5 tests=[AWL=-1.770, BANG_GUAR=0.939, BAYES_50=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2YKC0+1SrriL for ; Tue, 19 Aug 2008 13:34:48 -0700 (PDT) Received: from jalapeno.cc.columbia.edu (jalapeno.cc.columbia.edu [128.59.29.5]) by core3.amsl.com (Postfix) with ESMTP id 6A1A93A6811 for ; Tue, 19 Aug 2008 13:34:48 -0700 (PDT) Received: from banana.cc.columbia.edu (banana.cc.columbia.edu [128.59.29.54]) by jalapeno.cc.columbia.edu (8.14.1/8.14.1) with ESMTP id m7JKXseq012741; Tue, 19 Aug 2008 16:33:59 -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 m7JKXstp025738; Tue, 19 Aug 2008 16:33:54 -0400 (EDT) Received: from localhost (sa2086@localhost) by banana.cc.columbia.edu (8.14.1/8.14.1/Submit) with ESMTP id m7JKXoGl025729; Tue, 19 Aug 2008 16:33:51 -0400 (EDT) X-Authentication-Warning: banana.cc.columbia.edu: sa2086 owned process doing -bs Date: Tue, 19 Aug 2008 16:33:50 -0400 (EDT) From: Salman Abdul Baset To: Stas Khirman In-Reply-To: <00d701c901c7$9f0340c0$140aa8c0@viceroy> Message-ID: References: <004601c90109$844b9890$6500a8c0@viceroy> <8B2A8C57-F3D9-48FB-B02A-E3F424B71F02@multicasttech.com> <00d701c901c7$9f0340c0$140aa8c0@viceroy> User-Agent: Alpine 1.00 (SOC 882 2007-12-20) MIME-Version: 1.0 X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.63 on 128.59.29.5 Cc: p2pi@ietf.org Subject: Re: [p2pi] Real life torrent statistics X-BeenThere: p2pi@ietf.org 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 We have some related data from measuring Skype relays. http://www1.cs.columbia.edu/~salman/publications/skyperelay08.pdf -s On Mon, 18 Aug 2008, Stas Khirman wrote: >> Here is a plot of the top 20 with a power law superimposed: > >> > >> http://www.americafree.tv/papers/torrent.top_20.png > >> > >> Regards > >> Marshall > >> > > [Stas Khirman] > > > > Marshall, > > > > Thank for your investigation, but unfortunately, when considering tail of > the distribution I'm not sure it power distribution can be claimed - please > check > > http://www.khirman.com/system/files/image/blog/torrent_distribution_blog_2.g > if > > > > By popular demand, I just published major points and raw data on my blog : > > http://www.khirman.com/blog/p2p_localisation > > > > Working notes available at > http://www.khirman.com/system/files/image/blog/torrent_distribution.pdf > > > > Raw AS data http://www.khirman.com/system/files/image/blog/asn_groups.csv - > please feel free to "twist" it - will appreciate any input. > > > > > > Regards > > Stas Khirman > > P.S. For those who in Silicon Valley - would be glad if you join our Club > event August 21 - http://www.khirman.com/ctc/20080821 . Hot controversial > discussion and cold beer - guaranteed! (please sign-up if you plan to > attend) > > > > > > _______________________________________________ p2pi mailing list p2pi@ietf.org https://www.ietf.org/mailman/listinfo/p2pi From p2pi-bounces@ietf.org Tue Aug 19 14:29: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 3B6DA3A66B4; Tue, 19 Aug 2008 14:29: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 B7B3A3A63D2 for ; Tue, 19 Aug 2008 14:29:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.502 X-Spam-Level: X-Spam-Status: No, score=-2.502 tagged_above=-999 required=5 tests=[AWL=0.097, 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 wzINfp+LKBvP for ; Tue, 19 Aug 2008 14:29:06 -0700 (PDT) Received: from mailhost.jlc.net (mailhost.jlc.net [199.201.159.9]) by core3.amsl.com (Postfix) with ESMTP id C871B3A66B4 for ; Tue, 19 Aug 2008 14:29:05 -0700 (PDT) Received: by mailhost.jlc.net (Postfix, from userid 104) id 8680933C4A; Tue, 19 Aug 2008 17:28:16 -0400 (EDT) Date: Tue, 19 Aug 2008 17:28:16 -0400 From: John Leslie To: "Vijay K. Gurbani" Message-ID: <20080819212816.GK25453@verdi> References: <74CCBBDF76102846AFA7B29F3A98D3F60107C32A@PACDCEXCMB06.cable.comcast.com> <200808120901.m7C91q6H012752@bagheera.jungle.bt.co.uk> <48A48779.60507@alcatel-lucent.com> <20080814204249.GS25453@verdi> <48AB0761.7070507@alcatel-lucent.com> Mime-Version: 1.0 Content-Disposition: inline In-Reply-To: <48AB0761.7070507@alcatel-lucent.com> User-Agent: Mutt/1.4.1i Cc: "p2pi@ietf.org" Subject: Re: [p2pi] Information in an ALTO protocol X-BeenThere: p2pi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: P2P Infrastructure Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: p2pi-bounces@ietf.org Errors-To: p2pi-bounces@ietf.org Vijay K. Gurbani wrote: > John Leslie wrote: >> Vijay K. Gurbani wrote: > >>> At present, we have the following discrete pieces of information >>> mentioned in the post-BoF charter: >>> >>> (1) Routing preferences >>> (2) Priority values >> >> These are a bit amorphous... > > Fair enough. Folks have suggested that preferences and priorities > along the lines of: > > _is_better_than_ > _is_better_than_ > > > How do you see that we can make these a bit more concrete? I get nervous when I see sorting by priority -- all it takes is one item changing and your whole sorting is invalidated. I'd like to gather information with very little tendency to change and report that. When we talk "local", we risk confusing different categories of "local". Are we talking a neighborhood, a geographic area where concentration is done, a routing domain, an Autonomous System, an island, a continent, or what? Also, if "local is better", better for what? I claim that what we really care about is congestion choke points. And obviously, we care the most about choke points which will actually be congested during our p2p transfer. So I'd prefer information such as - the uplink from this CIDR block is congested part of most days; when its latency exceeds 10 milliseconds, assume it's congested. - the downlink to this CIDR block is congested part of some days; when its latency exceeds 20 milliseconds, assume it's congested. - the up & down link from this CIDR block to our nearest peering point is seldom congested; it's minimum latency is 11 milliseconds. - our peering for CIDR blocks (a, b, c...) to AS #### is seldom congested. - our peering for these CIDR block to AS #### is occasionally congested; packets start dropping at a latency of 1.4 milliseconds. - peering for AS #### usually flows through AS #### These are all things that a NOC is aware of -- though admittedly management _may_ believe that admitting to these would somehow benefit their competiton. What the application wants to know, of course, is the above for its local ISP plus the corresponding info for the destination ISP's CIDR block. Being a simple-minded fellow, I thing it would be nice to be able to query both ISPs. (The query to the remote ISP, of course, could be done more efficiently by the tracker.) >>> (3) AS numbers >> >> Sometimes very useful; sometimes not... > > But arguably a low-hanging fruit that does indeed provide some > information that is helpful in the absence of any other guidance. AS numbers are very useful if we're trying to model the behavior of routers; but this is not always the case: rather often we're overwhelmed by local congestion. >>> (4) Geographic location >> >> Often wildly inaccurate, and even more often quite unrelated to >> network topology. Would be _very_ useful in an alternate universe where >> routing found next-hops _physically_ closer to the destination... > > Probably needs a bit more discussion on whether or not this is > valuable before discarding it. I don't mean to discard it; but I hesitate to put much weight on it. >>> 6 can be provided by the network operator or approximated using >>> synthetic coordinate systems and the like. >> >> Actual topology is likely to change without warning; so you should >> be prepared for it to prove wildly inaccurate. More often than not, >> it turns out to be only roughly approximated or hopelessly optimistic. > > Sure; synthetic coordinate systems have been designed with > approximations and opportunistic optimism in mind. While the > active guidance of an ISP in imparting topological information > is best, we should not preclude third-party services from > approximating the same to the best of their abilities. Actually, most of the stuff I listed at the beginning of this email can be reasonably well approximated by trackers cooperating with peers. IMHO, they'd be better advised to gather those data than chase synthetic coordinates. (YMMV) >>> Information that has been deemed out of scope based on list >>> discussion is: >>> >>> (1) Last hop bandwidth >> >> The most useful number yet listed, _if_ folks will give it to us >> and we interpret it correctly... > > Hmmm ... so I suspect that it is premature to say that last-hop > bandwidth is out of scope? What do others think? For myself, I think we'd be silly to rule it out-of-scope because we don't believe ISPs would agree to provide it. _Any_ question we ask an ISP may well receive a "none-of-your-business" reply. >>> What other sort of information should be a focus of ALTO? >> >> It would be rather useful to have "characteristics that indicate >> congestion" on a path. The applications are going to have to judge >> instantaneous congestion anyway, and basing that judgment on >> known characteristics rather than guesswork should speed progress >> towards an optimal mix. >> >> Jitter in the latency will be of interest to certain applications. > > I believe that these will fall squarely in TANA, if not some other > TSV WG. I don't mean to infringe on any other WG's charter: I just mean that jitter information would sometimes be helpful in choosing a peer. I venture no opinion on who should provide it. -- John Leslie _______________________________________________ p2pi mailing list p2pi@ietf.org https://www.ietf.org/mailman/listinfo/p2pi From p2pi-bounces@ietf.org Tue Aug 19 16:40: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 BAB6628C225; Tue, 19 Aug 2008 16:40: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 CBB5028C226 for ; Tue, 19 Aug 2008 16:40:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.179 X-Spam-Level: ** X-Spam-Status: No, score=2.179 tagged_above=-999 required=5 tests=[AWL=0.370, BAYES_50=0.001, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, 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 NIqGGbd+wV1P for ; Tue, 19 Aug 2008 16:40:49 -0700 (PDT) Received: from mo-p00-ob.rzone.de (mo-p00-ob.rzone.de [81.169.146.161]) by core3.amsl.com (Postfix) with ESMTP id 26BFD3A6BED for ; Tue, 19 Aug 2008 16:40:46 -0700 (PDT) X-RZG-CLASS-ID: mo00 X-RZG-AUTH: :LW0Wek7mfO1Vkr5kPgWDvaJNkQpNEn8ylntakOISso1hE0McXW12o8AG24SD41nTjy5r24VXmP8qMlVXW88= Received: from [192.168.1.78] (Ta6c2.t.pppool.de [89.55.166.194]) by post.webmailer.de (klopstock mo48) (RZmta 16.47) with ESMTP id R00cb9k7JL5tMQ ; Wed, 20 Aug 2008 01:40:40 +0200 (MEST) (envelope-from: ) Message-ID: <48AB59F7.6010907@infinite-source.de> Date: Wed, 20 Aug 2008 01:40:39 +0200 From: The 8472 User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: Stas Khirman References: <004601c90109$844b9890$6500a8c0@viceroy> In-Reply-To: <004601c90109$844b9890$6500a8c0@viceroy> Cc: p2pi@ietf.org, p4pwg@yahoogroups.com Subject: Re: [p2pi] Real life torrent statistics X-BeenThere: p2pi@ietf.org X-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="===============2022839879==" Sender: p2pi-bounces@ietf.org Errors-To: p2pi-bounces@ietf.org --===============2022839879== Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Stas Khirman wrote:

To estimate a feasibility of ALTO/P4P for real life torrents , I collected <ip,port> information for peers from one of the most popular “PirateBay” torrents ( almost 20k peers) and maped their IPs to corresponded ASs. Please find attached my working notes with some interesting statistics.

Ahh, there is a problem with this one. With torrents you have a significant long tail when it comes to swarm sizes and content. I'm not certain about distribution, but the long tail will probably outweight the... let's say top 100 torrents. Torrents with only 10-20 peers spread throughout several ASNs is a much harder to optimize than the top 100.
This problem is aggreviated by swarm fragmentation due to private trackers and since bittorrent does not aim to coalesce all torrents with the same content, i.e. due to different piece sizes, file names etc.

Also, I find it surprising geo distribution of the peers – majority were in UK , not in US (probably because content is available in US theaters).  Places 3-5 taken by Sweden, Poland and Canada (in total – more peers then in US).

This will probably be different if you sample torrents from regional trackers or torrents aimed at other audiences. During some DHT tracing on the weekend i saw a significant proportion of DHT traffic coming from asian countries, though i suspect an inefficient implementation of the DHT by a client that's popular in china to play some role in this distribution.

 

Certainly, observed “heavy” neighboring of peers is a function of swarm size. I intend to investigate a few medium/small size swarms to have a multi-point picture for any future discussions.

as i mentioned above we should try to get the big picture, i.e. how relevant the long tail is, measured in aggregate bandwidth. If the small torrents actually make up the bulk of the traffic then any solution will require a high degree of cooperation between ISPs, e.g. caches that cooperate with each other.

--
The 8472
independent developer for the Azureus Vuze Bittorrent client
--===============2022839879== 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 --===============2022839879==-- From p2pi-bounces@ietf.org Tue Aug 19 17:05: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 1596028C13A; Tue, 19 Aug 2008 17:05: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 222B33A6B4D for ; Tue, 19 Aug 2008 17:05:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.889 X-Spam-Level: X-Spam-Status: No, score=-8.889 tagged_above=-999 required=5 tests=[AWL=-1.226, BAYES_50=0.001, 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 w3zawxtayEaF for ; Tue, 19 Aug 2008 17:05:09 -0700 (PDT) Received: from dkny.pando.com (dkny.pando.com [67.99.55.163]) by core3.amsl.com (Postfix) with ESMTP id A52DA3A6B77 for ; Tue, 19 Aug 2008 17:05:09 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by dkny.pando.com (Postfix) with ESMTP id 81CAEE10C02; Tue, 19 Aug 2008 20:05:12 -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 StHZouZa9iP1; Tue, 19 Aug 2008 20:04:59 -0400 (EDT) Received: from dkny.pando.com (dkny.pando.com [10.10.60.11]) by dkny.pando.com (Postfix) with ESMTP id 2AB2BE10AB8; Tue, 19 Aug 2008 20:04:59 -0400 (EDT) Date: Tue, 19 Aug 2008 20:04:59 -0400 (EDT) From: Laird Popkin To: The 8472 Message-ID: <685421868.179521219190699129.JavaMail.root@dkny.pando.com> In-Reply-To: <1104054922.179501219190149690.JavaMail.root@dkny.pando.com> MIME-Version: 1.0 X-Originating-IP: [10.10.20.79] Cc: p2pi@ietf.org, p4pwg@yahoogroups.com Subject: Re: [p2pi] Real life torrent statistics X-BeenThere: p2pi@ietf.org X-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="===============0946967062==" Sender: p2pi-bounces@ietf.org Errors-To: p2pi-bounces@ietf.org --===============0946967062== Content-Type: multipart/alternative; boundary="----=_Part_8049_1001143559.1219190699128" ------=_Part_8049_1001143559.1219190699128 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable You're right that swarms with 10 peers can't be optimized - the p2p network= will connect all 10 peers to each other and move as much data as possible.= =20 That being said, I suspect that a small number of very popular swarms that = can be optimized would give significant impact on overall data flow, becaus= e one swarm with 20,000 peers balances out a lot of 'long tail'. Haiyong Xi= e of Yale mentioned=C2=A0to me that there was an analysis of this last year= , by spidering one of the popular torrent web sites, and their conclusion w= as that well over 50% of the downloaders were in swarms with 100+ active pe= ers, which is where they estimate that P4P optimization applies. Similarly,= when I was in the music business and tracked such things, 2% of the files = in the p2p networks accounted for the large majority of the download activi= ty.=20 I think that it would be a very interesting analysis, spidering some torren= t web sites and seeing how the distribution of bandwidth is balanced betwee= n the 'head' and the 'long tail'.=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: "The 8472" =20 To: "Stas Khirman" =20 Cc: p2pi@ietf.org, p4pwg@yahoogroups.com=20 Sent: Tuesday, August 19, 2008 4:40:39 PM (GMT-0800) America/Los_Angeles=20 Subject: Re: [p2pi] Real life torrent statistics=20 Stas Khirman wrote:=20 To estimate a feasibility of ALTO/P4P for real life torrents , I collected = information for peers from one of the most popular =E2=80=9CPirat= eBay=E2=80=9D torrents ( almost 20k peers) and maped their IPs to correspon= ded ASs. Please find attached my working notes with some interesting statis= tics. Ahh, there is a problem with this one. With torrents you have a signi= ficant long tail when it comes to swarm sizes and content. I'm not certain = about distribution, but the long tail will probably outweight the... let's = say top 100 torrents. Torrents with only 10-20 peers spread throughout seve= ral ASNs is a much harder to optimize than the top 100.=20 This problem is aggreviated by swarm fragmentation due to private trackers = and since bittorrent does not aim to coalesce all torrents with the same co= ntent, i.e. due to different piece sizes, file names etc.=20 Also, I find it surprising geo distribution of the peers =E2=80=93 majority= were in UK , not in US (probably because content is available in US theate= rs). =C2=A0Places 3-5 taken by Sweden, Poland and Canada (in total =E2=80= =93 more peers then in US). This will probably be different if you sample t= orrents from regional trackers or torrents aimed at other audiences. During= some DHT tracing on the weekend i saw a significant proportion of DHT traf= fic coming from asian countries, though i suspect an inefficient implementa= tion of the DHT by a client that's popular in china to play some role in th= is distribution.=20 Certainly, observed =E2=80=9Cheavy=E2=80=9D neighboring of peers is a funct= ion of swarm size. I intend to investigate a few medium/small size swarms t= o have a multi-point picture for any future discussions. as i mentioned abo= ve we should try to get the big picture, i.e. how relevant the long tail is= , measured in aggregate bandwidth. If the small torrents actually make up t= he bulk of the traffic then any solution will require a high degree of coop= eration between ISPs, e.g. caches that cooperate with each other.=20 --=20 The 8472=20 independent developer for the Azureus Vuze Bittorrent client=20 _______________________________________________ p2pi mailing list p2pi@ietf= .org https://www.ietf.org/mailman/listinfo/p2pi ------=_Part_8049_1001143559.1219190699128 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable

You're right that swarms with 10 peers can't= be optimized - the p2p network will connect all 10 peers to each other and= move as much data as possible.

 

That being said, I suspect that a small number of very popular swarms th= at can be optimized would give significant impact on overall data flow, bec= ause one swarm with 20,000 peers balances out a lot of 'long tail'. Haiyong= Xie of Yale mentioned to me that there was an analysis of this last y= ear, by spidering one of the popular torrent web sites, and their conclusio= n was that well over 50% of the downloaders were in swarms with 100+ active= peers, which is where they estimate that P4P optimization applies. Similar= ly, when I was in the music business and tracked such things, 2% of the fil= es in the p2p networks accounted for the large majority of the download act= ivity.

 

I think that it would be a very interesting analysis, spidering some tor= rent web sites and seeing how the distribution of bandwidth is balanced bet= ween the 'head' and the 'long tail'.


- Laird Popkin, CTO, Pando Networks
&nbs= p; mobile: 646/465-0570

----- Original Message -----
Fr= om: "The 8472" <the8472@infinite-source.de>
To: "Stas Khirman" <= ;stas@khirman.com>
Cc: p2pi@ietf.org, p4pwg@yahoogroups.com
Sent: = Tuesday, August 19, 2008 4:40:39 PM (GMT-0800) America/Los_Angeles
Subje= ct: Re: [p2pi] Real life torrent statistics

Stas Khirman wrote:

To estimate a feasibility of ALTO/P4P for real li= fe torrents , I collected <ip,port> information for peers from one of= the most popular =E2=80=9CPirateBay=E2=80=9D torrents ( almost 20k peers) = and maped their IPs to corresponded ASs. Please find attached my working no= tes with some interesting statistics.

A= hh, there is a problem with this one. With torrents you have a significant = long tail when it comes to swarm sizes and content. I'm not certain about d= istribution, but the long tail will probably outweight the... let's say top= 100 torrents. Torrents with only 10-20 peers spread throughout several ASN= s is a much harder to optimize than the top 100.
This problem is aggrevi= ated by swarm fragmentation due to private trackers and since bittorrent do= es not aim to coalesce all torrents with the same content, i.e. due to diff= erent piece sizes, file names etc.

Also, I find it surprising geo distribution of th= e peers =E2=80=93 majority were in UK , not in US (probably because content= is available in US theaters).  Places 3-5 taken by Sweden, Poland and= Canada (in total =E2=80=93 more peers then in US).

=
This will probably be different if you sample torrents from re= gional trackers or torrents aimed at other audiences. During some DHT traci= ng on the weekend i saw a significant proportion of DHT traffic coming from= asian countries, though i suspect an inefficient implementation of the DHT= by a client that's popular in china to play some role in this distribution= .

 

Certainly, observed =E2=80=9Cheavy=E2=80=9D neigh= boring of peers is a function of swarm size. I intend to investigate a few = medium/small size swarms to have a multi-point picture for any future discu= ssions.

as i mentioned above we should = try to get the big picture, i.e. how relevant the long tail is, measured in= aggregate bandwidth. If the small torrents actually make up the bulk of th= e traffic then any solution will require a high degree of cooperation betwe= en ISPs, e.g. caches that cooperate with each other.

--
The 8472=
independent developer for the Azureus Vuze Bittorrent client

_= ______________________________________________ p2pi mailing list p2pi@ietf.= org https://www.ietf.org/mailman/listinfo/p2pi ------=_Part_8049_1001143559.1219190699128-- --===============0946967062== 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 --===============0946967062==-- From p2pi-bounces@ietf.org Tue Aug 19 17:21: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 6FAEC28C225; Tue, 19 Aug 2008 17:21: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 281FE3A6A1F for ; Tue, 19 Aug 2008 17:21:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id enOJvki-PtQE for ; Tue, 19 Aug 2008 17:21:47 -0700 (PDT) Received: from mout.perfora.net (mout.perfora.net [74.208.4.195]) by core3.amsl.com (Postfix) with ESMTP id 363E628C22D for ; Tue, 19 Aug 2008 17:21:46 -0700 (PDT) Received: from viceroy (ppp-71-139-12-121.dsl.snfc21.pacbell.net [71.139.12.121]) by mrelay.perfora.net (node=mrus1) with ESMTP (Nemesis) id 0MKpCa-1KVbSN24i4-0005Iv; Tue, 19 Aug 2008 20:21:52 -0400 From: "Stas Khirman" To: "'Laird Popkin'" , "'The 8472'" References: <1104054922.179501219190149690.JavaMail.root@dkny.pando.com> <685421868.179521219190699129.JavaMail.root@dkny.pando.com> Date: Tue, 19 Aug 2008 17:21:46 -0700 Message-ID: <003401c9025a$be8e0360$140aa8c0@viceroy> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 thread-index: AckCWHM0lYJ1JL9/SB66Cc+pIwVCugAAPKHw In-Reply-To: <685421868.179521219190699129.JavaMail.root@dkny.pando.com> X-Provags-ID: V01U2FsdGVkX18keYeJnKRC5o3ymDDrOAXukA+n4MBl10009hD fWcgADXIHiW9Tckonrlfp+vQwYWjOsTLE14fNRjGrodd/fycA4 qDM05f4TU+fWwfLhl3NpA== Cc: p2pi@ietf.org, p4pwg@yahoogroups.com Subject: Re: [p2pi] Real life torrent statistics X-BeenThere: p2pi@ietf.org X-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="===============1411456707==" Sender: p2pi-bounces@ietf.org Errors-To: p2pi-bounces@ietf.org This is a multi-part message in MIME format. --===============1411456707== Content-Type: multipart/alternative; boundary="----=_NextPart_000_0035_01C90220.122F2B60" This is a multi-part message in MIME format. ------=_NextPart_000_0035_01C90220.122F2B60 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Quite frankly, I do not thing that collected statistics can support this or another point of view - it is too small set. I'll be glad to share more datapoints with this community - probably in few days. But just for reference from my past data collection - for popular http://tracker.prq.to/ tracker median size of the torrent swarm is 38 peers only. In general, I saw that 10% of TV-shows torrents are using 80% of peers. For movie content - it is about classical 20/80 ratio. _____ From: Laird Popkin [mailto:laird@pando.com] Sent: Tuesday, August 19, 2008 5:05 PM To: The 8472 Cc: p2pi@ietf.org; p4pwg@yahoogroups.com; Stas Khirman Subject: Re: [p2pi] Real life torrent statistics You're right that swarms with 10 peers can't be optimized - the p2p network will connect all 10 peers to each other and move as much data as possible. That being said, I suspect that a small number of very popular swarms that can be optimized would give significant impact on overall data flow, because one swarm with 20,000 peers balances out a lot of 'long tail'. Haiyong Xie of Yale mentioned to me that there was an analysis of this last year, by spidering one of the popular torrent web sites, and their conclusion was that well over 50% of the downloaders were in swarms with 100+ active peers, which is where they estimate that P4P optimization applies. Similarly, when I was in the music business and tracked such things, 2% of the files in the p2p networks accounted for the large majority of the download activity. I think that it would be a very interesting analysis, spidering some torrent web sites and seeing how the distribution of bandwidth is balanced between the 'head' and the 'long tail'. - Laird Popkin, CTO, Pando Networks mobile: 646/465-0570 ----- Original Message ----- From: "The 8472" To: "Stas Khirman" Cc: p2pi@ietf.org, p4pwg@yahoogroups.com Sent: Tuesday, August 19, 2008 4:40:39 PM (GMT-0800) America/Los_Angeles Subject: Re: [p2pi] Real life torrent statistics Stas Khirman wrote: To estimate a feasibility of ALTO/P4P for real life torrents , I collected information for peers from one of the most popular "PirateBay" torrents ( almost 20k peers) and maped their IPs to corresponded ASs. Please find attached my working notes with some interesting statistics. Ahh, there is a problem with this one. With torrents you have a significant long tail when it comes to swarm sizes and content. I'm not certain about distribution, but the long tail will probably outweight the... let's say top 100 torrents. Torrents with only 10-20 peers spread throughout several ASNs is a much harder to optimize than the top 100. This problem is aggreviated by swarm fragmentation due to private trackers and since bittorrent does not aim to coalesce all torrents with the same content, i.e. due to different piece sizes, file names etc. Also, I find it surprising geo distribution of the peers - majority were in UK , not in US (probably because content is available in US theaters). Places 3-5 taken by Sweden, Poland and Canada (in total - more peers then in US). This will probably be different if you sample torrents from regional trackers or torrents aimed at other audiences. During some DHT tracing on the weekend i saw a significant proportion of DHT traffic coming from asian countries, though i suspect an inefficient implementation of the DHT by a client that's popular in china to play some role in this distribution. Certainly, observed "heavy" neighboring of peers is a function of swarm size. I intend to investigate a few medium/small size swarms to have a multi-point picture for any future discussions. as i mentioned above we should try to get the big picture, i.e. how relevant the long tail is, measured in aggregate bandwidth. If the small torrents actually make up the bulk of the traffic then any solution will require a high degree of cooperation between ISPs, e.g. caches that cooperate with each other. -- The 8472 independent developer for the Azureus Vuze Bittorrent client _______________________________________________ p2pi mailing list p2pi@ietf.org https://www.ietf.org/mailman/listinfo/p2pi ------=_NextPart_000_0035_01C90220.122F2B60 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Quite frankly, I do not thing that collected statistics can support this or another point of view – = it is too small set. I’ll be glad to share more datapoints with this = community – probably in few days.

 

But just for reference from my past = data collection – for popular http://tracker.prq.to/ tracker median = size of the torrent swarm is 38 peers only. In general, I saw that 10% of = TV-shows torrents are using 80% of peers. For movie content – it is about classical = 20/80 ratio…

 

From: Laird = Popkin [mailto:laird@pando.com]
Sent: Tuesday, August 19, = 2008 5:05 PM
To: The 8472
Cc: p2pi@ietf.org; p4pwg@yahoogroups.com; Stas Khirman
Subject: Re: [p2pi] Real = life torrent statistics

 

You're right that swarms with 10 peers can't be optimized - = the p2p network will connect all 10 peers to each other and move as much = data as possible.

 

That being said, I suspect that a small number of very = popular swarms that can be optimized would give significant impact on overall = data flow, because one swarm with 20,000 peers balances out a lot of 'long = tail'. Haiyong Xie of Yale mentioned to me that there was an analysis of = this last year, by spidering one of the popular torrent web sites, and their conclusion was that well over 50% of the downloaders were in swarms with = 100+ active peers, which is where they estimate that P4P optimization = applies. Similarly, when I was in the music business and tracked such things, 2% of the = files in the p2p networks accounted for the large majority of the download = activity.

 

I think that it would be a very interesting analysis, = spidering some torrent web sites and seeing how the distribution of bandwidth is = balanced between the 'head' and the 'long tail'.


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

----- Original Message -----
From: "The 8472" <the8472@infinite-source.de>
To: "Stas Khirman" <stas@khirman.com>
Cc: p2pi@ietf.org, p4pwg@yahoogroups.com
Sent: Tuesday, August 19, 2008 4:40:39 PM (GMT-0800) = America/Los_Angeles
Subject: Re: [p2pi] Real life torrent statistics

Stas Khirman wrote:

To estimate a feasibility of = ALTO/P4P for real life torrents , I collected <ip,port> information for peers = from one of the most popular “PirateBay” torrents ( almost 20k peers) = and maped their IPs to corresponded ASs. Please find attached my working = notes with some interesting statistics.

Ahh, there is a problem with this = one. With torrents you have a significant long tail when it comes to swarm = sizes and content. I'm not certain about distribution, but the long tail will = probably outweight the... let's say top 100 torrents. Torrents with only 10-20 = peers spread throughout several ASNs is a much harder to optimize than the top = 100.
This problem is aggreviated by swarm fragmentation due to private = trackers and since bittorrent does not aim to coalesce all torrents with the same = content, i.e. due to different piece sizes, file names etc.

Also, I find it surprising geo distribution of the peers – majority were in UK , not in US (probably = because content is available in US theaters).  Places 3-5 taken by = Sweden, Poland and Canada (in total – more peers then in US).

This will probably be different = if you sample torrents from regional trackers or torrents aimed at other = audiences. During some DHT tracing on the weekend i saw a significant proportion of = DHT traffic coming from asian countries, though i suspect an inefficient implementation of the DHT by a client that's popular in china to play = some role in this distribution.

 

Certainly, observed = “heavy” neighboring of peers is a function of swarm size. I intend to = investigate a few medium/small size swarms to have a multi-point picture for any future discussions.

as i mentioned above we should = try to get the big picture, i.e. how relevant the long tail is, measured in = aggregate bandwidth. If the small torrents actually make up the bulk of the = traffic then any solution will require a high degree of cooperation between ISPs, = e.g. caches that cooperate with each other.

--
The 8472
independent developer for the Azureus Vuze Bittorrent client

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

------=_NextPart_000_0035_01C90220.122F2B60-- --===============1411456707== 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 --===============1411456707==-- From p2pi-bounces@ietf.org Mon Aug 25 12:25:50 2008 Return-Path: X-Original-To: p2pi-archive@ietf.org Delivered-To: ietfarch-p2pi-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 98DC33A696C; Mon, 25 Aug 2008 12:25:50 -0700 (PDT) X-Original-To: p2pi@core3.amsl.com Delivered-To: p2pi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A9DE53A696C for ; Mon, 25 Aug 2008 12:25:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.11 X-Spam-Level: X-Spam-Status: No, score=-5.11 tagged_above=-999 required=5 tests=[BAYES_05=-1.11, 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 2K4fEdxsuFZY for ; Mon, 25 Aug 2008 12:25:48 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id 2D1D23A68B3 for ; Mon, 25 Aug 2008 12:25:48 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.32,266,1217808000"; d="scan'208";a="69219791" Received: from sjc12-sbr-sw3-3f5.cisco.com (HELO imail.cisco.com) ([172.19.96.182]) by sj-iport-1.cisco.com with ESMTP; 25 Aug 2008 19:25:35 +0000 Received: from stealth-10-32-245-152.cisco.com ([10.32.245.152]) by imail.cisco.com (8.12.11/8.12.10) with ESMTP id m7PJ0ssv009877 for ; Mon, 25 Aug 2008 12:00:54 -0700 Message-Id: From: David R Oran To: p2pi@ietf.org In-Reply-To: <48AAD5EF.5030303@alcatel-lucent.com> Mime-Version: 1.0 (Apple Message framework v928.1) Date: Mon, 25 Aug 2008 15:25:33 -0400 References: <489B498B.4040804@telecomitalia.it> <20080811143531.GA18911@net.t-labs.tu-berlin.de> <20080811165443.GB18911@net.t-labs.tu-berlin.de> <1219070969.6961.37.camel@bart2> <48AAD5EF.5030303@alcatel-lucent.com> X-Mailer: Apple Mail (2.928.1) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2079; t=1219690855; x=1220554855; c=relaxed/simple; s=oregon; h=To:Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=oran@cisco.com; z=From:=20David=20R=20Oran=20 |Subject:=20Re=3A=20[p2pi]=20Information=20in=20an=20ALTO=2 0protocol |Sender:=20 |To:=20p2pi@ietf.org; bh=/J/6xfvIhiCfAiRk47MshCqQLaFpNf5na4TjokWABBQ=; b=evo6nunsQWWz/ZuLRpAHwLAPxujtN+wHaPfI9niU4HdPjBJyar56bA5wyV ZHjl0QBmTtj5oJ2gw7x0GP+qDeK/dClCfMEd6IHq1rkEQ18eS/S9YTKZgbjK /9AO9fHnoi; Authentication-Results: imail.cisco.com; header.From=oran@cisco.com; dkim=pass ( sig from cisco.com/oregon verified; ); Subject: Re: [p2pi] Information in an ALTO protocol X-BeenThere: p2pi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: P2P Infrastructure Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: 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 Aug 19, 2008, at 10:17 AM, Vijay K. Gurbani wrote: > Fabio Hecht wrote: >> in this case, would an ALTO Server query other ALTO Servers to gather >> this information? Because, from an ISP point of view, the ALTO Server >> would not know what the last-hop bandwidth is for every other peer. >> Would the protocol then be the same used by the overlay applications? > > Fabio: At this point, not much thought has been given to an Inter-ALTO > server protocol or what its form may be. We are trying to get our > hands around the needed information that could serve as the building > block for an ALTO server - ALTO client protocol. > This is only tangentially related to the main topic of this thread, but since it occurred to me on reading this exchange about server chaining I thought I'd mention it here: Many client/server protocols are were initially designed to be strictly two party, with no architectural support for proxies or other stateful intermediaries (HTTP and RTSP come to mind...there are likely many others). It may behoove us to build proxy capability into ALTO from day 1, since it will almost inevitably have to be added later at some level of pain, perhaps large, and almost assuredly some undesirable security tradeoffs. This probably involves at least the following: - separating our end-to-end from ho--by hop (transport layer?) security - clear data model separation between things used to "route" requests and things used to interpret queries. - a flexible addressing model - a way to aggregate and summarize in responses and likely a bunch of other considerations I'm missing in the above. DaveO. > 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 Aug 25 14:01: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 1C8C13A6BFC; Mon, 25 Aug 2008 14:01: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 99F1C3A6BCB for ; Mon, 25 Aug 2008 14:01:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.002 X-Spam-Level: X-Spam-Status: No, score=0.002 tagged_above=-999 required=5 tests=[BAYES_50=0.001, 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 N6N42JA3qUyR for ; Mon, 25 Aug 2008 14:01:48 -0700 (PDT) Received: from mout.perfora.net (mout.perfora.net [74.208.4.197]) by core3.amsl.com (Postfix) with ESMTP id 612FA3A6BD0 for ; Mon, 25 Aug 2008 14:01:48 -0700 (PDT) Received: from s73602 (w173.z064002096.dfw-tx.dsl.cnc.net [64.2.96.173]) by mrelay.perfora.net (node=mrus0) with ESMTP (Nemesis) id 0MKp8S-1KXjBM3yj6-0005mP; Mon, 25 Aug 2008 17:01:03 -0400 Message-ID: <00d701c906f5$c5f2aee0$6501a8c0@china.huawei.com> From: "Spencer Dawkins" To: "David R Oran" , References: <489B498B.4040804@telecomitalia.it> <20080811143531.GA18911@net.t-labs.tu-berlin.de> <20080811165443.GB18911@net.t-labs.tu-berlin.de><1219070969.6961.37.camel@bart2><48AAD5EF.5030303@alcatel-lucent.com> Date: Mon, 25 Aug 2008 16:01:38 -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: V01U2FsdGVkX18OFym7vPmxMX9G4T7gI+gZA+9oE0fbVNELicX z8WvNbrK8F13ofu+2V7U6+Y090T43ynda/GUCEaEHG1Dh5dBs1 G1IUtfqCMEveZdvrzkELYgbgU7DFMFsQBNSpaqriKQ= Subject: Re: [p2pi] Information in an ALTO protocol X-BeenThere: p2pi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: P2P Infrastructure Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: 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 strongly agree with Dave. I might suggest a couple of additions: - the hop-by-hop and end-to-end distinction is important for a lot of other stuff besides security, in addition to security, and - ("snork!") I'm not sure whether a NAT traversal story (which could be "use ICE, stupid") would be appropriate, but best to consider that up front as well. Thanks, Spencer From: "David R Oran" > This is only tangentially related to the main topic of this thread, > but since it occurred to me on reading this exchange about server > chaining I thought I'd mention it here: > > Many client/server protocols are were initially designed to be > strictly two party, with no architectural support for proxies or other > stateful intermediaries (HTTP and RTSP come to mind...there are likely > many others). > > It may behoove us to build proxy capability into ALTO from day 1, > since it will almost inevitably have to be added later at some level > of pain, perhaps large, and almost assuredly some undesirable security > tradeoffs. > > This probably involves at least the following: > - separating our end-to-end from ho--by hop (transport layer?) security > - clear data model separation between things used to "route" requests > and things used to interpret queries. > - a flexible addressing model > - a way to aggregate and summarize in responses > > and likely a bunch of other considerations I'm missing in the above. _______________________________________________ p2pi mailing list p2pi@ietf.org https://www.ietf.org/mailman/listinfo/p2pi From p2pi-bounces@ietf.org Wed Aug 27 09:52: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 C2CB23A691F; Wed, 27 Aug 2008 09:52: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 31C3D3A682B for ; Wed, 27 Aug 2008 09:52:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.65 X-Spam-Level: X-Spam-Status: No, score=-0.65 tagged_above=-999 required=5 tests=[AWL=1.950, 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 HLWN3ssACzuj for ; Wed, 27 Aug 2008 09:52:03 -0700 (PDT) Received: from gateout01.mbox.net (gateout01.mbox.net [165.212.64.21]) by core3.amsl.com (Postfix) with ESMTP id 083F23A68F4 for ; Wed, 27 Aug 2008 09:52:02 -0700 (PDT) Received: from gateout01.mbox.net (gwsmtp.usa.net [165.212.65.102]) by gateout01.mbox.net (Postfix) with ESMTP id 6DD8ECD60B; Wed, 27 Aug 2008 16:51:02 +0000 (GMT) Received: from GW1.EXCHPROD.USA.NET [165.212.116.254] by gateout01.mbox.net via smtad (C8.MAIN.3.45S) with ESMTP id XID788mHAqzc6421Xo1; Wed, 27 Aug 2008 16:51:02 -0000 X-USANET-Source: 165.212.116.254 IN ldusseault@commerce.net GW1.EXCHPROD.USA.NET X-USANET-MsgId: XID788mHAqzc6421Xo1 Received: from [10.1.1.130] ([157.22.41.236]) by GW1.EXCHPROD.USA.NET over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Wed, 27 Aug 2008 10:51:01 -0600 Message-Id: <91D210DB-C42D-4430-A46C-B6CE10AEA4AE@commerce.net> From: Lisa Dusseault To: David R Oran In-Reply-To: Mime-Version: 1.0 (Apple Message framework v928.1) Date: Wed, 27 Aug 2008 09:51:00 -0700 References: <489B498B.4040804@telecomitalia.it> <20080811143531.GA18911@net.t-labs.tu-berlin.de> <20080811165443.GB18911@net.t-labs.tu-berlin.de> <1219070969.6961.37.camel@bart2> <48AAD5EF.5030303@alcatel-lucent.com> X-Mailer: Apple Mail (2.928.1) X-OriginalArrivalTime: 27 Aug 2008 16:51:02.0159 (UTC) FILETIME=[16A7E1F0:01C90865] Cc: p2pi@ietf.org Subject: Re: [p2pi] Information in an ALTO protocol X-BeenThere: p2pi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: P2P Infrastructure Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: 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 Aug 25, 2008, at 12:25 PM, David R Oran wrote: > > Many client/server protocols are were initially designed to be > strictly two party, with no architectural support for proxies or other > stateful intermediaries (HTTP and RTSP come to mind...there are likely > many others). > > It may behoove us to build proxy capability into ALTO from day 1, > since it will almost inevitably have to be added later at some level > of pain, perhaps large, and almost assuredly some undesirable security > tradeoffs. You're making the assumption now, that ALTO will need to add proxies or intermediaries ("will almost inevitability"). I don't really have evidence that you're wrong about that, but I also don't see the use cases right now. Do you have anything specific in mind? > > > This probably involves at least the following: > - separating our end-to-end from ho--by hop (transport layer?) > security > - clear data model separation between things used to "route" requests > and things used to interpret queries. > - a flexible addressing model > - a way to aggregate and summarize in responses These are good architectural principles to remember while writing and reviewing drafts, assuming they can be followed without falling into the trap of designing the be-all and end-all system. -- Lisa > > > and likely a bunch of other considerations I'm missing in the above. > > DaveO. > >> Thanks, >> >> - vijay >> -- >> Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent >> 2701 Lucent Lane, Rm. 9F-546, Lisle, Illinois 60532 (USA) >> Email: vkg@{alcatel-lucent.com,bell-labs.com,acm.org} >> WWW: http://www.alcatel-lucent.com/bell-labs >> _______________________________________________ >> p2pi mailing list >> p2pi@ietf.org >> https://www.ietf.org/mailman/listinfo/p2pi > > _______________________________________________ > p2pi mailing list > p2pi@ietf.org > https://www.ietf.org/mailman/listinfo/p2pi > _______________________________________________ p2pi mailing list p2pi@ietf.org https://www.ietf.org/mailman/listinfo/p2pi From p2pi-bounces@ietf.org Wed Aug 27 09:59: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 560433A6ACF; Wed, 27 Aug 2008 09:59: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 C80493A694C for ; Wed, 27 Aug 2008 09:59:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FMiPblAkCjTD for ; Wed, 27 Aug 2008 09:59:49 -0700 (PDT) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by core3.amsl.com (Postfix) with ESMTP id E9EC23A6ACF for ; Wed, 27 Aug 2008 09:59:49 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.32,279,1217808000"; d="scan'208";a="43627661" Received: from sjc12-sbr-sw3-3f5.cisco.com (HELO imail.cisco.com) ([172.19.96.182]) by sj-iport-5.cisco.com with ESMTP; 27 Aug 2008 16:58:12 +0000 Received: from stealth-10-32-245-150.cisco.com ([10.32.245.150]) by imail.cisco.com (8.12.11/8.12.10) with ESMTP id m7RGXNb7022083; Wed, 27 Aug 2008 09:33:23 -0700 Message-Id: <59F52543-CDB0-41FB-991D-7985E8237559@cisco.com> From: David R Oran To: Lisa Dusseault In-Reply-To: <91D210DB-C42D-4430-A46C-B6CE10AEA4AE@commerce.net> Mime-Version: 1.0 (Apple Message framework v928.1) Date: Wed, 27 Aug 2008 12:58:09 -0400 References: <489B498B.4040804@telecomitalia.it> <20080811143531.GA18911@net.t-labs.tu-berlin.de> <20080811165443.GB18911@net.t-labs.tu-berlin.de> <1219070969.6961.37.camel@bart2> <48AAD5EF.5030303@alcatel-lucent.com> <91D210DB-C42D-4430-A46C-B6CE10AEA4AE@commerce.net> X-Mailer: Apple Mail (2.928.1) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2463; t=1219854804; x=1220718804; c=relaxed/simple; s=oregon; h=To:Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=oran@cisco.com; z=From:=20David=20R=20Oran=20 |Subject:=20Re=3A=20[p2pi]=20Information=20in=20an=20ALTO=2 0protocol |Sender:=20 |To:=20Lisa=20Dusseault=20; bh=uOVSMym808VVziLJjjh4RuZICCjKddFhOjYHyzGzc94=; b=aAhdGwH8RX6p29vR3YS0HPO2mi3Ycl8xglxJ2aUvphWy2BCVQFcvQzCnXk 6NoSfIIVK9uwcetmmSSpg7hcv9p0j0ra2AOSJPXuBCnnr1oqqKpH5W6mMyAo nk5vpGy+yT; Authentication-Results: imail.cisco.com; header.From=oran@cisco.com; dkim=pass ( sig from cisco.com/oregon verified; ); Cc: p2pi@ietf.org Subject: Re: [p2pi] Information in an ALTO protocol X-BeenThere: p2pi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: P2P Infrastructure Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: 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 Aug 27, 2008, at 12:51 PM, Lisa Dusseault wrote: > > On Aug 25, 2008, at 12:25 PM, David R Oran wrote: >> >> Many client/server protocols are were initially designed to be >> strictly two party, with no architectural support for proxies or >> other >> stateful intermediaries (HTTP and RTSP come to mind...there are >> likely >> many others). >> >> It may behoove us to build proxy capability into ALTO from day 1, >> since it will almost inevitably have to be added later at some level >> of pain, perhaps large, and almost assuredly some undesirable >> security >> tradeoffs. > > You're making the assumption now, that ALTO will need to add proxies > or intermediaries ("will almost inevitability"). I don't really > have evidence that you're wrong about that, but I also don't see the > use cases right now. Do you have anything specific in mind? > Yeah: 1. my ISP runs a redirector to their "transparent" ALTO server so I can't get directly to the one I want to get to. 2. My P2P "community" wants to cache and do lookaside stuff to provide more globally optimized swarm spreading. So, I use their Alto "proxy" and let them help decide who needs to be asked for what. >> >> >> This probably involves at least the following: >> - separating our end-to-end from ho--by hop (transport layer?) >> security >> - clear data model separation between things used to "route" requests >> and things used to interpret queries. >> - a flexible addressing model >> - a way to aggregate and summarize in responses > > These are good architectural principles to remember while writing > and reviewing drafts, assuming they can be followed without falling > into the trap of designing the be-all and end-all system. > > -- Lisa > >> >> >> and likely a bunch of other considerations I'm missing in the above. >> >> DaveO. >> >>> Thanks, >>> >>> - vijay >>> -- >>> Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent >>> 2701 Lucent Lane, Rm. 9F-546, Lisle, Illinois 60532 (USA) >>> Email: vkg@{alcatel-lucent.com,bell-labs.com,acm.org} >>> WWW: http://www.alcatel-lucent.com/bell-labs >>> _______________________________________________ >>> p2pi mailing list >>> p2pi@ietf.org >>> https://www.ietf.org/mailman/listinfo/p2pi >> >> _______________________________________________ >> p2pi mailing list >> p2pi@ietf.org >> https://www.ietf.org/mailman/listinfo/p2pi >> > _______________________________________________ p2pi mailing list p2pi@ietf.org https://www.ietf.org/mailman/listinfo/p2pi From p2pi-bounces@ietf.org Wed Aug 27 10:18: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 EEB4A3A6B38; Wed, 27 Aug 2008 10:18: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 4AF483A6A76 for ; Wed, 27 Aug 2008 10:18:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.004 X-Spam-Level: X-Spam-Status: No, score=-1.004 tagged_above=-999 required=5 tests=[AWL=0.355, 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 2m+3mJK0rJwG for ; Wed, 27 Aug 2008 10:18:56 -0700 (PDT) Received: from gateout02.mbox.net (gateout02.mbox.net [165.212.64.22]) by core3.amsl.com (Postfix) with ESMTP id 643AB3A6B2F for ; Wed, 27 Aug 2008 10:18:56 -0700 (PDT) Received: from gateout02 (gwsmtp.usa.net [165.212.65.102]) by gateout02.mbox.net (Postfix) with ESMTP id ED55F4BDA7E; Wed, 27 Aug 2008 17:18:52 +0000 (GMT) Received: from GW1.EXCHPROD.USA.NET [165.212.116.254] by gateout02 via smtad (C8.MAIN.3.45S) with ESMTP id XID360mHARs27488Xo2; Wed, 27 Aug 2008 17:18:52 -0000 X-USANET-Source: 165.212.116.254 IN ldusseault@commerce.net GW1.EXCHPROD.USA.NET X-USANET-MsgId: XID360mHARs27488Xo2 Received: from [10.1.1.130] ([157.22.41.236]) by GW1.EXCHPROD.USA.NET over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Wed, 27 Aug 2008 11:18:52 -0600 Message-Id: <3D7E15E8-C27C-4B12-9A6B-627EA6767627@commerce.net> From: Lisa Dusseault To: David R Oran In-Reply-To: <59F52543-CDB0-41FB-991D-7985E8237559@cisco.com> Mime-Version: 1.0 (Apple Message framework v928.1) Date: Wed, 27 Aug 2008 10:18:51 -0700 References: <489B498B.4040804@telecomitalia.it> <20080811143531.GA18911@net.t-labs.tu-berlin.de> <20080811165443.GB18911@net.t-labs.tu-berlin.de> <1219070969.6961.37.camel@bart2> <48AAD5EF.5030303@alcatel-lucent.com> <91D210DB-C42D-4430-A46C-B6CE10AEA4AE@commerce.net> <59F52543-CDB0-41FB-991D-7985E8237559@cisco.com> X-Mailer: Apple Mail (2.928.1) X-OriginalArrivalTime: 27 Aug 2008 17:18:52.0742 (UTC) FILETIME=[FA669E60:01C90868] Cc: p2pi@ietf.org Subject: Re: [p2pi] Information in an ALTO protocol X-BeenThere: p2pi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: P2P Infrastructure Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: 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 Aug 27, 2008, at 9:58 AM, David R Oran wrote: > > On Aug 27, 2008, at 12:51 PM, Lisa Dusseault wrote: >> >> On Aug 25, 2008, at 12:25 PM, David R Oran wrote: >>> >>> Many client/server protocols are were initially designed to be >>> strictly two party, with no architectural support for proxies or >>> other >>> stateful intermediaries (HTTP and RTSP come to mind...there are >>> likely >>> many others). >>> >>> It may behoove us to build proxy capability into ALTO from day 1, >>> since it will almost inevitably have to be added later at some level >>> of pain, perhaps large, and almost assuredly some undesirable >>> security >>> tradeoffs. >> >> You're making the assumption now, that ALTO will need to add >> proxies or intermediaries ("will almost inevitability"). I don't >> really have evidence that you're wrong about that, but I also don't >> see the use cases right now. Do you have anything specific in mind? >> This helps, and leads to more questions... > Yeah: > 1. my ISP runs a redirector to their "transparent" ALTO server so I > can't get directly to the one I want to get to. How does this use case affect protocol design in the short term? Other than the agreed principles of good design, I mean. An ISP can run any kind of internal protocol and we're a long way away from generalized interoperability between agents deployed within an ISP. > > 2. My P2P "community" wants to cache and do lookaside stuff to > provide more globally optimized swarm spreading. So, I use their > Alto "proxy" and let them help decide who needs to be asked for what. This is a use case I've been talking to people about in a different context, and it's a difficult one. If the swarm's Alto server can ask as itself for useful information, probably public information, then that's easy. But if the swarm's Alto server has to ask for information "on behalf of" a swarm member, then we have difficult delegation and permission issues. I had assumed we wouldn't want to tackle that in the first batch of ALTO work. But even if the swarm's Alto server can get information from other places, publically or through delegation, and compile that or forward it, the next thing to bring into question is whether the end consumer of the information needs to know where the information came from originally. I don't even know what lesson one can draw from HTTP but I'd probably be able to put up a good argument for learning that proxy information is mostly useless. Most proxy and forwarding information that actually appears in HTTP traffic is ignored by clients, and most traffic does not even go through non-transparent proxies. IOW, most proxying of HTTP, and all compiling of responses, happens transparently, and does not use the protocol headers that were designed for handling intermediaries. As devil's advocate I'm now prepared for my argument to be totally demolished... Lisa > > > >>> >>> >>> This probably involves at least the following: >>> - separating our end-to-end from ho--by hop (transport layer?) >>> security >>> - clear data model separation between things used to "route" >>> requests >>> and things used to interpret queries. >>> - a flexible addressing model >>> - a way to aggregate and summarize in responses >> >> These are good architectural principles to remember while writing >> and reviewing drafts, assuming they can be followed without falling >> into the trap of designing the be-all and end-all system. >> >> -- Lisa >> >>> _______________________________________________ p2pi mailing list p2pi@ietf.org https://www.ietf.org/mailman/listinfo/p2pi From p2pi-bounces@ietf.org Wed Aug 27 10:25: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 B33443A6AC3; Wed, 27 Aug 2008 10:25: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 7C4B83A6AC3 for ; Wed, 27 Aug 2008 10:25:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.457 X-Spam-Level: X-Spam-Status: No, score=-5.457 tagged_above=-999 required=5 tests=[AWL=-0.098, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, SARE_LWSHORTT=1.24] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cuzb+Lsg55w7 for ; Wed, 27 Aug 2008 10:25:34 -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 4F5B83A684A for ; Wed, 27 Aug 2008 10:25:34 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.32,279,1217808000"; d="scan'208";a="97612868" Received: from sjc12-sbr-sw3-3f5.cisco.com (HELO imail.cisco.com) ([172.19.96.182]) by sj-iport-3.cisco.com with ESMTP; 27 Aug 2008 17:25:06 +0000 Received: from stealth-10-32-245-150.cisco.com ([10.32.245.150]) by imail.cisco.com (8.12.11/8.12.10) with ESMTP id m7RH0H2Z023222; Wed, 27 Aug 2008 10:00:18 -0700 Message-Id: <50EBE8E6-2819-457E-BB21-94184CD4BD32@cisco.com> From: David R Oran To: Lisa Dusseault In-Reply-To: <3D7E15E8-C27C-4B12-9A6B-627EA6767627@commerce.net> Mime-Version: 1.0 (Apple Message framework v928.1) Date: Wed, 27 Aug 2008 13:25:03 -0400 References: <489B498B.4040804@telecomitalia.it> <20080811143531.GA18911@net.t-labs.tu-berlin.de> <20080811165443.GB18911@net.t-labs.tu-berlin.de> <1219070969.6961.37.camel@bart2> <48AAD5EF.5030303@alcatel-lucent.com> <91D210DB-C42D-4430-A46C-B6CE10AEA4AE@commerce.net> <59F52543-CDB0-41FB-991D-7985E8237559@cisco.com> <3D7E15E8-C27C-4B12-9A6B-627EA6767627@commerce.net> X-Mailer: Apple Mail (2.928.1) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=4326; t=1219856418; x=1220720418; c=relaxed/simple; s=oregon; h=To:Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=oran@cisco.com; z=From:=20David=20R=20Oran=20 |Subject:=20Re=3A=20[p2pi]=20Information=20in=20an=20ALTO=2 0protocol |Sender:=20 |To:=20Lisa=20Dusseault=20; bh=64NEK3cWud4aEvtxXnx9rl5M9A43D+mJZN5Pv5/g2dw=; b=a/Ukum6K3FywWkZ7wRnu9vhTiV1+dHMAQUysOgfNBvDZWCRNJvPv3so2fD MGoRVb2lnhR7sa3Ck34qTgLGQZHaGPfrI2VWqPuoCtG2B+R3zk0ttjlXoIO1 3KYUf2KK+o; Authentication-Results: imail.cisco.com; header.From=oran@cisco.com; dkim=pass ( sig from cisco.com/oregon verified; ); Cc: p2pi@ietf.org Subject: Re: [p2pi] Information in an ALTO protocol X-BeenThere: p2pi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: P2P Infrastructure Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: 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 Aug 27, 2008, at 1:18 PM, Lisa Dusseault wrote: > > On Aug 27, 2008, at 9:58 AM, David R Oran wrote: >> >> On Aug 27, 2008, at 12:51 PM, Lisa Dusseault wrote: >>> >>> On Aug 25, 2008, at 12:25 PM, David R Oran wrote: >>>> >>>> Many client/server protocols are were initially designed to be >>>> strictly two party, with no architectural support for proxies or >>>> other >>>> stateful intermediaries (HTTP and RTSP come to mind...there are >>>> likely >>>> many others). >>>> >>>> It may behoove us to build proxy capability into ALTO from day 1, >>>> since it will almost inevitably have to be added later at some >>>> level >>>> of pain, perhaps large, and almost assuredly some undesirable >>>> security >>>> tradeoffs. >>> >>> You're making the assumption now, that ALTO will need to add >>> proxies or intermediaries ("will almost inevitability"). I don't >>> really have evidence that you're wrong about that, but I also >>> don't see the use cases right now. Do you have anything specific >>> in mind? >>> > > This helps, and leads to more questions... > >> Yeah: >> 1. my ISP runs a redirector to their "transparent" ALTO server so I >> can't get directly to the one I want to get to. > > How does this use case affect protocol design in the short term? > Other than the agreed principles of good design, I mean. An ISP can > run any kind of internal protocol and we're a long way away from > generalized interoperability between agents deployed within an ISP. > Like any middlebox, it's helpful if there's a clean separation between the things the middlebox can fool with and the things that get integrity protected end-to-end. >> >> 2. My P2P "community" wants to cache and do lookaside stuff to >> provide more globally optimized swarm spreading. So, I use their >> Alto "proxy" and let them help decide who needs to be asked for what. > > This is a use case I've been talking to people about in a different > context, and it's a difficult one. If the swarm's Alto server can > ask as itself for useful information, probably public information, > then that's easy. But if the swarm's Alto server has to ask for > information "on behalf of" a swarm member, then we have difficult > delegation and permission issues. I had assumed we wouldn't want to > tackle that in the first batch of ALTO work. I agree this is difficult in general. It's just been my experience that adding proxy hooks to a protocol that did not envision them has been messy and painful. That's not to say I necessarily believe we will need the full generality you talk about below. > But even if the swarm's Alto server can get information from other > places, publically or through delegation, and compile that or > forward it, the next thing to bring into question is whether the end > consumer of the information needs to know where the information came > from originally. I don't even know what lesson one can draw from > HTTP but I'd probably be able to put up a good argument for learning > that proxy information is mostly useless. Most proxy and forwarding > information that actually appears in HTTP traffic is ignored by > clients, and most traffic does not even go through non-transparent > proxies. IOW, most proxying of HTTP, and all compiling of > responses, happens transparently, and does not use the protocol > headers that were designed for handling intermediaries. > Do you think this was inherent, or because it was a bolt-on? > As devil's advocate I'm now prepared for my argument to be totally > demolished... > > Lisa > >> >> >> >>>> >>>> >>>> This probably involves at least the following: >>>> - separating our end-to-end from ho--by hop (transport layer?) >>>> security >>>> - clear data model separation between things used to "route" >>>> requests >>>> and things used to interpret queries. >>>> - a flexible addressing model >>>> - a way to aggregate and summarize in responses >>> >>> These are good architectural principles to remember while writing >>> and reviewing drafts, assuming they can be followed without >>> falling into the trap of designing the be-all and end-all system. >>> >>> -- Lisa >>> >>>> _______________________________________________ p2pi mailing list p2pi@ietf.org https://www.ietf.org/mailman/listinfo/p2pi From p2pi-bounces@ietf.org Wed Aug 27 10:35: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 3D64028C1A8; Wed, 27 Aug 2008 10:35: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 662BF28C1A8 for ; Wed, 27 Aug 2008 10:35:38 -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 O1OiXVJPcX0w for ; Wed, 27 Aug 2008 10:35:33 -0700 (PDT) Received: from exprod7og105.obsmtp.com (exprod7og105.obsmtp.com [64.18.2.163]) by core3.amsl.com (Postfix) with ESMTP id 4D73628C0E6 for ; Wed, 27 Aug 2008 10:35:33 -0700 (PDT) Received: from source ([66.129.228.6]) by exprod7ob105.postini.com ([64.18.6.12]) with SMTP; Wed, 27 Aug 2008 10:35:32 PDT Received: from antipi.jnpr.net ([10.10.2.34]) by p-emsmtp03.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 27 Aug 2008 10:20:07 -0700 Received: from proton.jnpr.net ([10.10.2.37]) by antipi.jnpr.net with Microsoft SMTPSVC(6.0.3790.1830); Wed, 27 Aug 2008 13:20:06 -0400 Received: from 172.23.1.107 ([172.23.1.107]) by proton.jnpr.net ([10.10.2.37]) with Microsoft Exchange Server HTTP-DAV ; Wed, 27 Aug 2008 17:20:06 +0000 User-Agent: Microsoft-Entourage/12.12.0.080729 Date: Wed, 27 Aug 2008 10:19:51 -0700 From: Reinaldo Penno To: David R Oran , Message-ID: Thread-Topic: [p2pi] Information in an ALTO protocol Thread-Index: AckIaR0gjGskvjjzf0uwyiqKQ2FHuw== In-Reply-To: Mime-version: 1.0 X-OriginalArrivalTime: 27 Aug 2008 17:20:06.0856 (UTC) FILETIME=[26938480:01C90869] Subject: Re: [p2pi] Information in an ALTO protocol X-BeenThere: p2pi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: P2P Infrastructure Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: p2pi-bounces@ietf.org Errors-To: p2pi-bounces@ietf.org I would like to also point out that we should strive to make ALTO as NAT friendly as possible. Thanks, Reinaldo On 8/25/08 12:25 PM, "David R Oran" wrote: > > On Aug 19, 2008, at 10:17 AM, Vijay K. Gurbani wrote: > >> Fabio Hecht wrote: >>> in this case, would an ALTO Server query other ALTO Servers to gather >>> this information? Because, from an ISP point of view, the ALTO Server >>> would not know what the last-hop bandwidth is for every other peer. >>> Would the protocol then be the same used by the overlay applications? >> >> Fabio: At this point, not much thought has been given to an Inter-ALTO >> server protocol or what its form may be. We are trying to get our >> hands around the needed information that could serve as the building >> block for an ALTO server - ALTO client protocol. >> > This is only tangentially related to the main topic of this thread, > but since it occurred to me on reading this exchange about server > chaining I thought I'd mention it here: > > Many client/server protocols are were initially designed to be > strictly two party, with no architectural support for proxies or other > stateful intermediaries (HTTP and RTSP come to mind...there are likely > many others). > > It may behoove us to build proxy capability into ALTO from day 1, > since it will almost inevitably have to be added later at some level > of pain, perhaps large, and almost assuredly some undesirable security > tradeoffs. > > This probably involves at least the following: > - separating our end-to-end from ho--by hop (transport layer?) security > - clear data model separation between things used to "route" requests > and things used to interpret queries. > - a flexible addressing model > - a way to aggregate and summarize in responses > > and likely a bunch of other considerations I'm missing in the above. > > DaveO. > >> Thanks, >> >> - vijay >> -- >> Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent >> 2701 Lucent Lane, Rm. 9F-546, Lisle, Illinois 60532 (USA) >> Email: vkg@{alcatel-lucent.com,bell-labs.com,acm.org} >> WWW: http://www.alcatel-lucent.com/bell-labs >> _______________________________________________ >> p2pi mailing list >> p2pi@ietf.org >> https://www.ietf.org/mailman/listinfo/p2pi > > _______________________________________________ > p2pi mailing list > p2pi@ietf.org > https://www.ietf.org/mailman/listinfo/p2pi _______________________________________________ p2pi mailing list p2pi@ietf.org https://www.ietf.org/mailman/listinfo/p2pi From p2pi-bounces@ietf.org Wed Aug 27 10:37: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 D38D428C1A8; Wed, 27 Aug 2008 10:37: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 3C00D3A684A for ; Wed, 27 Aug 2008 10:37:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.123 X-Spam-Level: X-Spam-Status: No, score=-1.123 tagged_above=-999 required=5 tests=[AWL=0.236, 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 NoKsvH5AzcAk for ; Wed, 27 Aug 2008 10:37:29 -0700 (PDT) Received: from gateout01.mbox.net (gateout01.mbox.net [165.212.64.21]) by core3.amsl.com (Postfix) with ESMTP id 4BF7F3A6C24 for ; Wed, 27 Aug 2008 10:37:29 -0700 (PDT) Received: from gateout01.mbox.net (gwsmtp.usa.net [165.212.65.102]) by gateout01.mbox.net (Postfix) with ESMTP id 99427CDC4B; Wed, 27 Aug 2008 17:37:24 +0000 (GMT) Received: from GW2.EXCHPROD.USA.NET [165.212.116.254] by gateout01.mbox.net via smtad (C8.MAIN.3.45S) with ESMTP id XID684mHARly1957Xo1; Wed, 27 Aug 2008 17:37:24 -0000 X-USANET-Source: 165.212.116.254 IN ldusseault@commerce.net GW2.EXCHPROD.USA.NET X-USANET-MsgId: XID684mHARly1957Xo1 Received: from [10.1.1.130] ([157.22.41.236]) by GW2.EXCHPROD.USA.NET over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Wed, 27 Aug 2008 11:37:23 -0600 Message-Id: <95B8804E-1B84-4ECA-BC68-9D4FE715F019@commerce.net> From: Lisa Dusseault To: David R Oran In-Reply-To: <50EBE8E6-2819-457E-BB21-94184CD4BD32@cisco.com> Mime-Version: 1.0 (Apple Message framework v928.1) Date: Wed, 27 Aug 2008 10:37:22 -0700 References: <489B498B.4040804@telecomitalia.it> <20080811143531.GA18911@net.t-labs.tu-berlin.de> <20080811165443.GB18911@net.t-labs.tu-berlin.de> <1219070969.6961.37.camel@bart2> <48AAD5EF.5030303@alcatel-lucent.com> <91D210DB-C42D-4430-A46C-B6CE10AEA4AE@commerce.net> <59F52543-CDB0-41FB-991D-7985E8237559@cisco.com> <3D7E15E8-C27C-4B12-9A6B-627EA6767627@commerce.net> <50EBE8E6-2819-457E-BB21-94184CD4BD32@cisco.com> X-Mailer: Apple Mail (2.928.1) X-OriginalArrivalTime: 27 Aug 2008 17:37:24.0322 (UTC) FILETIME=[90F44420:01C9086B] Cc: p2pi@ietf.org Subject: Re: [p2pi] Information in an ALTO protocol X-BeenThere: p2pi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: P2P Infrastructure Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: 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 Aug 27, 2008, at 10:25 AM, David R Oran wrote: > > On Aug 27, 2008, at 1:18 PM, Lisa Dusseault wrote: > >> >> On Aug 27, 2008, at 9:58 AM, David R Oran wrote: >>> >>> Yeah: >>> 1. my ISP runs a redirector to their "transparent" ALTO server so >>> I can't get directly to the one I want to get to. >> >> How does this use case affect protocol design in the short term? >> Other than the agreed principles of good design, I mean. An ISP >> can run any kind of internal protocol and we're a long way away >> from generalized interoperability between agents deployed within an >> ISP. >> > Like any middlebox, it's helpful if there's a clean separation > between the things the middlebox can fool with and the things that > get integrity protected end-to-end. > >>> >>> 2. My P2P "community" wants to cache and do lookaside stuff to >>> provide more globally optimized swarm spreading. So, I use their >>> Alto "proxy" and let them help decide who needs to be asked for >>> what. >> >> This is a use case I've been talking to people about in a different >> context, and it's a difficult one. If the swarm's Alto server can >> ask as itself for useful information, probably public information, >> then that's easy. But if the swarm's Alto server has to ask for >> information "on behalf of" a swarm member, then we have difficult >> delegation and permission issues. I had assumed we wouldn't want >> to tackle that in the first batch of ALTO work. > I agree this is difficult in general. It's just been my experience > that adding proxy hooks to a protocol that did not envision them has > been messy and painful. That's not to say I necessarily believe we > will need the full generality you talk about below. I agree we agree... :) I guess we'll see how this plays out in protocol design, and it will be at least amusing and perhaps useful to do an exercise imagining how an ALTO base protocol can or should be extended before it's baked. > >> But even if the swarm's Alto server can get information from other >> places, publically or through delegation, and compile that or >> forward it, the next thing to bring into question is whether the >> end consumer of the information needs to know where the information >> came from originally. I don't even know what lesson one can draw >> from HTTP but I'd probably be able to put up a good argument for >> learning that proxy information is mostly useless. Most proxy and >> forwarding information that actually appears in HTTP traffic is >> ignored by clients, and most traffic does not even go through non- >> transparent proxies. IOW, most proxying of HTTP, and all compiling >> of responses, happens transparently, and does not use the protocol >> headers that were designed for handling intermediaries. >> > Do you think this was inherent, or because it was a bolt-on? This I do not know. I have a gut feeling it's inherent. Perhaps meta- information isn't as useful as we programmers usually think it is? There's definitely a pattern across protocols, whether the meta- information is provided initially or as a bolt-on, of that being less used than anticipated. This might be random rather than a pattern -- just a natural product of designing a bunch of stuff and being wrong about a random selection of features being useful. It's too loose to nail down, at least for me. Lisa _______________________________________________ p2pi mailing list p2pi@ietf.org https://www.ietf.org/mailman/listinfo/p2pi From p2pi-bounces@ietf.org Wed Aug 27 11:31: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 8F7793A6C53; Wed, 27 Aug 2008 11:31: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 4852F3A6C53 for ; Wed, 27 Aug 2008 11:31:55 -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 LFPf4kBvU02y for ; Wed, 27 Aug 2008 11:31:54 -0700 (PDT) Received: from pacdcimo01.cable.comcast.com (PacdcIMO01.cable.comcast.com [24.40.8.145]) by core3.amsl.com (Postfix) with ESMTP id AF5433A6C65 for ; Wed, 27 Aug 2008 11:31:53 -0700 (PDT) Received: from ([24.40.15.118]) by pacdcimo01.cable.comcast.com with ESMTP id 5503620.12447198; Wed, 27 Aug 2008 14:31:19 -0400 Received: from PACDCEXCMB06.cable.comcast.com ([24.40.15.22]) by PACDCEXCSMTP04.cable.comcast.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 27 Aug 2008 14:31:18 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 27 Aug 2008 14:31:02 -0400 Message-ID: <74CCBBDF76102846AFA7B29F3A98D3F60107C3B8@PACDCEXCMB06.cable.comcast.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [p2pi] Information in an ALTO protocol Thread-Index: AckIZmMHLRVE7huQSh65u5H4gJUhNQADKwEQ From: "Woundy, Richard" To: , X-OriginalArrivalTime: 27 Aug 2008 18:31:18.0658 (UTC) FILETIME=[18C4C620:01C90873] Cc: p2pi@ietf.org Subject: Re: [p2pi] Information in an ALTO protocol X-BeenThere: p2pi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: P2P Infrastructure Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: p2pi-bounces@ietf.org Errors-To: p2pi-bounces@ietf.org >1. my ISP runs a redirector to their "transparent" ALTO server so I can't get directly to the one I want to get to. I'm not sure I understand the motivation or rationale for an ISP to run a "transparent ALTO server". First, my understanding is that ISPs would not require users to make ALTO queries for usage. So if the ISP intercepts ALTO messages, then users could stop sending ALTO messages altogether, and/or send 'alt-ALTO' messages that are not intercepted by the ISP and are processed by the alt-ALTO server desired by the user. So it would seem that ISP interception of ALTO messages would be self-defeating for the ISP. Second, ALTO clients may include P2P clients and trackers, among other entities. ALTO requests from (typically off-net) P2P trackers would be difficult if not impossible for the ISP to intercept. The premise of the ALTO protocol is that both the user and ISP benefit from its usage, right? So why would a 'transparent ALTO server' even be necessary for the ISP? I am not opposed to the concept of the non-ISP ALTO server, I just don't understand why the ISP would be incented to intercept those requests. -- Rich ----- Original Message ----- From: p2pi-bounces@ietf.org To: Lisa Dusseault Cc: p2pi@ietf.org Sent: Wed Aug 27 12:58:09 2008 Subject: Re: [p2pi] Information in an ALTO protocol On Aug 27, 2008, at 12:51 PM, Lisa Dusseault wrote: > > On Aug 25, 2008, at 12:25 PM, David R Oran wrote: >> >> Many client/server protocols are were initially designed to be >> strictly two party, with no architectural support for proxies or >> other >> stateful intermediaries (HTTP and RTSP come to mind...there are >> likely >> many others). >> >> It may behoove us to build proxy capability into ALTO from day 1, >> since it will almost inevitably have to be added later at some level >> of pain, perhaps large, and almost assuredly some undesirable >> security >> tradeoffs. > > You're making the assumption now, that ALTO will need to add proxies > or intermediaries ("will almost inevitability"). I don't really > have evidence that you're wrong about that, but I also don't see the > use cases right now. Do you have anything specific in mind? > Yeah: 1. my ISP runs a redirector to their "transparent" ALTO server so I can't get directly to the one I want to get to. 2. My P2P "community" wants to cache and do lookaside stuff to provide more globally optimized swarm spreading. So, I use their Alto "proxy" and let them help decide who needs to be asked for what. >> >> >> This probably involves at least the following: >> - separating our end-to-end from ho--by hop (transport layer?) >> security >> - clear data model separation between things used to "route" requests >> and things used to interpret queries. >> - a flexible addressing model >> - a way to aggregate and summarize in responses > > These are good architectural principles to remember while writing > and reviewing drafts, assuming they can be followed without falling > into the trap of designing the be-all and end-all system. > > -- Lisa > >> >> >> and likely a bunch of other considerations I'm missing in the above. >> >> DaveO. >> >>> Thanks, >>> >>> - vijay >>> -- >>> Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent >>> 2701 Lucent Lane, Rm. 9F-546, Lisle, Illinois 60532 (USA) >>> Email: vkg@{alcatel-lucent.com,bell-labs.com,acm.org} >>> WWW: http://www.alcatel-lucent.com/bell-labs >>> _______________________________________________ >>> p2pi mailing list >>> p2pi@ietf.org >>> https://www.ietf.org/mailman/listinfo/p2pi >> >> _______________________________________________ >> p2pi mailing list >> p2pi@ietf.org >> https://www.ietf.org/mailman/listinfo/p2pi >> > _______________________________________________ p2pi mailing list p2pi@ietf.org https://www.ietf.org/mailman/listinfo/p2pi _______________________________________________ p2pi mailing list p2pi@ietf.org https://www.ietf.org/mailman/listinfo/p2pi From p2pi-bounces@ietf.org Wed Aug 27 13:49: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 960753A68FE; Wed, 27 Aug 2008 13:49: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 107193A68FE for ; Wed, 27 Aug 2008 13:49:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.837 X-Spam-Level: X-Spam-Status: No, score=0.837 tagged_above=-999 required=5 tests=[AWL=-1.300, BAYES_50=0.001, 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 SzVWOsKeScL3 for ; Wed, 27 Aug 2008 13:49:41 -0700 (PDT) Received: from paoakoavas10.cable.comcast.com (paoakoavas10.cable.comcast.com [208.17.35.59]) by core3.amsl.com (Postfix) with ESMTP id DA1BF3A68C2 for ; Wed, 27 Aug 2008 13:49:35 -0700 (PDT) Received: from ([10.52.116.30]) by paoakoavas10.cable.comcast.com with ESMTP id KP-TDCH7.49967412; Wed, 27 Aug 2008 16:49:20 -0400 Received: from PACDCEXCMB06.cable.comcast.com ([24.40.15.22]) by PAOAKEXCSMTP01.cable.comcast.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 27 Aug 2008 16:49:20 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 27 Aug 2008 16:48:41 -0400 Message-ID: <74CCBBDF76102846AFA7B29F3A98D3F60107C3BB@PACDCEXCMB06.cable.comcast.com> In-Reply-To: <20080819212816.GK25453@verdi> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [p2pi] Information in an ALTO protocol Thread-Index: AckCQrS3DnZ+Gcy9T9eM5JkEeAOZ7gGQC48g References: <74CCBBDF76102846AFA7B29F3A98D3F60107C32A@PACDCEXCMB06.cable.comcast.com><200808120901.m7C91q6H012752@bagheera.jungle.bt.co.uk><48A48779.60507@alcatel-lucent.com> <20080814204249.GS25453@verdi><48AB0761.7070507@alcatel-lucent.com> <20080819212816.GK25453@verdi> From: "Woundy, Richard" To: "John Leslie" , "Vijay K. Gurbani" X-OriginalArrivalTime: 27 Aug 2008 20:49:20.0251 (UTC) FILETIME=[60FB94B0:01C90886] Cc: p2pi@ietf.org Subject: Re: [p2pi] Information in an ALTO protocol X-BeenThere: p2pi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: P2P Infrastructure Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: p2pi-bounces@ietf.org Errors-To: p2pi-bounces@ietf.org (Catching up after coming back from vacation) >> Hmmm ... so I suspect that it is premature to say that last-hop >> bandwidth is out of scope? What do others think? >For myself, I think we'd be silly to rule it out-of-scope because we don't believe ISPs would agree to provide it. _Any_ question we ask an ISP may well receive a "none-of-your-business" reply. I might be OK with leaving this in scope. I stated two potential ISP issues in a previous email: the marketing concern (the ISP may be revealing its mix of regular versus premium customers to competitors) and traffic concentration concern (traffic may be drawn to fewer ISP links with premium customers). But I would agree with John that different ISPs may make different choices with regards to those concerns. My bigger concern, however, is the user privacy concern, about the ISP revealing to the general public about its premium/regular/economy customers. I agree that in many cases that this information may be actively measured, but that would seem to require at least some complicity by the end user (e.g. the end user's host needs to respond to the measurement traffic). So at least we should discuss whether a user opt-in or opt-out mechanism should be required for user-specific data like this. -- Rich -----Original Message----- From: p2pi-bounces@ietf.org [mailto:p2pi-bounces@ietf.org] On Behalf Of John Leslie Sent: Tuesday, August 19, 2008 5:28 PM To: Vijay K. Gurbani Cc: p2pi@ietf.org Subject: Re: [p2pi] Information in an ALTO protocol Vijay K. Gurbani wrote: > John Leslie wrote: >> Vijay K. Gurbani wrote: > >>> At present, we have the following discrete pieces of information >>> mentioned in the post-BoF charter: >>> >>> (1) Routing preferences >>> (2) Priority values >> >> These are a bit amorphous... > > Fair enough. Folks have suggested that preferences and priorities > along the lines of: > > _is_better_than_ > _is_better_than_ > > > How do you see that we can make these a bit more concrete? I get nervous when I see sorting by priority -- all it takes is one item changing and your whole sorting is invalidated. I'd like to gather information with very little tendency to change and report that. When we talk "local", we risk confusing different categories of "local". Are we talking a neighborhood, a geographic area where concentration is done, a routing domain, an Autonomous System, an island, a continent, or what? Also, if "local is better", better for what? I claim that what we really care about is congestion choke points. And obviously, we care the most about choke points which will actually be congested during our p2p transfer. So I'd prefer information such as - the uplink from this CIDR block is congested part of most days; when its latency exceeds 10 milliseconds, assume it's congested. - the downlink to this CIDR block is congested part of some days; when its latency exceeds 20 milliseconds, assume it's congested. - the up & down link from this CIDR block to our nearest peering point is seldom congested; it's minimum latency is 11 milliseconds. - our peering for CIDR blocks (a, b, c...) to AS #### is seldom congested. - our peering for these CIDR block to AS #### is occasionally congested; packets start dropping at a latency of 1.4 milliseconds. - peering for AS #### usually flows through AS #### These are all things that a NOC is aware of -- though admittedly management _may_ believe that admitting to these would somehow benefit their competiton. What the application wants to know, of course, is the above for its local ISP plus the corresponding info for the destination ISP's CIDR block. Being a simple-minded fellow, I thing it would be nice to be able to query both ISPs. (The query to the remote ISP, of course, could be done more efficiently by the tracker.) >>> (3) AS numbers >> >> Sometimes very useful; sometimes not... > > But arguably a low-hanging fruit that does indeed provide some > information that is helpful in the absence of any other guidance. AS numbers are very useful if we're trying to model the behavior of routers; but this is not always the case: rather often we're overwhelmed by local congestion. >>> (4) Geographic location >> >> Often wildly inaccurate, and even more often quite unrelated to >> network topology. Would be _very_ useful in an alternate universe where >> routing found next-hops _physically_ closer to the destination... > > Probably needs a bit more discussion on whether or not this is > valuable before discarding it. I don't mean to discard it; but I hesitate to put much weight on it. >>> 6 can be provided by the network operator or approximated using >>> synthetic coordinate systems and the like. >> >> Actual topology is likely to change without warning; so you should >> be prepared for it to prove wildly inaccurate. More often than not, >> it turns out to be only roughly approximated or hopelessly optimistic. > > Sure; synthetic coordinate systems have been designed with > approximations and opportunistic optimism in mind. While the > active guidance of an ISP in imparting topological information > is best, we should not preclude third-party services from > approximating the same to the best of their abilities. Actually, most of the stuff I listed at the beginning of this email can be reasonably well approximated by trackers cooperating with peers. IMHO, they'd be better advised to gather those data than chase synthetic coordinates. (YMMV) >>> Information that has been deemed out of scope based on list >>> discussion is: >>> >>> (1) Last hop bandwidth >> >> The most useful number yet listed, _if_ folks will give it to us >> and we interpret it correctly... > > Hmmm ... so I suspect that it is premature to say that last-hop > bandwidth is out of scope? What do others think? For myself, I think we'd be silly to rule it out-of-scope because we don't believe ISPs would agree to provide it. _Any_ question we ask an ISP may well receive a "none-of-your-business" reply. >>> What other sort of information should be a focus of ALTO? >> >> It would be rather useful to have "characteristics that indicate >> congestion" on a path. The applications are going to have to judge >> instantaneous congestion anyway, and basing that judgment on >> known characteristics rather than guesswork should speed progress >> towards an optimal mix. >> >> Jitter in the latency will be of interest to certain applications. > > I believe that these will fall squarely in TANA, if not some other > TSV WG. I don't mean to infringe on any other WG's charter: I just mean that jitter information would sometimes be helpful in choosing a peer. I venture no opinion on who should provide 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 Wed Aug 27 14:00: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 B8B143A68FE; Wed, 27 Aug 2008 14:00: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 5B6A93A68FE for ; Wed, 27 Aug 2008 14:00:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.409 X-Spam-Level: ** X-Spam-Status: No, score=2.409 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, J_CHICKENPOX_42=0.6, 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 rBTKVM6iPBPp for ; Wed, 27 Aug 2008 14:00:36 -0700 (PDT) Received: from mo-p00-ob.rzone.de (mo-p00-ob.rzone.de [81.169.146.162]) by core3.amsl.com (Postfix) with ESMTP id E3F553A6407 for ; Wed, 27 Aug 2008 14:00:35 -0700 (PDT) X-RZG-CLASS-ID: mo00 X-RZG-AUTH: :LW0Wek7mfO1Vkr5kPgWDvaJNkQpNEn8ylntakOISso1hE0McXW12o8AG24SD41nTjy5r24VXmPCLCjTebw== Received: from [192.168.1.78] (Tbf1f.t.pppool.de [89.55.191.31]) by post.webmailer.de (mrclete mo50) (RZmta 16.47) with ESMTP id z0330dk7RHn4VN for ; Wed, 27 Aug 2008 23:00:26 +0200 (MEST) (envelope-from: ) Message-ID: <48B5C064.70408@infinite-source.de> Date: Wed, 27 Aug 2008 23:00:20 +0200 From: The 8472 User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: p2pi@ietf.org Subject: [p2pi] Incentivization for P2P optimizations X-BeenThere: p2pi@ietf.org X-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="===============0156057148==" Sender: p2pi-bounces@ietf.org Errors-To: p2pi-bounces@ietf.org --===============0156057148== Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit The problem with most P2P optimizations, such as ALTO is that they must be supported by many applications that are developed as a community effort or are strongly user-demand driven in other ways. This means any adoption of optimization depends on the user-perceived value of such optimization.

This means that any optimization must perform as least as good or preferably better than an unoptimized variant would on an open, neutral network. Comparing against traffic shaped network is not a realistic option as traffic shaping drives the demand for obfuscation, leads to an arms race rather than asking the ISP's servers to support the very file sharing applications it's sabotaging at the same time (i'm talking about aggressive traffic shaping here). I.e. the stick does not work very well.

So... how can the carrot look like? Preferring locality does not really work if a swarm is seeded by a handful of very fast seeds in (standard example:) sweden or japan, most peer selection operation in general can only be strongly biased if the swarm is already saturated with bandwidth since the peers are already optimizing for maximum throughput, any deviation from that scheme could mean less-than-optimal performance, from the user perspective.
The general point is that there is only a limited amount of upload bandwidth within the global pool of peers. All ALTO&Co can do is redistributing from the pool, which means it would be a disadvantage to some users and thus a disincentive.

To provide a real incentive to end users there are 2 ways, either it could be monetary or improved download performance. The basic idea of the monetary incentive is to charge extra for non-optimized traffic, e.g. some austrialian ISPs charge extra for "international" traffic in general. But since users like flat pricing that's probably not such a good option.
Providing "real" bandwidth improvements for peers can be done either through caches or something i call "shadow bandwidth", i.e. bandwidth that's physically available on the connection to the user but not part of his broadband plan. E.g. if he is paying for a 20/5 plan but the line is physically capable of 50/20 then we'd have a shadow bandwidth of 30/15. Such bandwidth is already used in some scenarios do deliver VoIP or VoD w/o interference from the internet traffic. If this shadow bandwidth would be made available to local (or otherwise optimized) connections then this would provide a significant incentive to adopt such optimization schemes.
Caches can also provide an incentive since many swarms are not capable of saturating the users' downlink, but as users can be members of private, ratio-tracking sites or caches themselves only participate in uploading to external peers to a very limited extent they can only reduce the upload of a user indirectly by providing bandwidth that has not to be provided by someone in the global pool of peers.


Other options are: multicast and symmetric connection. Multicast dramatically reduces the number of nodes that have to upload and symmetric connections make your local peer as good as any as most peers will be able to reciprocate at your own upload rate on average, which would mean locality-optimizations wouldn't be a dis-incentive at least.



Long story short:
  • incentives for and against adoption from the enduser perspective should be consided in the design of such optimizations
  • the stick probably won't work. you do not feed the jaw that bites you
  • going easy on the ISP infrastructure is not a carrot from the user perspective if it has noticeable, negative impact on the throughput, not just on average but also for individual users
  • cost savings or improved download speeds are real incentives for endusers
  • any centralized solution will be watched with a wary eye as they'll be run by cooperations that might be considered as hostile by users in the light of stories like this one: http://torrentfreak.com/uncovering-the-dark-side-of-p4p-080824/ thus privacy and lawyer-resistance should be design-goals of any P2P-infrastructure as this would otherwise prove to be a disincentive for adoption

--
The 8472
independent developer for the Azureus Vuze Bittorrent client --===============0156057148== 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 --===============0156057148==-- From p2pi-bounces@ietf.org Thu Aug 28 16:53: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 33F373A6C7C; Thu, 28 Aug 2008 16:53: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 21A363A6ABE for ; Thu, 28 Aug 2008 16:53:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.102 X-Spam-Level: * X-Spam-Status: No, score=1.102 tagged_above=-999 required=5 tests=[BAYES_50=0.001, GB_PAYLESS=0.5, HTML_MESSAGE=0.001, J_CHICKENPOX_42=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 PgTIef-UhbcI for ; Thu, 28 Aug 2008 16:53:04 -0700 (PDT) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.227]) by core3.amsl.com (Postfix) with ESMTP id 472063A6A4F for ; Thu, 28 Aug 2008 16:53:03 -0700 (PDT) Received: by rv-out-0506.google.com with SMTP id b25so548866rvf.49 for ; Thu, 28 Aug 2008 16:52:52 -0700 (PDT) Received: by 10.141.84.17 with SMTP id m17mr1121860rvl.48.1219967571831; Thu, 28 Aug 2008 16:52:51 -0700 (PDT) Received: from ?10.0.1.234? ( [208.72.192.23]) by mx.google.com with ESMTPS id b8sm2700459rvf.4.2008.08.28.16.52.49 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 28 Aug 2008 16:52:50 -0700 (PDT) Message-Id: <4526334F-F76A-4853-91FD-69C1DB643E77@shlang.com> From: Stanislav Shalunov To: The 8472 In-Reply-To: <48B5C064.70408@infinite-source.de> Mime-Version: 1.0 (Apple Message framework v926) Date: Thu, 28 Aug 2008 16:52:48 -0700 References: <48B5C064.70408@infinite-source.de> X-Mailer: Apple Mail (2.926) Cc: p2pi@ietf.org Subject: Re: [p2pi] Incentivization for P2P optimizations X-BeenThere: p2pi@ietf.org X-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="===============0618968979==" Sender: p2pi-bounces@ietf.org Errors-To: p2pi-bounces@ietf.org --===============0618968979== Content-Type: multipart/alternative; boundary=Apple-Mail-64--1005284010 --Apple-Mail-64--1005284010 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit This is very well-reasoned and I thought I would just add a couple of small bits: Many ISPs outside of the US already have traffic caps and charge per bit above the cap. US ISPs seem to be moving in the same direction. Usually in these cases there's an exception for some form of local traffic. The locality is different in different places, sometimes country-wide sometimes city-wide, and sometimes network-wide. If ALTO allowed the ISP to convey this same preference in a machine-readable form, both the ISP and the P2P app/user would have an incentive to use it. The incentives, briefly, are -- For the user and, consequently, P2P app developers, pay less with metered traffic be blocked or throttled less with unmetered traffic For the edge ISP, have less transit traffic There's no incentive for core ISPs (who get paid for the transit traffic), but their participation isn't required. The privacy requirement is that the ISP learns no more than it does today about the swarm operation. The ISP already knows who you connect to, but it does not know who you're considering as connection candidates. And yes, when ISP preference and performance collide, performance will win. I do hope that there's a fair number of cases where there's no collision. On Aug 27, 2008, at 2:00 PM, The 8472 wrote: > The problem with most P2P optimizations, such as ALTO is that they > must be supported by many applications that are developed as a > community effort or are strongly user-demand driven in other ways. > This means any adoption of optimization depends on the user- > perceived value of such optimization. > > This means that any optimization must perform as least as good or > preferably better than an unoptimized variant would on an open, > neutral network. Comparing against traffic shaped network is not a > realistic option as traffic shaping drives the demand for > obfuscation, leads to an arms race rather than asking the ISP's > servers to support the very file sharing applications it's > sabotaging at the same time (i'm talking about aggressive traffic > shaping here). I.e. the stick does not work very well. > > So... how can the carrot look like? Preferring locality does not > really work if a swarm is seeded by a handful of very fast seeds in > (standard example:) sweden or japan, most peer selection operation > in general can only be strongly biased if the swarm is already > saturated with bandwidth since the peers are already optimizing for > maximum throughput, any deviation from that scheme could mean less- > than-optimal performance, from the user perspective. > The general point is that there is only a limited amount of upload > bandwidth within the global pool of peers. All ALTO&Co can do is > redistributing from the pool, which means it would be a disadvantage > to some users and thus a disincentive. > > To provide a real incentive to end users there are 2 ways, either it > could be monetary or improved download performance. The basic idea > of the monetary incentive is to charge extra for non-optimized > traffic, e.g. some austrialian ISPs charge extra for "international" > traffic in general. But since users like flat pricing that's > probably not such a good option. > Providing "real" bandwidth improvements for peers can be done either > through caches or something i call "shadow bandwidth", i.e. > bandwidth that's physically available on the connection to the user > but not part of his broadband plan. E.g. if he is paying for a 20/5 > plan but the line is physically capable of 50/20 then we'd have a > shadow bandwidth of 30/15. Such bandwidth is already used in some > scenarios do deliver VoIP or VoD w/o interference from the internet > traffic. If this shadow bandwidth would be made available to local > (or otherwise optimized) connections then this would provide a > significant incentive to adopt such optimization schemes. > Caches can also provide an incentive since many swarms are not > capable of saturating the users' downlink, but as users can be > members of private, ratio-tracking sites or caches themselves only > participate in uploading to external peers to a very limited extent > they can only reduce the upload of a user indirectly by providing > bandwidth that has not to be provided by someone in the global pool > of peers. > > > Other options are: multicast and symmetric connection. Multicast > dramatically reduces the number of nodes that have to upload and > symmetric connections make your local peer as good as any as most > peers will be able to reciprocate at your own upload rate on > average, which would mean locality-optimizations wouldn't be a dis- > incentive at least. > > > > Long story short: > incentives for and against adoption from the enduser perspective > should be consided in the design of such optimizations > the stick probably won't work. you do not feed the jaw that bites you > going easy on the ISP infrastructure is not a carrot from the user > perspective if it has noticeable, negative impact on the throughput, > not just on average but also for individual users > cost savings or improved download speeds are real incentives for > endusers > any centralized solution will be watched with a wary eye as they'll > be run by cooperations that might be considered as hostile by users > in the light of stories like this one: http://torrentfreak.com/uncovering-the-dark-side-of-p4p-080824/ > thus privacy and lawyer-resistance should be design-goals of any > P2P-infrastructure as this would otherwise prove to be a > disincentive for adoption > > -- > The 8472 > independent developer for the Azureus Vuze Bittorrent client > _______________________________________________ > p2pi mailing list > p2pi@ietf.org > https://www.ietf.org/mailman/listinfo/p2pi -- Stanislav Shalunov --Apple-Mail-64--1005284010 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: quoted-printable
This is very well-reasoned = and I thought I would just add a couple of small = bits:

Many ISPs outside of the US already have = traffic caps and charge per bit above the cap.  US ISPs seem to be = moving in the same direction.  Usually in these cases there's an = exception for some form of local traffic.  The locality is = different in different places, sometimes country-wide sometimes = city-wide, and sometimes network-wide.  If ALTO allowed the ISP to = convey this same preference in a machine-readable form, both the ISP and = the P2P app/user would have an incentive to use = it.

The incentives, briefly, are = --

For the user and, consequently, P2P app = developers,
  • pay less with = metered traffic
  • be blocked or throttled less with unmetered = traffic

For the edge ISP,
  • have less transit = traffic

There's no incentive = for core ISPs (who get paid for the transit traffic), but their = participation isn't required.

The privacy = requirement is that the ISP learns no more than it does today about the = swarm operation.  The ISP already knows who you connect to, but it = does not know who you're considering as connection = candidates.

And yes, when ISP preference and = performance collide, performance will win.  I do hope that there's = a fair number of cases where there's no = collision.



On Aug 27, = 2008, at 2:00 PM, The 8472 wrote:

The problem with most P2P = optimizations, such as ALTO is that they must be supported by many = applications that are developed as a community effort or are strongly = user-demand driven in other ways. This means any adoption of = optimization depends on the user-perceived value of such = optimization.

This means that any optimization must perform as = least as good or preferably better than an unoptimized variant would on = an open, neutral network. Comparing against traffic shaped network is = not a realistic option as traffic shaping drives the demand for = obfuscation, leads to an arms race rather than asking the ISP's servers = to support the very file sharing applications it's sabotaging at the = same time (i'm talking about aggressive traffic shaping here). I.e. the = stick does not work very well.

So... how can the carrot look = like? Preferring locality does not really work if a swarm is seeded by a = handful of very fast seeds in (standard example:) sweden or japan, most = peer selection operation in general can only be strongly biased if the = swarm is already saturated with bandwidth since the peers are already = optimizing for maximum throughput, any deviation from that scheme could = mean less-than-optimal performance, from the user perspective.
The = general point is that there is only a limited amount of upload bandwidth = within the global pool of peers. All ALTO&Co can do is = redistributing from the pool, which means it would be a disadvantage to = some users and thus a disincentive.

To provide a real incentive = to end users there are 2 ways, either it could be monetary or improved = download performance. The basic idea of the monetary incentive is to = charge extra for non-optimized traffic, e.g. some austrialian ISPs = charge extra for "international" traffic in general. But since users = like flat pricing that's probably not such a good option.
Providing = "real" bandwidth improvements for peers can be done either through = caches or something i call "shadow bandwidth", i.e. bandwidth that's = physically available on the connection to the user but not part of his = broadband plan. E.g. if he is paying for a 20/5 plan but the line is = physically capable of 50/20 then we'd have a shadow bandwidth of 30/15. = Such bandwidth is already used in some scenarios do deliver VoIP or VoD = w/o interference from the internet traffic. If this shadow bandwidth = would be made available to local (or otherwise optimized) connections = then this would provide a significant incentive to adopt such = optimization schemes.
Caches can also provide an incentive since = many swarms are not capable of saturating the users' downlink, but as = users can be members of private, ratio-tracking sites or caches = themselves only participate in uploading to external peers to a very = limited extent they can only reduce the upload of a user indirectly by = providing bandwidth that has not to be provided by someone in the global = pool of peers.


Other options are: multicast and symmetric = connection. Multicast dramatically reduces the number of nodes that have = to upload and symmetric connections make your local peer as good as any = as most peers will be able to reciprocate at your own upload rate on = average, which would mean locality-optimizations wouldn't be a = dis-incentive at least.



Long story short:
    =
  • incentives for and against adoption from the enduser perspective = should be consided in the design of such optimizations
  • the = stick probably won't work. you do not feed the jaw that bites you
    =
  • going easy on the ISP infrastructure is not a carrot from the = user perspective if it has noticeable, negative impact on the = throughput, not just on average but also for individual users
    • =
  • cost savings or improved download speeds are real incentives for = endusers
  • any centralized solution will be watched with a = wary eye as they'll be run by cooperations that might be considered as = hostile by users in the light of stories like this one: h= ttp://torrentfreak.com/uncovering-the-dark-side-of-p4p-080824/ thus = privacy and lawyer-resistance should be design-goals of any = P2P-infrastructure as this would otherwise prove to be a disincentive = for adoption

--
The 8472
independent = developer for the Azureus Vuze Bittorrent client
= _______________________________________________
p2pi mailing = list
p2pi@ietf.org
https://www.ietf.org/ma= ilman/listinfo/p2pi


= --Apple-Mail-64--1005284010-- --===============0618968979== 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 --===============0618968979==-- From p2pi-bounces@ietf.org Thu Aug 28 17:12: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 B7BB93A6A2D; Thu, 28 Aug 2008 17:12: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 33F713A6A2D for ; Thu, 28 Aug 2008 17:12:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.958 X-Spam-Level: X-Spam-Status: No, score=-0.958 tagged_above=-999 required=5 tests=[AWL=-0.773, BAYES_40=-0.185] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UPLjBTvD-193 for ; Thu, 28 Aug 2008 17:12:54 -0700 (PDT) Received: from mailhost.jlc.net (mailhost.jlc.net [199.201.159.9]) by core3.amsl.com (Postfix) with ESMTP id 5C8333A67CC for ; Thu, 28 Aug 2008 17:12:54 -0700 (PDT) Received: by mailhost.jlc.net (Postfix, from userid 104) id 2986A33C43; Thu, 28 Aug 2008 20:12:58 -0400 (EDT) Date: Thu, 28 Aug 2008 20:12:58 -0400 From: John Leslie To: "Woundy, Richard" Message-ID: <20080829001258.GJ41780@verdi> References: <20080819212816.GK25453@verdi> <74CCBBDF76102846AFA7B29F3A98D3F60107C3BB@PACDCEXCMB06.cable.comcast.com> Mime-Version: 1.0 Content-Disposition: inline In-Reply-To: <74CCBBDF76102846AFA7B29F3A98D3F60107C3BB@PACDCEXCMB06.cable.comcast.com> User-Agent: Mutt/1.4.1i Cc: p2pi@ietf.org Subject: Re: [p2pi] Information in an ALTO protocol X-BeenThere: p2pi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: P2P Infrastructure Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: p2pi-bounces@ietf.org Errors-To: p2pi-bounces@ietf.org Woundy, Richard wrote: > >>> Hmmm ... so I suspect that it is premature to say that last-hop >>> bandwidth is out of scope? What do others think? > >> For myself, I think we'd be silly to rule it out-of-scope because we >> don't believe ISPs would agree to provide it. _Any_ question we ask an >> ISP may well receive a "none-of-your-business" reply. > > I might be OK with leaving this in scope. I stated two potential ISP > issues in a previous email: the marketing concern (the ISP may be > revealing its mix of regular versus premium customers to competitors) This is certainly possible (in which case they won't answer, or will answer with "noisy" data); but I don't think it would actually reveal anything terribly useful. > and traffic concentration concern (traffic may be drawn to fewer ISP > links with premium customers). I would hope that congestion would be noticed before this becomes a problem. > My bigger concern, however, is the user privacy concern, about the ISP > revealing to the general public about its premium/regular/economy > customers. I agree that in many cases that this information may be > actively measured, but that would seem to require at least some > complicity by the end user (e.g. the end user's host needs to respond to > the measurement traffic). Customers could legitimately object to this information being revealed. > So at least we should discuss whether a user opt-in or opt-out mechanism > should be required for user-specific data like this. IMHO, that is best left for ISPs and customers to work out themselves. -- John Leslie _______________________________________________ p2pi mailing list p2pi@ietf.org https://www.ietf.org/mailman/listinfo/p2pi From p2pi-bounces@ietf.org Fri Aug 29 11:28: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 5F7B73A6A3B; Fri, 29 Aug 2008 11:28: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 2E3A63A6A3B for ; Fri, 29 Aug 2008 11:28:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.659 X-Spam-Level: ** X-Spam-Status: No, score=2.659 tagged_above=-999 required=5 tests=[AWL=-0.250, BAYES_50=0.001, GB_PAYLESS=0.5, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, J_CHICKENPOX_42=0.6, 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 m0Vz9YrHwxUj for ; Fri, 29 Aug 2008 11:28:53 -0700 (PDT) Received: from mo-p00-ob.rzone.de (mo-p00-ob.rzone.de [81.169.146.161]) by core3.amsl.com (Postfix) with ESMTP id 49FBD3A69E7 for ; Fri, 29 Aug 2008 11:28:49 -0700 (PDT) X-RZG-CLASS-ID: mo00 X-RZG-AUTH: :LW0Wek7mfO1Vkr5kPgWDvaJNkQpNEn8ylntakOISso1hE0McXW12o8AG24SD41nTjy5r24VXmP1pbyoIWQ== Received: from [192.168.1.78] (T8c4a.t.pppool.de [89.55.140.74]) by post.webmailer.de (fruni mo28) (RZmta 16.47) with ESMTP id 3072afk7TG9e01 ; Fri, 29 Aug 2008 20:28:51 +0200 (MEST) (envelope-from: ) Message-ID: <48B83FE2.5070001@infinite-source.de> Date: Fri, 29 Aug 2008 20:28:50 +0200 From: The 8472 User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: Stanislav Shalunov References: <48B5C064.70408@infinite-source.de> <4526334F-F76A-4853-91FD-69C1DB643E77@shlang.com> In-Reply-To: <4526334F-F76A-4853-91FD-69C1DB643E77@shlang.com> Cc: p2pi@ietf.org Subject: Re: [p2pi] Incentivization for P2P optimizations X-BeenThere: p2pi@ietf.org X-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="===============2143725223==" Sender: p2pi-bounces@ietf.org Errors-To: p2pi-bounces@ietf.org --===============2143725223== Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Stanislav Shalunov wrote:
This is very well-reasoned and I thought I would just add a couple of small bits:

Many ISPs outside of the US already have traffic caps and charge per bit above the cap.  US ISPs seem to be moving in the same direction.  Usually in these cases there's an exception for some form of local traffic.  The locality is different in different places, sometimes country-wide sometimes city-wide, and sometimes network-wide.  If ALTO allowed the ISP to convey this same preference in a machine-readable form, both the ISP and the P2P app/user would have an incentive to use it.
Well, actually... over here in europe many ISPs actually moved from usage based pricing to flat fees... hum... 7 years ago? The only ones considering returning to usage based pricing are those that offer flat fee UMTS data services.

The incentives, briefly, are --

For the user and, consequently, P2P app developers,
  • pay less with metered traffic
  • be blocked or throttled less with unmetered traffic
yeah... as i said, the stick would probably hamper cooperation. Aggressive, protocol-specific traffic shaping leads to obfuscation, and when you obfuscate you certainly don't want to draw the ISP's attention to the fact that you're P2Ping by querying its p2p-optimization services. Generic throttling (i.e. just lowering the connection's speed caps) might be different, though it's still a "conform or die"-kind of incentive.

For the edge ISP,
  • have less transit traffic

There's no incentive for core ISPs (who get paid for the transit traffic), but their participation isn't required.
even the core ISPs (tier 1 carriers) have to build out peering among each other and generally share the costs of such peering sites. But i don't know if p2p actually is a serious cost concern at those points.

The privacy requirement is that the ISP learns no more than it does today about the swarm operation.  The ISP already knows who you connect to, but it does not know who you're considering as connection candidates.
yes, while is this somewhat easy when you just do peer selection optimization it gets way more difficult with caching.

And yes, when ISP preference and performance collide, performance will win.  I do hope that there's a fair number of cases where there's no collision.



On Aug 27, 2008, at 2:00 PM, The 8472 wrote:

The problem with most P2P optimizations, such as ALTO is that they must be supported by many applications that are developed as a community effort or are strongly user-demand driven in other ways. This means any adoption of optimization depends on the user-perceived value of such optimization.

This means that any optimization must perform as least as good or preferably better than an unoptimized variant would on an open, neutral network. Comparing against traffic shaped network is not a realistic option as traffic shaping drives the demand for obfuscation, leads to an arms race rather than asking the ISP's servers to support the very file sharing applications it's sabotaging at the same time (i'm talking about aggressive traffic shaping here). I.e. the stick does not work very well.

So... how can the carrot look like? Preferring locality does not really work if a swarm is seeded by a handful of very fast seeds in (standard example:) sweden or japan, most peer selection operation in general can only be strongly biased if the swarm is already saturated with bandwidth since the peers are already optimizing for maximum throughput, any deviation from that scheme could mean less-than-optimal performance, from the user perspective.
The general point is that there is only a limited amount of upload bandwidth within the global pool of peers. All ALTO&Co can do is redistributing from the pool, which means it would be a disadvantage to some users and thus a disincentive.

To provide a real incentive to end users there are 2 ways, either it could be monetary or improved download performance. The basic idea of the monetary incentive is to charge extra for non-optimized traffic, e.g. some austrialian ISPs charge extra for "international" traffic in general. But since users like flat pricing that's probably not such a good option.
Providing "real" bandwidth improvements for peers can be done either through caches or something i call "shadow bandwidth", i.e. bandwidth that's physically available on the connection to the user but not part of his broadband plan. E.g. if he is paying for a 20/5 plan but the line is physically capable of 50/20 then we'd have a shadow bandwidth of 30/15. Such bandwidth is already used in some scenarios do deliver VoIP or VoD w/o interference from the internet traffic. If this shadow bandwidth would be made available to local (or otherwise optimized) connections then this would provide a significant incentive to adopt such optimization schemes.
Caches can also provide an incentive since many swarms are not capable of saturating the users' downlink, but as users can be members of private, ratio-tracking sites or caches themselves only participate in uploading to external peers to a very limited extent they can only reduce the upload of a user indirectly by providing bandwidth that has not to be provided by someone in the global pool of peers.


Other options are: multicast and symmetric connection. Multicast dramatically reduces the number of nodes that have to upload and symmetric connections make your local peer as good as any as most peers will be able to reciprocate at your own upload rate on average, which would mean locality-optimizations wouldn't be a dis-incentive at least.



Long story short:
  • incentives for and against adoption from the enduser perspective should be consided in the design of such optimizations
  • the stick probably won't work. you do not feed the jaw that bites you
  • going easy on the ISP infrastructure is not a carrot from the user perspective if it has noticeable, negative impact on the throughput, not just on average but also for individual users
  • cost savings or improved download speeds are real incentives for endusers
  • any centralized solution will be watched with a wary eye as they'll be run by cooperations that might be considered as hostile by users in the light of stories like this one: http://torrentfreak.com/uncovering-the-dark-side-of-p4p-080824/ thus privacy and lawyer-resistance should be design-goals of any P2P-infrastructure as this would otherwise prove to be a disincentive for adoption

--
The 8472
independent developer for the Azureus Vuze Bittorrent client
_______________________________________________
p2pi mailing list
p2pi@ietf.org
https://www.ietf.org/mailman/listinfo/p2pi



--
The 8472
independent developer for the Azureus Vuze Bittorrent client --===============2143725223== 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 --===============2143725223==-- From p2pi-bounces@ietf.org Fri Aug 29 11:59: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 E8CEE3A6A6F; Fri, 29 Aug 2008 11:59: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 91F733A6A6F for ; Fri, 29 Aug 2008 11:59:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.586 X-Spam-Level: X-Spam-Status: No, score=-101.586 tagged_above=-999 required=5 tests=[AWL=-1.687, BAYES_50=0.001, GB_PAYLESS=0.5, J_CHICKENPOX_42=0.6, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kOyzUEwjIO-7 for ; Fri, 29 Aug 2008 11:59:26 -0700 (PDT) Received: from multicasttech.com (lennon.multicasttech.com [63.105.122.7]) by core3.amsl.com (Postfix) with ESMTP id 2F67D3A6A37 for ; Fri, 29 Aug 2008 11:59:26 -0700 (PDT) Received: from [63.105.122.7] (account marshall_eubanks HELO [IPv6:::1]) by multicasttech.com (CommuniGate Pro SMTP 3.4.8) with ESMTP-TLS id 12726467; Fri, 29 Aug 2008 14:59:27 -0400 Message-Id: From: Marshall Eubanks To: Stanislav Shalunov In-Reply-To: <4526334F-F76A-4853-91FD-69C1DB643E77@shlang.com> Mime-Version: 1.0 (Apple Message framework v926) Date: Fri, 29 Aug 2008 14:59:23 -0400 References: <48B5C064.70408@infinite-source.de> <4526334F-F76A-4853-91FD-69C1DB643E77@shlang.com> X-Mailer: Apple Mail (2.926) Cc: p2pi@ietf.org Subject: Re: [p2pi] Incentivization for P2P optimizations X-BeenThere: p2pi@ietf.org X-Mailman-Version: 2.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 On Aug 28, 2008, at 7:52 PM, Stanislav Shalunov wrote: > This is very well-reasoned and I thought I would just add a couple = > of small bits: > > Many ISPs outside of the US already have traffic caps and charge per = > bit above the cap. US ISPs seem to be moving in the same direction. Indeed : Comcast has confirmed that all residential customers will be subject = to a 250 gigabyte per month data limit starting October 1. Regards Marshall > Usually in these cases there's an exception for some form of local = > traffic. The locality is different in different places, sometimes = > country-wide sometimes city-wide, and sometimes network-wide. If = > ALTO allowed the ISP to convey this same preference in a machine- = > readable form, both the ISP and the P2P app/user would have an = > incentive to use it. > > The incentives, briefly, are -- > > For the user and, consequently, P2P app developers, > =95 pay less with metered traffic > =95 be blocked or throttled less with unmetered traffic > > For the edge ISP, > =95 have less transit traffic > > There's no incentive for core ISPs (who get paid for the transit = > traffic), but their participation isn't required. > > The privacy requirement is that the ISP learns no more than it does = > today about the swarm operation. The ISP already knows who you = > connect to, but it does not know who you're considering as = > connection candidates. > > And yes, when ISP preference and performance collide, performance = > will win. I do hope that there's a fair number of cases where = > there's no collision. > > > > On Aug 27, 2008, at 2:00 PM, The 8472 wrote: > >> The problem with most P2P optimizations, such as ALTO is that they = >> must be supported by many applications that are developed as a = >> community effort or are strongly user-demand driven in other ways. = >> This means any adoption of optimization depends on the user- = >> perceived value of such optimization. >> >> This means that any optimization must perform as least as good or = >> preferably better than an unoptimized variant would on an open, = >> neutral network. Comparing against traffic shaped network is not a = >> realistic option as traffic shaping drives the demand for = >> obfuscation, leads to an arms race rather than asking the ISP's = >> servers to support the very file sharing applications it's = >> sabotaging at the same time (i'm talking about aggressive traffic = >> shaping here). I.e. the stick does not work very well. >> >> So... how can the carrot look like? Preferring locality does not = >> really work if a swarm is seeded by a handful of very fast seeds in = >> (standard example:) sweden or japan, most peer selection operation = >> in general can only be strongly biased if the swarm is already = >> saturated with bandwidth since the peers are already optimizing for = >> maximum throughput, any deviation from that scheme could mean less- = >> than-optimal performance, from the user perspective. >> The general point is that there is only a limited amount of upload = >> bandwidth within the global pool of peers. All ALTO&Co can do is = >> redistributing from the pool, which means it would be a = >> disadvantage to some users and thus a disincentive. >> >> To provide a real incentive to end users there are 2 ways, either = >> it could be monetary or improved download performance. The basic = >> idea of the monetary incentive is to charge extra for non-optimized = >> traffic, e.g. some austrialian ISPs charge extra for = >> "international" traffic in general. But since users like flat = >> pricing that's probably not such a good option. >> Providing "real" bandwidth improvements for peers can be done = >> either through caches or something i call "shadow bandwidth", i.e. = >> bandwidth that's physically available on the connection to the user = >> but not part of his broadband plan. E.g. if he is paying for a 20/5 = >> plan but the line is physically capable of 50/20 then we'd have a = >> shadow bandwidth of 30/15. Such bandwidth is already used in some = >> scenarios do deliver VoIP or VoD w/o interference from the internet = >> traffic. If this shadow bandwidth would be made available to local = >> (or otherwise optimized) connections then this would provide a = >> significant incentive to adopt such optimization schemes. >> Caches can also provide an incentive since many swarms are not = >> capable of saturating the users' downlink, but as users can be = >> members of private, ratio-tracking sites or caches themselves only = >> participate in uploading to external peers to a very limited extent = >> they can only reduce the upload of a user indirectly by providing = >> bandwidth that has not to be provided by someone in the global pool = >> of peers. >> >> >> Other options are: multicast and symmetric connection. Multicast = >> dramatically reduces the number of nodes that have to upload and = >> symmetric connections make your local peer as good as any as most = >> peers will be able to reciprocate at your own upload rate on = >> average, which would mean locality-optimizations wouldn't be a dis- = >> incentive at least. >> >> >> >> Long story short: >> =95 incentives for and against adoption from the enduser perspective = >> should be consided in the design of such optimizations >> =95 the stick probably won't work. you do not feed the jaw that = >> bites you >> =95 going easy on the ISP infrastructure is not a carrot from the = >> user perspective if it has noticeable, negative impact on the = >> throughput, not just on average but also for individual users >> =95 cost savings or improved download speeds are real incentives for = >> endusers >> =95 any centralized solution will be watched with a wary eye as = >> they'll be run by cooperations that might be considered as hostile = >> by users in the light of stories like this one: http://torrentfreak.com/= uncovering-the-dark-side-of-p4p-080824/ = >> thus privacy and lawyer-resistance should be design-goals of any = >> P2P-infrastructure as this would otherwise prove to be a = >> disincentive for adoption >> >> -- = >> The 8472 >> independent developer for the Azureus Vuze Bittorrent client >> _______________________________________________ >> p2pi mailing list >> p2pi@ietf.org >> https://www.ietf.org/mailman/listinfo/p2pi > > -- > Stanislav Shalunov > > > > _______________________________________________ > p2pi mailing list > p2pi@ietf.org > https://www.ietf.org/mailman/listinfo/p2pi _______________________________________________ p2pi mailing list p2pi@ietf.org https://www.ietf.org/mailman/listinfo/p2pi From p2pi-bounces@ietf.org Fri Aug 29 18:26: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 0D24B3A6B12; Fri, 29 Aug 2008 18:26: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 0D8A73A6B29 for ; Fri, 29 Aug 2008 18:26:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.102 X-Spam-Level: * X-Spam-Status: No, score=1.102 tagged_above=-999 required=5 tests=[BAYES_50=0.001, GB_PAYLESS=0.5, HTML_MESSAGE=0.001, J_CHICKENPOX_42=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 ib5dr8ljBQUV for ; Fri, 29 Aug 2008 18:26:37 -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 439943A6B0E for ; Fri, 29 Aug 2008 18:26:37 -0700 (PDT) Received: by wf-out-1314.google.com with SMTP id 27so1024520wfd.31 for ; Fri, 29 Aug 2008 18:26:41 -0700 (PDT) Received: by 10.142.213.10 with SMTP id l10mr1190419wfg.197.1220059600968; Fri, 29 Aug 2008 18:26:40 -0700 (PDT) Received: from ?192.168.1.104? ( [67.188.243.194]) by mx.google.com with ESMTPS id 22sm5584673wfg.13.2008.08.29.18.26.39 (version=TLSv1/SSLv3 cipher=RC4-MD5); Fri, 29 Aug 2008 18:26:39 -0700 (PDT) Message-Id: From: Stanislav Shalunov To: The 8472 In-Reply-To: <48B83FE2.5070001@infinite-source.de> Mime-Version: 1.0 (Apple Message framework v926) Date: Fri, 29 Aug 2008 18:26:37 -0700 References: <48B5C064.70408@infinite-source.de> <4526334F-F76A-4853-91FD-69C1DB643E77@shlang.com> <48B83FE2.5070001@infinite-source.de> X-Mailer: Apple Mail (2.926) Cc: p2pi@ietf.org Subject: Re: [p2pi] Incentivization for P2P optimizations X-BeenThere: p2pi@ietf.org X-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="===============0174870420==" Sender: p2pi-bounces@ietf.org Errors-To: p2pi-bounces@ietf.org --===============0174870420== Content-Type: multipart/alternative; boundary=Apple-Mail-92--913254124 --Apple-Mail-92--913254124 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit On Aug 29, 2008, at 11:28 AM, The 8472 wrote: > Well, actually... over here in europe many ISPs actually moved from > usage based pricing to flat fees... hum... 7 years ago? The only > ones considering returning to usage based pricing are those that > offer flat fee UMTS data services. The meme is that flat fees make the ISP 50% more money. (As far as I know the actual number is based on very few data points.) Whether or not the number is quite right (I think that's too high), flat fees do seem to make the ISP more money. So the US ISPs moved to flat pricing around 12 years ago, and some non- US ones (still a minority) followed suit. The ISPs, regardless of pricing plans, will do something with outliers. Currently, non-metered ISPs terminate their accounts or put them into extreme penalty boxes. This is clearly worse in every metric and for every party than charging a fair rate above a cap. The move to usage-based billing above a cap that most users don't hit is all but inevitable. Check the news. > >> >> The incentives, briefly, are -- >> >> For the user and, consequently, P2P app developers, >> pay less with metered traffic >> be blocked or throttled less with unmetered traffic > yeah... as i said, the stick would probably hamper cooperation. > Aggressive, protocol-specific traffic shaping leads to obfuscation, > and when you obfuscate you certainly don't want to draw the ISP's > attention to the fact that you're P2Ping by querying its p2p- > optimization services. Generic throttling (i.e. just lowering the > connection's speed caps) might be different, though it's still a > "conform or die"-kind of incentive. The ISPs do count the bytes. The users are the ones who pay and so they have the ultimate power. But of course ISPs will move to stay in business or go out of business. > even the core ISPs (tier 1 carriers) have to build out peering among > each other and generally share the costs of such peering sites. But > i don't know if p2p actually is a serious cost concern at those > points. Transit traffic is where tier 1 ISPs get paid. Of course they have costs, but they stay in business by making a profit. > yes, while is this somewhat easy when you just do peer selection > optimization it gets way more difficult with caching. The ISP already knows what you're downloading, except for https trackers + encrypted mode connections. Encrypted mode will obviously need to disable caching. > >> >> And yes, when ISP preference and performance collide, performance >> will win. I do hope that there's a fair number of cases where >> there's no collision. >> >> >> >> On Aug 27, 2008, at 2:00 PM, The 8472 wrote: >> >>> The problem with most P2P optimizations, such as ALTO is that they >>> must be supported by many applications that are developed as a >>> community effort or are strongly user-demand driven in other ways. >>> This means any adoption of optimization depends on the user- >>> perceived value of such optimization. >>> >>> This means that any optimization must perform as least as good or >>> preferably better than an unoptimized variant would on an open, >>> neutral network. Comparing against traffic shaped network is not a >>> realistic option as traffic shaping drives the demand for >>> obfuscation, leads to an arms race rather than asking the ISP's >>> servers to support the very file sharing applications it's >>> sabotaging at the same time (i'm talking about aggressive traffic >>> shaping here). I.e. the stick does not work very well. >>> >>> So... how can the carrot look like? Preferring locality does not >>> really work if a swarm is seeded by a handful of very fast seeds >>> in (standard example:) sweden or japan, most peer selection >>> operation in general can only be strongly biased if the swarm is >>> already saturated with bandwidth since the peers are already >>> optimizing for maximum throughput, any deviation from that scheme >>> could mean less-than-optimal performance, from the user perspective. >>> The general point is that there is only a limited amount of upload >>> bandwidth within the global pool of peers. All ALTO&Co can do is >>> redistributing from the pool, which means it would be a >>> disadvantage to some users and thus a disincentive. >>> >>> To provide a real incentive to end users there are 2 ways, either >>> it could be monetary or improved download performance. The basic >>> idea of the monetary incentive is to charge extra for non- >>> optimized traffic, e.g. some austrialian ISPs charge extra for >>> "international" traffic in general. But since users like flat >>> pricing that's probably not such a good option. >>> Providing "real" bandwidth improvements for peers can be done >>> either through caches or something i call "shadow bandwidth", i.e. >>> bandwidth that's physically available on the connection to the >>> user but not part of his broadband plan. E.g. if he is paying for >>> a 20/5 plan but the line is physically capable of 50/20 then we'd >>> have a shadow bandwidth of 30/15. Such bandwidth is already used >>> in some scenarios do deliver VoIP or VoD w/o interference from the >>> internet traffic. If this shadow bandwidth would be made available >>> to local (or otherwise optimized) connections then this would >>> provide a significant incentive to adopt such optimization schemes. >>> Caches can also provide an incentive since many swarms are not >>> capable of saturating the users' downlink, but as users can be >>> members of private, ratio-tracking sites or caches themselves only >>> participate in uploading to external peers to a very limited >>> extent they can only reduce the upload of a user indirectly by >>> providing bandwidth that has not to be provided by someone in the >>> global pool of peers. >>> >>> >>> Other options are: multicast and symmetric connection. Multicast >>> dramatically reduces the number of nodes that have to upload and >>> symmetric connections make your local peer as good as any as most >>> peers will be able to reciprocate at your own upload rate on >>> average, which would mean locality-optimizations wouldn't be a dis- >>> incentive at least. >>> >>> >>> >>> Long story short: >>> incentives for and against adoption from the enduser perspective >>> should be consided in the design of such optimizations >>> the stick probably won't work. you do not feed the jaw that bites >>> you >>> going easy on the ISP infrastructure is not a carrot from the user >>> perspective if it has noticeable, negative impact on the >>> throughput, not just on average but also for individual users >>> cost savings or improved download speeds are real incentives for >>> endusers >>> any centralized solution will be watched with a wary eye as >>> they'll be run by cooperations that might be considered as hostile >>> by users in the light of stories like this one: http://torrentfreak.com/uncovering-the-dark-side-of-p4p-080824/ >>> thus privacy and lawyer-resistance should be design-goals of any >>> P2P-infrastructure as this would otherwise prove to be a >>> disincentive for adoption >>> >>> -- >>> The 8472 >>> independent developer for the Azureus Vuze Bittorrent client >>> _______________________________________________ >>> p2pi mailing list >>> p2pi@ietf.org >>> https://www.ietf.org/mailman/listinfo/p2pi >> >> -- >> Stanislav Shalunov >> >> >> > > -- > The 8472 > independent developer for the Azureus Vuze Bittorrent client -- Stanislav Shalunov --Apple-Mail-92--913254124 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: quoted-printable
On Aug 29, 2008, at = 11:28 AM, The 8472 wrote:
Well, actually... over here in = europe many ISPs actually moved from usage based pricing to flat fees... = hum... 7 years ago? The only ones considering returning to usage based = pricing are those that offer flat fee UMTS data = services.

The meme is that flat = fees make the ISP 50% more money.  (As far as I know the actual = number is based on very few data points.) Whether or not the number is = quite right (I think that's too high), flat fees do seem to make the ISP = more money.

So the US ISPs moved to flat = pricing around 12 years ago, and some non-US ones (still a minority) = followed suit.

The ISPs, regardless of pricing = plans, will do something with outliers.  Currently, non-metered = ISPs terminate their accounts or put them into extreme penalty boxes. =  This is clearly worse in every metric and for every party than = charging a fair rate above a cap.   The move to usage-based billing = above a cap that most users don't hit is all but inevitable.  Check = the news.



The incentives, briefly, are = --

For the user and, consequently, P2P = app developers,
  • pay less = with metered traffic
  • be blocked or throttled less with = unmetered traffic
yeah... as i said, = the stick would probably hamper cooperation. Aggressive, = protocol-specific traffic shaping leads to obfuscation, and when you = obfuscate you certainly don't want to draw the ISP's attention to the = fact that you're P2Ping by querying its p2p-optimization services. = Generic throttling (i.e. just lowering the connection's speed caps) = might be different, though it's still a "conform or die"-kind of = incentive.

The ISPs do count the = bytes.  The users are the ones who pay and so they have the = ultimate power.  But of course ISPs will move to stay in business = or go out of business.

even the core ISPs (tier 1 = carriers) have to build out peering among each other and generally share = the costs of such peering sites. But i don't know if p2p actually is a = serious cost concern at those = points.

Transit traffic is where = tier 1 ISPs get paid.  Of course they have costs, but they stay in = business by making a profit.

yes, while is = this somewhat easy when you just do peer selection optimization it gets = way more difficult with = caching.

The ISP already knows = what you're downloading, except for https trackers + encrypted mode = connections.  Encrypted mode will obviously need to disable = caching.



And yes, when ISP preference and = performance collide, performance will win.  I do hope that there's = a fair number of cases where there's no collision.

=


On Aug 27, 2008, at 2:00 = PM, The 8472 wrote:

=
= The problem with most P2P optimizations, such as ALTO is that they must = be supported by many applications that are developed as a community = effort or are strongly user-demand driven in other ways. This means any = adoption of optimization depends on the user-perceived value of such = optimization.

This means that any optimization must perform = as least as good or preferably better than an unoptimized variant would = on an open, neutral network. Comparing against traffic shaped network is = not a realistic option as traffic shaping drives the demand for = obfuscation, leads to an arms race rather than asking the ISP's servers = to support the very file sharing applications it's sabotaging at the = same time (i'm talking about aggressive traffic shaping here). I.e. the = stick does not work very well.

So... how can the carrot look = like? Preferring locality does not really work if a swarm is seeded by a = handful of very fast seeds in (standard example:) sweden or japan, most = peer selection operation in general can only be strongly biased if the = swarm is already saturated with bandwidth since the peers are already = optimizing for maximum throughput, any deviation from that scheme could = mean less-than-optimal performance, from the user perspective.
The = general point is that there is only a limited amount of upload bandwidth = within the global pool of peers. All ALTO&Co can do is = redistributing from the pool, which means it would be a disadvantage to = some users and thus a disincentive.

To provide a real = incentive to end users there are 2 ways, either it could be monetary or = improved download performance. The basic idea of the monetary incentive = is to charge extra for non-optimized traffic, e.g. some austrialian ISPs = charge extra for "international" traffic in general. But since users = like flat pricing that's probably not such a good option.
Providing = "real" bandwidth improvements for peers can be done either through = caches or something i call "shadow bandwidth", i.e. bandwidth that's = physically available on the connection to the user but not part of his = broadband plan. E.g. if he is paying for a 20/5 plan but the line is = physically capable of 50/20 then we'd have a shadow bandwidth of 30/15. = Such bandwidth is already used in some scenarios do deliver VoIP or VoD = w/o interference from the internet traffic. If this shadow bandwidth = would be made available to local (or otherwise optimized) connections = then this would provide a significant incentive to adopt such = optimization schemes.
Caches can also provide an incentive since = many swarms are not capable of saturating the users' downlink, but as = users can be members of private, ratio-tracking sites or caches = themselves only participate in uploading to external peers to a very = limited extent they can only reduce the upload of a user indirectly by = providing bandwidth that has not to be provided by someone in the global = pool of peers.


Other options are: multicast and = symmetric connection. Multicast dramatically reduces the number of nodes = that have to upload and symmetric connections make your local peer as = good as any as most peers will be able to reciprocate at your own upload = rate on average, which would mean locality-optimizations wouldn't be a = dis-incentive at least.



Long story = short:
  • incentives for and against adoption from the = enduser perspective should be consided in the design of such = optimizations
  • the stick probably won't work. you do not = feed the jaw that bites you
  • going easy on the = ISP infrastructure is not a carrot from the user perspective if it has = noticeable, negative impact on the throughput, not just on average but = also for individual users
  • cost savings or improved = download speeds are real incentives for endusers
    • =
  • any centralized solution will be watched with a wary eye as they'll = be run by cooperations that might be considered as hostile by users in = the light of stories like this one: h= ttp://torrentfreak.com/uncovering-the-dark-side-of-p4p-080824/ thus = privacy and lawyer-resistance should be design-goals of any = P2P-infrastructure as this would otherwise prove to be a disincentive = for adoption

--
The 8472
= independent developer for the Azureus Vuze Bittorrent client
= _______________________________________________
p2pi mailing = list
p2pi@ietf.org
https://www.ietf.org/m= ailman/listinfo/p2pi

=

--
The 8472
independent developer for = the Azureus Vuze Bittorrent client


= --Apple-Mail-92--913254124-- --===============0174870420== 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 --===============0174870420==-- From p2pi-bounces@ietf.org Sat Aug 30 05:30: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 2B40E3A68FA; Sat, 30 Aug 2008 05:30: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 394D63A68FA for ; Sat, 30 Aug 2008 05:30:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.505 X-Spam-Level: * X-Spam-Status: No, score=1.505 tagged_above=-999 required=5 tests=[AWL=1.154, BAYES_50=0.001, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AA1d4HayVTBh for ; Sat, 30 Aug 2008 05:30:09 -0700 (PDT) Received: from mo-p00-ob.rzone.de (mo-p00-ob.rzone.de [81.169.146.160]) by core3.amsl.com (Postfix) with ESMTP id 0C6023A68A1 for ; Sat, 30 Aug 2008 05:30:08 -0700 (PDT) X-RZG-CLASS-ID: mo00 X-RZG-AUTH: :LW0Wek7mfO1Vkr5kPgWDvaJNkQpNEn8ylntakOISso1hE0McXW12o8AG24SD41nTjy5r24VXmPH0VMo6lig= Received: from [192.168.1.78] (Tb6c3.t.pppool.de [89.55.182.195]) by post.webmailer.de (klopstock mo10) (RZmta 16.47) with ESMTP id 906beck7UBeigh ; Sat, 30 Aug 2008 14:30:09 +0200 (MEST) (envelope-from: ) Message-ID: <48B93D51.2000805@infinite-source.de> Date: Sat, 30 Aug 2008 14:30:09 +0200 From: The 8472 User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: Stanislav Shalunov References: <48B5C064.70408@infinite-source.de> <4526334F-F76A-4853-91FD-69C1DB643E77@shlang.com> <48B83FE2.5070001@infinite-source.de> In-Reply-To: Cc: p2pi@ietf.org Subject: Re: [p2pi] Incentivization for P2P optimizations X-BeenThere: p2pi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: P2P Infrastructure Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: p2pi-bounces@ietf.org Errors-To: p2pi-bounces@ietf.org Stanislav Shalunov wrote: > yes, while is this somewhat easy when you just do peer selection > optimization it gets way more difficult with caching. > > The ISP already knows what you're downloading, except for https > trackers + encrypted mode connections. Encrypted mode will obviously > need to disable caching. they could know, but they don't (or they shouldn't) at the moment since that would violate user privacy. ISPs should be considered a public service, just like the postal service. Should the postal service be allowed to look into your mail? They can do so technically, just like ISPs can easily look into your packets and examine what you're doing. Thus privacy has to be protected in a caching scheme. -- The 8472 independent developer for the Azureus Vuze Bittorrent client _______________________________________________ p2pi mailing list p2pi@ietf.org https://www.ietf.org/mailman/listinfo/p2pi From p2pi-bounces@ietf.org Sat Aug 30 05:40: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 41F653A69AD; Sat, 30 Aug 2008 05:40: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 7D24E3A68A1 for ; Sat, 30 Aug 2008 05:39:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.623 X-Spam-Level: X-Spam-Status: No, score=0.623 tagged_above=-999 required=5 tests=[BAYES_50=0.001, 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 k2H6a4kdCgnC for ; Sat, 30 Aug 2008 05:39:58 -0700 (PDT) Received: from ug-out-1314.google.com (ug-out-1314.google.com [66.249.92.171]) by core3.amsl.com (Postfix) with ESMTP id 6F6673A69AD for ; Sat, 30 Aug 2008 05:39:57 -0700 (PDT) Received: by ug-out-1314.google.com with SMTP id u2so1405727uge.15 for ; Sat, 30 Aug 2008 05:40:00 -0700 (PDT) Received: by 10.66.238.18 with SMTP id l18mr632224ugh.32.1220100000388; Sat, 30 Aug 2008 05:40:00 -0700 (PDT) Received: by 10.67.92.13 with HTTP; Sat, 30 Aug 2008 05:40:00 -0700 (PDT) Message-ID: <167dfb9b0808300540v4b6ed4e8ic104b3719e45de89@mail.gmail.com> Date: Sat, 30 Aug 2008 13:40:00 +0100 From: "Theo Zourzouvillys" To: "The 8472" In-Reply-To: <48B83FE2.5070001@infinite-source.de> MIME-Version: 1.0 Content-Disposition: inline References: <48B5C064.70408@infinite-source.de> <4526334F-F76A-4853-91FD-69C1DB643E77@shlang.com> <48B83FE2.5070001@infinite-source.de> Cc: p2pi@ietf.org Subject: Re: [p2pi] Incentivization for P2P optimizations X-BeenThere: p2pi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: P2P Infrastructure Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: p2pi-bounces@ietf.org Errors-To: p2pi-bounces@ietf.org 2008/8/29 The 8472 : > Well, actually... over here in europe many ISPs actually moved from usage > based pricing to flat fees... hum... 7 years ago? The only ones considering > returning to usage based pricing are those that offer flat fee UMTS data > services. Perhaps in your Europe, but certainly not mine :-) However you look at it, every single ISP here in the UK is usage based, ether through monthly caps, usage based charging, dynamically rate limiting, or sticking all the bandwidth abusers on a "naughy boy's" LNS to be in line with their usage policy for that service. ~ Theo _______________________________________________ p2pi mailing list p2pi@ietf.org https://www.ietf.org/mailman/listinfo/p2pi