Minutes P2P Mythbustering ----------------- Enrico Marocco presents slides on P2P facts/myths - P4P and TU Berlin trials have shown traffic localization - P4P, TU Berlin, and Ono trials have shown application improvements. May not be good in some cases (e.g., networks with low uplink bandwidth). - (??) - question on wide range of results. suggestion to find out more from authors about test scenarios. Enrico comments that they are currently trying to collect, but feels they are very scenario-specific. Current results for filesharing. Enrico comments that there one of document's refences mentions relay selection (Skype). - (??) - Question about distribution of download time. Enrico comments that it varies across results. Results depend on which / how many networks implement these techniques. Enrico comments that this also varies across results/papers. - Discussion on possible increase in uplink bandwidth. One data point is that in the Comcast trial, there was no uplink bandwidth increase. - Discussion on impacts on ISP peering. With P2P (de)localization, ISPs can direct traffic volume to achieve more advantageous peering agreements. - (??) - Question about whether forcing data out of network is bad for a network. Enrico comments that it may be advantageous if leads to better peering agreement. - Discussion on impacts on transit. Localization typically tries. Possible issue with - (??) - DoS attacks against peers. Enrico comments to share possible security concerns on mailing list. - Richard Barnes - Interesting that "good" service can be repurposed for economic gaming. Wonders whether it is possible for ALTO service display that it is providing good/honest service. Survey on Research on the ALTO Problem -------------------------------------- - Two approaches: application layer and layer cooperation - End-system mechanisms for topology estimation - coordinate systems - path selection services - link-layer internet maps - operator-provided topological information - discussion on coordinate systems with Vivaldi as example - uses network metrics to establish coordinates - uses triangle inequality, which may not be true in internet - discussion on Ono - uses CDNs as beacons for location - peers "bias" traffic towards peers with better similarity ratio - discussion on iPlane - build structured internet atlas - annotates alias with metrics (latency, loss rate, capacity, bandwidth) - prediction of end-to-end properties - P4P - multiple services: policy, P4P distance, capability - IPs mapped onto PIDs; pDistance measured between PIDs - Oracle - client sends unsorted list to ISP; ISP returns sorted list - ranking based on many metrics - (Vijay) - are we thinking about making this a research group draft? - Volker comments that it would be a good research group draft after some other additions. Stefano asks for comments from research group. Mechanism for P2P Group Management using Multiple Overlays ---------------------------------------------------------- - Motivation for P2P is communication and information sharing with and between communiities. Main motivation for groups is to control the scope of communications (privacy) - group management at application layer; each uses own mechanism - draft's goal is group management for P2P. Uses multiple overlays - each group forms separate overlay. - Group-specific traffic routed inside group overlay - group creation and maintenance - creation operates by creating new overlay - looks for existing group; publishes info to main overlay if not yet present - maintenance done by publishing member list to main overlay - one node in charge of maintaining info - joining and leaving - joining node finds group info in main overlay - leaving is done by leaving the group overlay - group removal - last peer removes from main overlay - binding to "alias" ID - establish alias for existing group - data format is XML - open issues - bootstrapping - ensure only legitimate members able to join group - (Thomas Schmidt) - Approch is well-known, but has high overhead on group management. Question to chairs is whether it makes sense to have concrete problem statement. Volker agrees. - (??) - How do you decide peer group? Answers that group membership list is outside of scope of the protocol. Bit Torrent Measurements: Challenges of Locality Promotion ---------------------------------------------------------- - table showing measurements done in this study - results: size & time dynamics - observed periodic behavior for some swarms; more pronounced for some swarms than others; some swarms don't hav ethem - results: Peers-per-AS distribution - Spanish swarm has larger % of peers in top AS (around 40%); Dutch swarm has smaller around 20% at median. - (Richard Barnes) - Question on how AS is determined - Zoran confirms that AS #'s come from whois data. - results: inter-AS traffic under locality - AS hop distance much better than 'binary' decision when choosing interdomain peers - results: inter-AS traffic under locality per AS - trend is there is reduction in inter-AS traffic, but some AS's increase traffic when using locality - (Richard Barnes) - comments that this is valuable data. Focus on AS's that contains peers but omits transit ASs. Agrees that - (Volker) - do you have sense on which ASs are most affected? Zoran comments that it is the ones who service more of the traffic. - (Reinaldo) - Question on result that says some ASs - How long is simulation run? is there a point at which reduction occurs? Zoran comments that same experiment ran with and without locality. ASs for which this happens changes under different scenarios. - (Enrico) - Suggestions on coordinating something for measurements. Zoran agrees. Volker comments that they would welcome a draft that summarizes results. - (Reinaldo) - Questions on simulation setup and comments it can differ from real-world experiments (PEX, DHT, etc). Request to put details in the draft. Introduction of ALTO-like activity --------------------------------------- - background: - whitespread broadband (many FTTH) - p2p filesharing appliations mosty ones that wer developed in Japan - isps shaping p2p traffic based on DPI - p2p still remains dominant - cost structure - ALTO's main target is user IS - bottleneck moving from access to backbone - consider link btw access network provider and ISP - contrl inter-AS traffic more than intra-AS - many type of p2p applications - network neutrality - equal access to networks - p2p traffic threat to equitable cost allocation but important for scalability - p2p network experiment council established - goal to spread p2p services; benefits to adopters - experimental environment - dummy nodes - 40 nodes composed of PCs in users' environments - observe peer selections - hint server - dummy node peer selection - appears random - hint server reduces reduction in physical distance for traffic - hint server '09 - more P2P vendors (6+) - compatibility with ALTO reqs (src, dst, cost) - public/private hint servers - private for isp-specific (accounting, etc) - extended fields for isp guidance - cache nodes, NAT nodes, non-congested nodes - stats information - transfer rates, # peers, - suggestions to ALTO - useful for hierarchy - wireless environments - providing stats is necessary to observe performances; difficult to estimate effectiveness - (Stefano) - very good input to ALTO WG - (Enrico) - post this to the ALTO mailing list Swarm Analysis: 7 days of two popular swarms -------------------------------------------- - two swarms - wanted to understand social aspects too - Sniper - Cantonese language movie (target was non-English; not released in US) - Push - English language movie (target is English; released in US) - both swarms have comperable size - (??) - Question on how tracker list and reachability impact stats; Vijay comments that they didn't test reachability - used Pirate bay - May 20 - Jun 6 2009 every 4 hours - attenuation rate for Sniper - 7000 leechers ; 4000 seeders at start - gradual decrease over time - (Volker) - started collecting at beginning of swarm? - attenuation rate for Push - much more difference between initial # of seeders/leechers - less gradual decrease in size - Peer durations for both torrents very similar - ASN statistics - around 2800 distinct ASNs for both - Max # of peers in ASN is ~3800 for Sniper (in UAE) - Max # of peers in ASn is ~7500 for Push (in Poland) - Around 200 AS's with >= 100 peers for Sniper - peer density (peers per ASN) - Norway / Great Britain has larger concentration - US has smaller (but more AS's) - next steps - continuing to mine - intent to repeat with other stats - more data before drawing more conclusions - (Rich Woundy) - Peers per ASN - were they simultaneous? No they were for duration Comment: Tracking by AS may not be most useful. Example Comcast has many ASs; Verizon has 1. Suggestion to normalize against size of ISP. - (Volker) Suggestion to write this up in a draft. - (??) - Do you know more about real-time traffic behavior? No - don't get this information from the tracker. Didn't do communication with peers. Vijay comments that they would like to get handle on access characteristics for peers with long duration. - (??) - Couldn't find China in stats for Sniper torrent. Vijay surprised by this as well. P2P Live Streaming for the Masses --------------------------------- - RayV is deployed systems - 3 million downloads - 300,000 connected clients on average - 70,00 concurrent viewers at peak - viewing habits overall: 31 minutes per day - varies by type of program - demonstration - 20 - 65 or 80 peers depending on rate of stream - measures latency per peer, rate - want to synchronized viewers - measure dime delta amongst peers - get peers; start to communicate immediately when start - uppermost peer in initial list is source server (12 around globe) - content owners rquirements - quality and bit-rate (300kbps in China for example) - 500-800kbps for news/music - 800-1500kbps for sports - 2.5-6mbps for upcoming tv-like experience - delay - less than 10 seconds for broadcaster to viewers - simultaneous viewing up to 2 seconds - low cost - advertising / subscription - scale for concurrent viewers - rules (p2p limitations) - network quality and geo-localization needs - quality averages per country - how many packets that were requested were actually received - redundancy provides protection - but has wasted network bandwidth - quality deviation graph - without p2p: gaussian with avg of 0.85 - with p2p: most users get almost all packets - congestion control (but use UDP) - without p2p: avg 86.5% - with 75% p2p: avg 98.8% - (Volker) - some countries have source servers, some dont? Answer: Could put reliable source within countries that have issues (e.g., Austrialia) with performance. P2P has allowed them to reduce dependence on these servers. - Average upload from user - 180kbps - though, cap at 500kbps (so as not to affect users) - implication: can't rely on users completely - solve problem by using resources by non-viewers - not all peers are actual viewers - use those peers for distribution of traffic - use PET and network coding - (Reinaldo) - what exactly are non-viewers? Answer: these are people that have application open but not watching anything. - (??) - Are there "unknown" viewers? Answer: clients must contact servers. Use tokens to authorize content, so there aren't "unknown viewers". - system costs - deploying POPs is expensive (power, bandwidth, etc) - bandwidth cost varies largely across countries (Austrilia, south america, ..) - p2p helps scalability within enterprises, universities - Slides show estimates of overall cost of P2P - Rules from content owners - Prevent 'their' viewers from contributing to different types of content - rules must be applied at server-side - ISPs may have additional rules - viewers contribute only to own channels, only during certain hours - caching - legal rules - taxes between countries (if peers contribute to viewers in other countries) - techincal rules - peer selection based on server - putting source server close by helps - not clear that contributions from other peers works - (Yunfei) - interested in presentation at PPSP bof. What kind of localizatoin is applied in service? Answer: First thing is that viewer asks server for peers. Rough estimation of "zone" at server. Same LAN peers preferred. More important is how returned peers are used (1000's). Portion of "not good" peers initially is high. Replacement algorithm for that is important. Server has info of 'alternative' zones, costs for zones, etc Different zones can communicate (except for China). Bandwidth between China ISPs is small - try to avoid. Use SCTP congestion control over UDP. Go to reliable source for last 2 seconds. What is cache replacement policy? Answer: buffer for 8 seconds - no caching for data storage. Balance is upload bandwidth. ISPs could put satallites within own networks. buffer length varies by content owner (up to 8 seconds for p2p, 2 seconds). Want to reduce buffer length. - (??) - Are servers per content owner? Asnwer: they are shared (but for scalability purposes) - (??) - p2p arch in p2psip - is it of interest here? Volker says yes we could discuss here. - (??) - Content right owners have rights in only a region - is this limited at the viewer level (e.g., sharing across geographies). Answer: they have rules applied at server for this for viewing; 'amplifiers' dont apply this (since data not consuming storage, and they are not able to view the data they see).