自然之道

Chuan Wu, Baochun Li （University of Toronto）
Shuqiao Zhao （UUSee, Inc）

目标：分析拓扑。

指出商业系统中的peer选择和拓扑构造算法不复杂。

提到mesh比tree好的原因，但未展开证明。

• - 适应peer dynamics
• - flash crowd时好
• - 带宽利用率高
• - 拓扑维护简单

对flash crowd时，拓扑如何react，简单的结果。（事实上也无法细化）

2个月（2006年9月-10月）的trace。120GB。结论还用07年的一个trace进行了验证。

方法：Peer周期报告，服务器收集。认为爬的方法的缺陷：1）peer list不是真实的连接。2）没有indegree。

五个主要结论：

1. 在拓扑变化中发现flash crowd：说明能扛住一定的flash crowd
2. 度分布不是幂率
3. 按ISP形成了簇
4. 互惠
5. 没有超级节点

UUSee的算法的介绍：

• 一个media编码server （400Kbps，专有codec）+ 一大群streaming server
• peer playback buffer：500。每块1/3s。
• 同步方法：大家都比server晚20s放。
• TCP
• 启动时
  • 邻居选择：用握手信号检测RTT，再测TCP速度，由此通过估计算法，选最好的30个邻居作为起始的邻居请求数据。
  • Buffer初始化：抓最新的包，20s后检查。如果此时buffer级别不行，就重新启动，再用20s去抓。所以延时可能有20s，40s，60s。（和同步似乎有矛盾，怀疑前者）
• 连续请求块。（具体算法没说）
• 到了Deadline了但还没有收到的piece被跳过
• buffer填充率到达总大小的75%时就不填了。（特别，保守一点，防止拥塞？）

Peer选择算法的细节：

• 初始启动时，peer估计自己的最大上载、下载速度。
• 运行过程中，Peer一直评估自己的uploading能力是否用尽。如果没有，则通知tracker自己有余力。而tracker将其加入有余力的peer的列表里。
• 当新的peer来时，Tracker告诉它有余力的这些友邻。
• buffer count为‘1’的个数。运行过程中，peer如果发现一个邻居的buffer count小，就发送buffer count大的邻居给它。
• peer如果发现自己的buffer count很长时间都很小，就向tracker要新的peer。

（有趣的Peer集中式选择算法，如何评估？）

分析Peer个数：

• 发现了flash crowd：
• 每天9pm为一个高峰。在6小时左右，上去又下来，为一个三角形。对CCTV1这个最流行的频道，在中秋节晚会时，最高的人数，变化幅度为10K，折算的平均到达率为：10K/3*3.6K=1 peer/s （还不算太高吧）
• 稳定的peer为所有peer的1/4。

用buffer count进行的质量评估：发现大多数人还不错。

度分布：

• 稳定Peer的度分布：要求至少下了10个piece的Peer的度。
  • 入度：10
  • 出度：10-20
• 总partner：包括那些下了不到10个piece的，或根本没下的Peer
  • 总度30-40。
• 度随着人数的增长而增长
  • 9pm时，度增大。
• 出degree与上载throughput有一点相关性：
  • Pearson product-moment correlation coefficient：0.4871

分析是否有超级节点：

• 用likelihood metric proposed by Li et al. in [Li et al. 2004],
• 用上载throughput来计算。
• 没有超级节点

参考文献：

回顾历史：

• Kazza，第一代Gnutella，
• 现代Gnutella的经典文献：P2P topology characterization, Stutzbach et al. [Stutzbach et al. 2005]
• 没有BT网络的拓扑分析
• BT性能，[Pouwelse et al. 2005], Izal et al. [Izal et al. 2004] and Guo et al. [Guo et al. 2005]
• KAD的peer churn，session特点。 [Stutzbach and Rejaie 2006] and Steiner et al. [Steiner et al. 2007]
• Skype：协议，流量特性，用户满意度。[Chen et al. 2006].
• Ali,Hei,Silverston,Vu的测量
• GridCast P2P VoD用户体验的测量 Cheng et al. [Cheng et al. 2007]

Xiaofei Liao,

Basic:

• inter-overlay optimization, resources can join multiple overlays,

Goal：

• (1) improve global resource utilization and distribute traffic to all physical links evenly;
• (2) assign resources based on their locality and delay;
• (3) guarantee streaming service quality by using the nearest peers, even when such peers might belong to different overlays; and
• (4) balance the load among the group members.

Metrics:

• startup delay
• source-to-end delay
• playback continuity

Problem:

• still suffer from long delay and unplanned interruptions, especially when a large number of peers join the network simultaneously.

challenges:

• (1) how to find paths with low delays, including source-to-end delay and startup delay, in a global P2P network;
• (2) how to maintain the service continuity and stability (decreasing the impact of interruption caused by peers leaving);
• (3) how to determine the frequency of optimization operations; and
• (4) how to reduce the control overhead caused by the algorithm.

Component：

• inter-overlay optimization manager
• explores appropriate paths, builds backup links, and cuts off paths with low QoS for each end peer.
• key node manager
• allocates the limited resources: admission control policy
• buffer manager
• manages and schedules the transmission of media data.

Peer join or leave the topology

• LastDelay, which is the minimal of all source-to-end delays from the current node to the streaming source on different paths.
• Peers join or leave the topology according to LastDelay.
• Generally, each peer maintains one active streaming path set and one backup streaming path set.
• When the number of backup streaming paths is less than a threshold, the inter-overlay optimization algorithm is called to find appropriate streaming paths in the global P2P network with the help of the mesh-based overlay.
• a probing message named ProbM
• There are mainly two tasks for the inter-overlay optimization manager, including backup streaming path set management(reverse tracing) and active streaming path set management.
• When one active streaming path is cut off due to its poor QoS or peer’s leaving, a new streaming path is selected from the backup set.

Fetch algorithm:

• The playback deadline for each segment and the heterogeneous streaming bandwidth from partners.

topologies

• two types of topologies, physical topology and logical P2P topology.
• AnySee requires each peer maintain an INCD, from which each peer can have a position, named GID in the global network. The GID value of an end host is a 128-bits integer encoded by the 4-layer geometrical information corresponding to ISPs, cities, campuses, and buildings,
• height is always less than 7 even with a thousand peers included in one tree

Buffer size

• a small buffer space is enough, and indeed a small buffer often means a shorter startup delay.
• threshold DS is set to 25 seconds
• the necessary buffer size of AnySee is only 40 seconds, while Coolstreaming needs a 120-second buffer.
• layer-aware buffer management: Each peer computes its appropriate buffer space size according to the layer number.

Delay

• xx is the average disconnection times of one connection. T’ is the total transporting delay, ta denotes the total link delay,
• source-to-end delay is always less than 200 ms. the startup delay of most peers is less than 20s. the startup delay of Coolstreaming is around 60 seconds.

Problem

• too many users are leaving the overlay is the signal that the overlay is under heavy burden and needs to be optimized.
• “optimization index”, ADL= leaving percentage100 / average delay

Refer

• Simulation topology
• we use BRITE [3] generating three topologies, each with 5,000 nodes. The average number of neighbors of each node ranges from 4 to 10.
• [3] BRITE, http://www.cs.bu.edu/brite/.
• a crawler based on Gnutella protocol [1] and the source codes are rewritten from Limewire open source client [2] forty-five independent threads, our crawler discovers over fifty thousands peers and their connections in one week.
• A location detector based algorithm is employed to match the overlay with the underlying physical topology [25].
• [25] Y. Liu, L. Xiao, X. Liu, L.M. Ni, and X. Zhang, "Location Awareness in Unstructured Peer-To-Peer Systems", IEEE Transactions on Parallel and Distributed Systems, 2005.
• LTM (Locationaware Topology Matching) technique [25] two major operations: flooding-based detection with limited TTL, and updating logical connections. dm(id, S, TTL)
• Simulation based on topologies from real P2P networks [1].
• NTP
• Current implementation of NTP version 4.1.1 in public domain can reach the synchronization accuracy down to 7.5 milliseconds [27].
• [27] NTP: The Network Time Protocol, http://www.ntp.org/.
• single tree protocols, such as ESM, NICE [19] and ZigZag [18]
• [13] Y. Chu, S. G. Rao, and H. Zhang, "A Case for End System Multicast," in Proceedings of ACM SIGMETRICS, 2000.
• [19] S. Banerjee, B. Bhattacharjee, and C. Kommareddy, "Scalable Application Layer Multicast", in Proceedings of ACM SIGCOMM, 2002.
• [18] D. Tran, K. Hua, and S. Sheu, "Zigzag: An Efficient Peer-To- Peer Scheme for Media Streaming", in Proceedings of IEEE INFOCOM, 2003.
• multiple tree protocols [14][15].
• Problem: the leaving or crash behavior of nodes in the upper layers often causes buffer underflow.
• mesh-based protocols: as Coolstreaming, PROMISE [17] and GNUStream [21].
• [17] M. Hefeeda, A. Habib, B. Botev, D. Xu, and B. Bhargava, "PROMISE: Peer-To-Peer Media Streaming Using Collectcast", in Proceedings of ACM Multimedia, 2003.
• [21] X. Jiang, Y. Dong, and X. D, B. Bhargava, "GNUSTREAM: A P2P Media Streaming System Prototype", in Proceedings of IEEE ICME, 2003.
• Problem: Due to the random selection algorithm, the quality of service cannot be guaranteed, such as the startup delay.
• DHT based P2P resource pool
• Zhang proposed a DHT based P2P resource pool, SOMO [22], [23] to manage global resources and optimize multiple ALM (Application Layer Multicast) sessions, especially computation applications.
• [22] Z. Zhang, Y. Chen, S. Lin, B. Lu, S. Shi, X. Xie, and C. Yuan, "P2P Resource Pool and Its Application to Optimize Wide-Area Application Level Multicasting", in Proceedings of International Conference on Parallel Processing Workshops, 2004.
• [23] Z. Zhang, S. Shi, and J. Zhu, "SOMO: Self-Organized Metadata Overlay for Resource Management in P2P DHT", in Proceedings of IEEE IPTPS, 2003.
• IPTV [5]
• [5] B. Alfonsi, "I Want My IPTV: Internet Protocol Television Predicted a Winner", IEEE Distributed Systems Online, 2005.
• efficient distribution of live streams in a real-time manner over a large population of spectators with good QoS [4].
• [4] J. Liu, B. Li, and Y.-Q Zhang, "Adaptive Video Multicast Over the Internet", IEEE Multimedia, 2003.
• Efficient and scalable live-streaming overlay construction [8]
• [8] S. Banerjee, C. Kommareddy, K. Kar, B. Bhattacharjee, and S. Khuller, "Construction of an Efficient Overlay Multicast Infrastructure for Real-Time Applications", in Proceedings of IEEE INFOCOM, 2003.
• locality-aware strategies [10][11] and optimization schemes such as DONet in CoolStreaming [12], Narada in ESM [13],
• [10] Y. Liu, X. Liu, L. Xiao, L. Ni, and X. Zhang, "Location- Aware Topology Matching in P2P Systems", in Proceedings of IEEE INFOCOM, 2004
• [11] T.S.E. Ng and H. Zhang, "A Network Positioning System for the Internet", in Proceedings of USENIX, 2004.
• [13] Y. Chu, S. G. Rao, and H. Zhang, "A Case for End System Multicast," in Proceedings of ACM SIGMETRICS, 2000.

Goal:

• The tree-based structures are constrained by the limited end-user upload bandwidth which limits the tree fan-out leading to large tree depths. This leads to high playback delays for leaf users and renders these systems susceptible to nodes leaving the system.
  • average residential broadband download rates in the United States are around 2.8 Mbps, the corresponding upload rates average to only about 500 kbps (see [9] for current statistics).
• Provides an analytical basis for selecting the fragment size, the peer group size and the buffer size
• Allows service providers to estimate the server-side capacity needed to support a targeted number of users at a given streaming rate.

Result

• efficiency is not sensitive to the size of the peer group for groups larger than 15-20 users.
• a similar threshold exists for the number of fragments available for sharing at any given time.
  • if the number of fragments available for sharing is doubled from 5 to 10, the efficiency increases from 0.8 to 0.9
• the efficiency for BitTorrent-like fragment exchange: f(k, N)
  • k : > 7-8 : 15
  • N: > 30
• around 6 seconds, achieve 97.5% utilization of the peer upload capacity
• we need 40 fragments of buffering or a fragment size of 13.5 KB.

Refer:

• scalability of peer-to-peer solutions [8]
  • [8] S. Tewari and L.Kleinrock, “Proportional Replication in Peer-to-Peer Networks”, in Proc. of IEEE INFOCOM 2006, April 2006.
• the connectivity considerations are same as that for an Erdos-Renyi random graph [19]).
  • [19] Bollobas. B, Random Graphs, Academic Press, London, 198.
• where the fragments close to missing the playback deadlines are requested with a higher priority (see [7]).
  • [7] A. Vlavianos, M. Iliofotou, and M. Faloutsos, “BiToS: Enhancing BitTorrent for Supporting Streaming Applications”, in Global Internet Workshop in conjunction with IEEE INFOCOM 2006, April 2006.
  • While [7] provides insights into designing fragment request policies, they only mention the importance of appropriate buffer size selection and do not explore it.
• Reference [16] suggests modifications to peer selection and fragment request policies to support streaming applications
  • [16] G. Wu, T.C. Chiueh, “How Efficient is BitTorrent?,” in 13th Annual Multimedia Computing and Networking (MMCN’06), January 2006.

Contribution

• a framework in which to analyze these P2P applications from a single observable point

Result

1、analyze control traffic to present a probable operation model

• about 40% of the packets are 40 byte packets. These packets are pure acknowledgments
• 50% of packets are greater than 1 KBytes, e.g. 1400 bytes, MTU for IP over Ethernet.
• 10-20% packets that are in between, are control packets.
• total amount of bandwidth used by the control packets is thus on the order of 5% of the total bandwidth.

2、Basic

• any pair of hosts that exchange more than 4KBps worth of data have data flow between them
• update.pplive.com to auto update
• http://list.pplive.com/ and sends an HTTP request GET /web/xml/all.xml. This is an xml file containing the list of available channels. This list is retrieved once at the initial startup time and is written in the client hard disk as channel.xml.
• From that point onwards, there is no UDP communication with the host.

3、Analysis

• To analyze the data collected, we defined key objects and relationships between them.
• Parent and Child relationships
• R(A,X, t1) > Rp where Rp is 4KBps
• geographical analysis
• a database of subnets and their longitude and latitude to calculate the cartesian distance between a pair of hosts.
• 80% of the hosts match the geographical database.
• cost metric: associated with download and is measured in miles per byte.
• neighbors
• a stability of a distribution structure in terms of the frequency of changing the parents for a host. We have two slightly different notions for change in this regard.
• Sn = 1 − (|Pn−1 & Pn|)/ |Pn|
• Xn = 1 − |Pn|/(|Pn| + |An| + |Ln|)
• The parents send 100-200Kbps of data and there are 3-5 parents for this host. The number of children is much higher, 15-20, each one is being sent about 100-200Kbps.
• About 1% of the hosts communicated with became parents, while only about 2% of them became children.
• we use interval of 20 seconds, on average, 3 out of the 4-5 parents are different from one interval to the other.
• cost of downloading data
• about 13K miles per byte. That is approximately the distance across the pacific ocean. On further visual investigation of the parents, it is clear that almost all of the parents are hosts in Asia.
• believe that the system chooses parents solely based on performance.
• about 60% of the children are in Asia (13K miles) while the other 40% are either in the US or Europe.
• This fact also reaffirms the hypothesis of a random structure, that does not account for locality while making decisions about selecting parents for a particular client.
• has an even greater impact on network bandwidth utilization and control than P2P file transfer applications
• Security
• most of the control protocols are not encrypted. This can lead to malicious attacks that can make key components of the system ineffective. The messages are sent over HTTP, UDP and TCP in plain text and can be used to interfere with the normal operation of the system.

Refer

• A lot of interesting research and encouraging results.
• [1] S. Banerjee, B. Bhattacharjee, and C. Kommareddy. Scalable Application Layer Multicast. In Proceedings of ACM SIGCOMM, August 2002.
• [3] M. Castro, P. Druschel, A. Kermarrec, A. Nandi, A. Rowstron, and A. Singh. SplitStream: High-bandwidth Content Distribution in Cooperative Environments. In Proceedings of SOSP, 2003.
• [4] Y. Chawathe. Scattercast: An architecture for Internet broadcast distribution as an infrastructure service. Fall 2000. Ph.D. thesis.
• [5] Y. Chu, S.G. Rao, and H. Zhang. A Case for End System Multicast. In Proceedings of ACM Sigmetrics, June 2000.
• [7] J. Albrecht D. Kostic, A. Rodriguez and A. Vahdat. Bullet: High Bandwidth Data Dissemination Using an Overlay Mesh. In Proceedings of SOSP, 2003.
• [11] P. Francis. Yoid: Your Own Internet Distribution, http://www.aciri.org/yoid/. April 2000.
• [12] J. Jannotti, D. Gifford, K. L. Johnson, M. F. Kaashoek, and J. W. O’Toole Jr. Overcast: Reliable Multicasting with an Overlay Network. In Proceedings of the Fourth Symposium on Operating System Design and Implementation (OSDI), October 2000.
• [16] J. Liebeherr and M. Nahas. Application-layer Multicast with Delaunay Triangulations. In IEEE Globecom, November 2001.
• [17] A.M. Kermarrec M. Castro, P. Druschel and A. Rowstron. Scribe: A large-scale and decentralized application-level multicast infrastructure.
• In IEEE Journal on Selected Areas in Communications Vol. 20 No. 8, Oct 2002.
• [18] V.N. Padmanabhan, H.J. Wang, and P.A Chou. Resilient Peerto- peer Streaming. In Proceedings of IEEE ICNP, 2003.
• [21] Sylvia Ratnasamy, Mark Handley, Richard Karp, and Scott Shenker. Application-level Multicast using Content-Addressable Networks. In Proceedings of NGC, 2001.
• [25] S.Q.Zhuang, B.Y.Zhao, J.D.Kubiatowicz, and A.D.Joseph. Bayeux: An Architecture for Scalable and Fault-tolerant Widearea Data Dissemination, April 2001. Unpublished Report.
• [28] W. Wang, D. Helder, S. Jamin, and L. Zhang. Overlay optimizations for end-host multicast. In Proceedings of Fourth International Workshop on Networked Group Communication (NGC), October 2002.
• deployment scenario described in [6], [29].
• [6] Y.-H. Chu, A. Ganjam, T.S. Eugene, S. Rao, K. Sripanidkulchai, J. Zhan, and H. Zhang. Early experience with an interet broadcast system based on overlay multicast. USENIX Annual Techincal Conference, June 2004.
• a new breed of P2P video streaming applications has emerged [19], [20], [24], [27].
• ISP include
• In [15], the authors claim that ISP’s need to be included into the model so that the data exchanged between the ISP’s can be controlled.
• [15] T. Karagiannis, P. Rodriguez, and K. Papagiannaki. Should Internet Service Providers Fear Peer-Assisted Content Distribution. In Proceedings of IMC, pages 63–76, October 2005.
• NAT traverse
• These systems need to implement NAT identification and traversal using well-known protocols, such as STUN and TURN [22], [23] to deal with such connectivity restrictions.

Long Vu, UIUC

Basic Result

• over 50% of the captured peers are non-responsive:
• PPLive peers are impatient.: 50% peers < 10min, 60% peers < 20min, 90% < 100min
• short-term sessions, e.g. < 50min depend on channel characteristics, while long-term sessions, e.g. > 100min, depend on user preference.

Channel size

• 2800 at 20:00, more volatile, diurnal,
• variation is somewhat self repeating and perhaps even predictable (crests and troughs occur at predictable times).

degree distribution

• average node degree varies but stays within a small range - between 30 to 43.
• the degree distribution in file sharing p2p networks is scale-free and hence likely small world [5][4].
• like file sharing p2p overlays, the average node degree is also independent of the channel size. However, the structure of overlay is closer to random graphs, under certain situations.
• Clustering Coefficient
• The distinction between a random and a non-random graph can be measured by a metric called Clustering Coefficient. (CC).
• Watts and Strogatz first used CC to characterize graphs in [22].
• for a random node u with two neighbors v and w in its partner list, the CC is the probability that either v is in w’s partner list, or vice versa.
• For a random graph, the value of CC will be closer to the unconditional probability (i.e., even if v and w were not neighbors of u) that either v is w’s neighbor, or vice-versa. The farther the CC is from the above value, the less random (i.e., more clustered) the graph is.
• small channels (with as many as 500 nodes), peers indeed connect fairly randomly to each other.
• Nodes in the same snapshot have correlated availability

Refer

• Gnutella overlay
• the more prominent overlay studies among these are by Ripeanu et. al. [4] on Gnutella, by Saroui et. al. on Naspter and Gnutella [5], and by Bhagwan et. al. on Overnet [6].
• [4] M. Ripeanu, I. Foster, and A. Iamnitchi, ..Mapping the Gnutella network: Properties of large-scale peer-to-peer systems and implications for system design.,. IEEE Internet Computing Journal, vol. 6, no. 1, 2002.
• [5] Saroiu, P. K. Gummadi, and S. D. Gribble, .Measuring and analyzing the characteristics of Napster and Gnutella hosts,. Multimedia systems, 2003.
• [6] R. Bhagwan, S. Savage, and G. Voelker, .Understanding availability,. in IPTPS, 2003.
• tree-based multicasts
• [8] Y. hua Chu, S. G. Rao, and H. Zhang, .A case for end system multicast,. ACM SIG-METRICS, 2000.
• [9] S. Banerjee, B. Bhattacharjee, and C. Kommareddy, .Scalable application layer multicast,. in ACM SIGCOMM, 2002.
• [10] D. A. Tran, K. A. Hua, and T. Do, .Zigzag: An ef_cient peer-to-peer scheme for media streaming,. in IEEE Infocom, 2003.
• receiver-driven p2p streaming
• [11] M. Hefeeda, A. Habib, D. Xu, B. Bhargava, and B. Botev, .Collectcast: A peer-to-peer receiver-driven overlays,. in ACM Multimedia, 2003.
• [12] X. Zhang, J. Liu, B. Li, and T.-S. P. Yum, .Donet: A data-driven overlay network for ef_cient live media streaming,. IEEE Infocom, 2005.
• [13] R. Rejaie and S. Stafford, .A framework for architecting peer-to-peer receiver-driven overlays,. in ACM NOSSDAV, 2004, pp. 42 . 47.
• chunk-driven p2p streaming
• pplive, coolstreaming
• NAT tranverse
• If a PPLive node is inside NAT or firewalls, UDP in the above steps may be replaced by TCP - further details are in [15].
• [15] X. Hei, C. Liang, J. Liang, Y. Liu, and K. W. Ross, .A measurement study of a large-scale P2P IPTV system,. Polytechnic U., Tech. Rep., 2006.

Rakesh Kumar

Result

• performance is largely determined by a critical value.
• a certain ratio of traffic loads exceeds the critical value
• buffering can bring more improvement than can additional infrastructure bandwidth.

Basic

• In P2P streaming systems, participating nodes are very heterogeneous, particularly in terms of the amount of upload bandwidth they contribute [9].
• Broadly speaking, a P2P streaming system performs well if all participating peers can continuously playback the video (without freezing or skipping) with a small playback delay.

Model

• Server upload rate: Us bps
• Video rate: r bps
• two-class model
• Super peer upload rate: U1
• Ordinary peer upload rate: U2. (500kbps or less)
• Assumption: U2 < r < U1
• Peers join and leave the P2P streaming system at random times..
• Join: Poison processes. Join rate:λi
• 1/μi for the average amount of view time
• Pi(t): peer number, M/G/∞ processes [10].
• Poisson distribution with mean E[Pi] = ρi =λi /μi

Streaming: focus on the instantaneous rate

bufferless model:

• when all participating peers receive the video at rate r, we say that the system provides universal streaming.
• maximal average rate is a function of P1(t) and P2(t), denote it as φ(P1(t), P2(t)) ≥ r. decided by streaming protocol.

Without churn

• ui denote of the upload capacity of peer i
• bits arrive to the server at rate r – video rate
• maximum achievable rate rmax: the maximum value of r for universal streaming
• rmax = min{us, (us + Sum(ui))/n }.
• denote u(P) = Sum(ui)

Case 1. if us ≤ (us + u(P))/n

• Split us into n substream. si = ui u(P)/us
• because (n - 1)si ≤ ui :
• so can reach r = us

Case 2. if > ,

• Divide this video stream into n+1 substreams,
• si = ui/(n -1), sn+1 = (us - u(P)/(n –1))/n
• server copy two substreams to each peer i: the ith substream and the (n + 1)st substream.
• r = (us + u(P))/n can be supported.

Corollary 1: For any rate r such that u2 < r < u1, universal streaming is achievable by some fluid distribution scheme if and only if r ≤ φ(n1, n2), where φ(n1, n2) = min{us, (us + n1u1 + n2u2 )/(n1 + n2 )}.

With Churn:

universal streaming probability. Let Pi be the random variable denoting the number of active type-i peers in steady state. It is well-known that Pi has a Poisson distribution with mean E[Pi] = ρi.

P(universal streaming) = P(P1 ≥ cP2 - u′s), Where c = (r - u2)/(u1 – r), and u′s = us/(u1 – r)

Since P1 and P2 are independent Poison random variables, we can explicitly calculate the universal streaming probability as follows.

xxxx

Large System Analysis

Scaling, i.e. ρ1 → ∞ and ρ2 → ∞,

Using scaling regimes ρ1 = Kρ2 + β* sqrt(ρ2)

P(universal streaming) =

• 1 if K > c
• F( -β/ sqrt(c+c*c) ) if K = c, where 1 - F(·) is the distribution function of the standard normal random variable.
• 0 if K < c

Proof:

• Define the normalized random variables X1 = (P1 - ρ1)/sqrt(ρ1)
• c is the threshold for K ~ρ1/ρ2
• P(universal streaming) ≈ F((ρ1 - cρ2)/√ρ2 )/√(c + c*c)).

Result evaluation:

• r = 3, u1 = 1, u2 = 7, so c = 0.5,
• 1/μ1 = 1/μ2 = 0.5 hr
• ordinary peers λ2, super peers in vicinity of λ2/2
• small sys λ2 = 100/hr
• big sys:λ2 = 10,000/hr, ρ2 = λ2/μ2 = 5,000
• so ρ1/ρ2 =λ1/λ2

Usage:

• trend evaluation when ρ1/ρ2 increase, the degraded service probability decrease.
• The effect of increase Us.
• The critical ρ1/ρ2 area.
• Difference between big sys and small sys.

Buffering:

• make average uploading rate in the system exceeds r.
• to set the server buffer size to d, and to have the server drop at rate r - φ(t) from the head of the buffer when the server buffer is full.
• built a simple simulation tool to analyze the affects of buffering as well as the distribution of degraded-service durations.
• different buffer capacities of 0, 30, 60 and 120 seconds of video.
• when operating at ρ1/ρ2 = c = 0.5, With buffering, degraded service probability drops from 50% to approximately 5%.
• 30-second lag is sufficient to obtain almost all the potential buffering gains from buffering.
• 30 seconds lag is more effective than deploying 10 times the server capacity for this large system.
• degraded-service durations: decreases by a factor of 10 by increasing the buffer sizes.
• For under-capacity region for which ρ1/ρ2 < c + e. need special processing.

Refer

BT fluid model

• [15] D. Qiu and S. Srikant, “Modeling and Performance Analysis of BitTorrent-Like Perr-to-Peer networks,” ACM SIGCOMM 2004, August 2004, Portland, Oregon.
• The model accounts for churn, and views the number of seeds and leechers as fluid quantities. They develop simple differential equations for the fluids and solve the equations in steady state.
• [4] F. Clevenot, P. Nain and K.W. Ross, “Multiclass P2P Networks: Static Resource Allocation for Bandwidth for Service Differentiation and Bandwidth
• The multiclass fluid model leads to a non-linear system of differential equations with special structure.
• They prove the system of differential equations admits a unique stable equilibrium, which is computed in closed-form.
• The fluid models in [15] and [4] are not applicable to streaming systems with heterogeneous upload rates, since there is no notion of leechers(水蛭) transitioning to seeds.

Modeling the time it takes to distribute a file from seeds to leechers in churnless download systems.

• [12] J. Mundinger, R. R. Weber and G. Weiss, “Analysis of Peer-to-Peer File Dissemination amongst Users of Different Upload Capacities,”Performance Evaluation Review, Performance 2005 Issue.
• studied the problem for heterogeneous peers with infinite download capacity, both for chunkbased and fluid-based systems [12].
• Kumar and Ross derived an explicit expression for the minimum download time in a general heterogenous fluid system with finite download rates. They also extended this result to multi-class systems with first and second-class leechers.
• [2] E.W. Biersack, P. Rodriguez and P. Felber, “Performance Analysis of Peer-to-Peer Networks for File Distribution,” In proceedings of Quality of Future Internet Services (QOFIS04), September 2004, Barcelona, Spain.
• used a chunk-based model to derive expressions for the distribution time for a several practical overlay topologies.

M/G/∞ processes [10].

• [10] L. Kleinrock, “Queueing Systems, vol. I: Theory,” John Wiley and Sons, 1975.

Xiaojun Hei, Chao Liang, Jian Liang, Yong Liu and Keith W. Rossy

Basic:

• - a dedicated PPLive crawler
• - viewing behaviors as regular TV users
• - peer dynamically with a large number of peers
• - super peers act as video proxy
• - long start-up delays and playback lags, ranging from several seconds to a couple of minutes.
• - PPLive: Spring Festival Gala 2006, 200,000 users 400-800 kbps range

Deviation with BT

• - no reciprocity mechanisms deployed
• - video chunk scheduling is required
• - BT size < 1000. need gossip peer search algorithms

1. Meas

• - improve on [13] to trace peers behind NAT/firewalls.
• - offset field 4 bytes, 340 kbps, chunk size of 14 Kbytes
• - get buffer map by TCP, request one or more chunks by TCP.
  • - likely, get chunk with priority, e.g. the earlier chunk, the rarest chunk
• - continually searches for new partners
• - port of internal streaming engine HTTP server. 8888
• - active crawling to obtain user behaviors and global view
• - passive sniffing to gain insight from the perspective of residential users and campus users
• - round by round, in each round T, first crawl peer list S second and then sleep.
• - Ethereal
• - built our own customized PPLive packet analyzer to analyze the various fields in the various PPLive signaling and content packets.
• - Data were obtained at different granularities, including byte-level, packet-level and session-level
• - CCTV3-Campus, 784M Byte trace on 2hr. in it, 360M download video. 4.5G upload

Basic Result

• - chunk size > 14K bytes (the exact chunk size depends on the bit rate). the maximum payload size of a TCP segment (typically 1460 bytes), so a video tcp chunk should have > 10 tcp segment.
• - signaling overhead: 5% - 8%
• - traffic redundancy: small 13.8%. first 10 minutes of the traces are not used.
• - signaling by UDP/TCP. video only by TCP
• - Duration of Video
  • TCP Connections: SYN -> FIN, or 2min no data.
  • median 22.5 seconds, mean is 381.1 seconds. 10% of the connections last for over 15 minutes and the longest session lasts for more than 2 hours.
• - Neighbors. campus: 40, home, cctv3 20, cctv10 5.
  • - top peer contribute 50% in download, but dynamic from 350kbps to 0.
  • top only take 5% in upload. on average: SN
• - a true mesh overlay
  • - exists bidirectional video traffic exchange between a pair of peers even in a small time scale (< 1 minute).

2. Crawler

• - To obtain all participating peers and monitor
• - get from multiple peerlist servers and peers
• - Steps
  • - Peer Registration
    • - 128 bit channel identifier
    • - IP, TCP and UDP ports
    • - random peer ID
  • - Bootstrap
    • - bootstrap peer list query message to each peer-list root server
    • - 50 peers, IP and ports (TCP, UDP?)
  • - Peer Query
• - Peer behind NAT no response. > 50%
• - can find 95% peers in 5s, T = 60s, S = 15s
• - evaluation:
  • - use a controlled node to test, 33 experiments, arrival lag was 31.6 seconds; departure lag was 104.2 seconds.
  • - sojourn (寄居) time lag: 70s longer. average sojourn times: 800 - 1600 seconds
  • - peer life time lag overestimates number of active peers.
    • Little law, overestimate ratio 70/X, X real average peer sojourn time measured in seconds.
  • - Consequently, the active peer numbers we subsequently report overestimate the real active peer numbers by 5~9%.
• Arrive and departure
  • - users evolve over time: diurnal trend
  • - a sharp jump from 50K to 200K at 7:00pm for new year festival. scale well
  • - join and leave at a higher rate at peak times
  • - Peer arrival rate ~ Peak number. Max: 150-200/minute
  • - Peer departure rate:
    • - movie channel: batch-departure when program end -> expect lower peer churn rates in the middle of a program. Max: 1200/minute. Although it is big, but program is end, so no problem. The general rate: 100-200/min
    • - tv channel: no periodic batch departure pattern: 150-200/min
  • - 90% of peers for both programs have lifetimes shorter than 1.5 hours.
• - buffer level and playable content size: 0-10M, 50% with 7M.
  • Hei et al. [9] also observe that peers seem to strive for buffer levels of 7 Mbytes or higher by analyzing actively crawled cache bitmap but also didn’t dive in deeper.
• - lag up to 140s

3. Refer

• - chunk scheduling:
  • [14] BT: http://bittorrent.com/
  • [4] X. Zhang, J. Liu, B. Li, and T.-S. P. Yum, ¡°DONet/CoolStreaming: A Data-driven Overlay Network for Peer-to-Peer Live Media Streaming,¡± in IEEE INFOCOM, vol. 3, Mar. 2005, pp. 2102 ¨C 2111.
    • Performance evaluation over PlanetLab [4] and showed that mesh-pull live streaming systems achieve significant more continuous media playback than tree based systems.
  • [13] –, "A measurement study of a large-scale P2P IPTV system, Polytechnic University, Tech. Rep., May 26 2006. [Online]. Available:
  • http://cis.poly.edu/"ross/papers/P2PliveStreamingMeasurement.pdf
• mesh-pull live streaming systems achieve significant more continuous media playback than tree based systems
  • [20] X. Zhang, J. Liu, and B. Li, "On large-scale peer-to-peer live video distribution: Coolstreaming and its preliminary experimental results," in IEEE MMSP’2005, Oct. 2005.
• another prototype
  • [21] J. Liu, S. G. Rao, B. Li, and H. Zhang, "Opportunities and challenges of peer-to-peer Internet video broadcast," Nov. 2006.
• broadcasting video over the Internet
  • [22] R. Rejaie, "Anyone can broadcast video over the Internet," Commun. ACM, vol. 49, no. 11, pp. 55-57, 2006.
• a number of mesh-pull P2P streaming systems
  • [23] V. Pai, K. Kumar, K. Tamilmani, V. Sambamurthy, and A. E. Mohr, "Chainsaw: Eliminating trees from overlay multicast," in IPTPS’05, Feb. 2005.
  • [24] M. Zhang, L. Zhao, Y. Tang, J.-G. Luo, and S.-Q. Yang, "Large-scale live media streaming over peer-to-peer networks through global Internet," in P2PMMS’05, 2005, pp. 21-28.
  • [25] C. Dana, D. Li, D. Harrison, and C. N. Chuah, "BASS: BitTorrent assisted streaming system for video-on-demand," in IEEE MMSP, Oct. 2005.
  • [26] X. Liao, H. Jin, Y. Liu, L. M. Ni, and D. Deng, "AnySee: Peer-to-Peer live streaming," in IEEE INFOCOM, Apr. 2006.
  • [27] F. Pianese, J. Keller, and E. W. Biersack, "PULSE, a flexible P2P live streaming system," in Global Internet, Apr. 2006.
  • [28] A. Vlavianos, M. Iliofotou, and M. Faloutsos, "BiToS: Enhancing BitTorrent for supporting streaming applications," in Global Internet, Apr. 2006.
  • [29] N. Magharei and R. Rejaie, "Understanding mesh-based peer-to-peer streaming," in NOSSDAV ‘06, May 2006.
  • [30] T. Piotrowski, S. Banerjee, S. Bhatnagar, S. Ganguly, and R. Izmailov, "Peer-to-peer streaming of stored media: the indirect approach," in SIGMETRICS ‘06/Performance ‘06, 2006, pp. 371-372.
• theoretical studies of mesh-pull streaming systems
  • [18] R. Kumar, Y. Liu, and K. W. Ross, "Stochastic fluid theory for P2P streaming systems," in Proceedings of INFOCOM, 2007.
    • - show buffering can significantly improve video streaming quality.
  • [31] S. Tewari and L. Kleinrock, "Analytical model for BitTorrent-based live video streaming," in IEEE NIME 2007 Workshop, Jan. 2007.
• Gnutella
  • measurement of Napster and Gnutella [35] and detailed characterization of end-user hosts in these two systems.
    • [35] S. Saroiu, K. P. Gummadi, and S. D. Gribble, "Measuring and analyzing the characteristics of Napster and Gnutella hosts," Multimedia Syst., vol. 9, no. 2, pp. 170-184, 2003.
  • monitor of KaZaa traffic [36] and showed locality-aware P2P file-sharing architectures can achieve significant bandwidth savings.
    • [36] K. P. Gummadi, R. J. Dunn, S. Saroiu, S. D. Gribble, H. M. Levy, and J. Zahorjan, "Measurement, Modeling, and Analysis of a Peer-to-Peer File-sharing Workload," in ACM SOSP, 2003, pp. 314-329.
  • Ripeanu et al. crawled the one-tier Gnutella network to extract its overlay topology. For the latest two-tier Gnutella network, Stutzbach et al. provided a detailed characterization of P2P overlay topologies and their dynamics in [37].
    • [37] D. Stutzbach, R. Rejaie, and S. Sen, "Characterizing Unstructured Overlay Topologies in Modern P2P File-Sharing Systems," in ACM IMC, Oct. 2005.
  • Liang et al. deployed active crawling in [38] to reveal in-depth understanding of KaZaa overlay structure and dynamics.
    • [38] J. Liang, R. Kumar, and K. W. Ross, "The FastTrack Overlay: A Measurement Study," Computer Networks, vol. 50, no. 6, pp. 842-858, Apr. 2006.
  • In [39], Liang et al. further demonstrated the existence of content pollution and poisoning in KaZaa using an active crawler.
    • [39] J. Liang, N. Naoumov, and K. Ross, "The Index Poisoning Attack in P2P File-Sharing Systems," in IEEE INFOCOM, Apr. 2006.
• measurement study of live streaming workload from a large CDN
  • [40] K. Sripanidkulchai, B. Maggs, and H. Zhang, "An analysis of live streaming workloads on the Internet," in ACM IMC, 2004, pp. 41-54.
• measurement results for BitTorrent content distribution.
  • [41] M. Izal, G. Urvoy-Keller, E. W. Biersack, P. Felber, A. A. Hamra, and L. Garc´es-Erice, "Dissecting bittorrent: Five months in a torrent’s lifetime." in PAM, 2004, pp. 1-11.
  • [42] J. Pouwelse, P. Garbacki, D. Epema, and H. Sips, "The Bittorrent P2P File-sharing System: Measurements and Analysis," in IPTPS’05, Feb. 2005.
• protocol analysis of Skype and Skype traffic pattern
  • [43] S. A. Baset and H. Schulzrinne, "An Analysis of the Skype Peer-to-Peer Internet Telephony Protocol," in IEEE INFOCOM, Apr. 2006.
  • [15] S. Guha, N. Daswani, and R. Jain, "An Experimental Study of the Skype Peer-to-Peer VoIP System," in IPTPS’06, Feb. 2006.
• - free MaxMind GeoIP database [16]
  • [16] "Maxmind," http://www.maxmind.com/app/country.
• - file-sharing monitoring companies (such as Big Champagne [17]
  • [17] "Big champagne," http://www.bigchampagne.com/.

Basic：

• - 100,000 simultaneous users in one channel
• - video bit rates 250 Kbps to 400 Kbps with a few channels 800 Kbps. 340k for cctv3 and 312 for cctv10
• - TCP for both signaling and video streaming
• - Nevertheless, various web sites and message boards provide additional information.
• - passive packet sniffing

1. fundamental mechanisms

• - collected from different sources and confirmed by our own measurement results.
• - a gossip-based protocol for peer management and channel discovery
• - a P2P-based video distribution protocol

2. Signaling

• - joins the PPLive network and becomes a PPLive peer node
• - a query message to the PPLive channel server to obtain an updated channel list
• - sends out multiple query messages to some root servers to retrieve an online peer list(IP+Port) for the channel
• - sends out probes to peers on the list to find active peers for the channel.
• - some active peers may also return their own peer lists, helping the initial peer to find more peers.

3. sharing

3.1. double buffering mechanism

• - two buffers in local memory: the PPLive TV engine buffer and the media player buffer
• - two goals: pre-cache media content to combat download rate variations, efficient content distribution between peers.

3.2. reassembled

• Received video chunks are reassembled in order and buffered in the queue of the PPLive TV engine, forming a local streaming file in memory.

3.3. play

• - When the streaming file length crosses a predefined threshold, the PPLive TV engine launches a media player, which downloads video content from the local HTTP streaming server.
• - media player have built-in video buffering mechanisms. After the buffer of the media player fills up to the required level, the actual video playback starts.

3.4. download strategy

• - first download aggressively to quick start, then stablize
• - if rate fluctuation seriously, aggressively again(find new peers), then stablize again
• - possible downloads duplicate media content from multiple peers.
• - TV engine streaming to media player at the media playback rate.-

4. meas

• - 4 pc
• - cable modem.
• - Ethereal [5]
• - 2hr trace, cctv3 and 10
• - counted an IP address in traces if there was a TCP connection attempt (TCP SYN packets) between the traced peer and this IP address.

5. meas result

• - correlation between TCP session durations and average TCP segment size
  • - cumulative large packets (> 1200 bytes) > 10, video session; otherwise, signaling session.
  • - filter all packets less than 1200 bytes within a video session (because video session also has signaling interaction)
• - table 1 observation:
  • - churn: active ip/total ip, 30%
  • - fair: LAN 1:12, Home 1:1 and 1:0
  • - video session duration: 1s -> 10,000s. average 20s, 10% > 15min.
    • - long tail distribution?
  • - among all partner peers of one peer, the top peer almost contributes about 50%, but highly dynamic.
• - dynamic from inherent rate variation of the TCP, but aggregated video download rate smoother
• - popup delay: 10-15s, player buffer delay: 10-15s
• - download redundancy:
  • - Excluding TCP/IP headers to get total streaming payload
  • - extract video traffic
  • - compare with the real media segment size
  • - cctv3: residence, 13.8%. cctv-10 campus: 0.76%, cctv-10 residence: 9.5%.
• buffer size:
  • - close TV engine, media player buffer size: at least 5.37 Mbytes = 100s 400kbps
  • - disconnect PC from net, launch an HTTP file download software to download the media file from the PPLive streaming server. estimated PPLive buffer size varies from 7.8 MBytes to 17.1 MBytes. = 150s – 300s 400kbps. BL = 1500-3000 chunks. 0.1s/chunk.
• - geographic location. first byte prefix matching,

6. buffer manage

• - adaptively allocates buffer size according to the streaming rate and the buffering time period specified by the media source.

7. neighbors

• - cctv3 LAN: 40 neighbors. home 25 neighbors.
• - cctv10 LAN: 15 neighbors. home 8 neighbors.
• - constantly changes its upload and download neighbors.
• - in 30s, LAN less than 10% change, Home more
• - download from Asia and upload to U.S

8. Refer

[1] S. Cherry, The battle for broadband Internet protocol television, IEEE Spectrum, vol. 42, no. 1, pp. 24 ¨C 29, Jan. 2005.

[2] R. Jain, I want my IPTV, IEEE MultiMedia, vol. 12, no. 3, p. 96, 2005.

Xiaojun Hei, Yong Liu and Keith W. Ross

1. buffer bitmap crawler (buffer maps)

• - utilizes both UDP and TCP transport for collecting peer lists
• - TCP for collecting buffer maps from many remote peers during the same period of time.

2. passive sniffing nodes

• - WinDump [26]
• - three nodes

3. Quality metrics

3.1 network-wide playback continuity

• - tracks the sequence numbers of the arriving media objects and the presentation time of the latest media object
• - The streaming engine will start the player when the size of the cached playable video size exceeds a specified user configuable pre-buffering video threshold
• - t be the initial playback pre-buffering delay, which is specified in the streaming engine.
• - when presentation o\duration of buffered object > pre-buffering delay, playback continue
• - BM playable video remains less than 5 chunks for 4 seconds, we say a freezing event occurs at t1. A freeze event ends when the BM playable video is larger than the pre-buffering time of the stream.
• - CCTV9
• - CCTVnews, 700 peers -> 1400 peers in 30 min, 868 peers 41.9% reboot, 1054 peers 3% reboot, then return to 827, 4.1% reboot.
• - may related to user behavior? churn in the start? but it is 5hrs later
• - may related to chanel charateristics? cctv3 is for Entertainment and cctv8 is for TV set, duration is relatively long
• - CCTV1, 605 peers, only 4.8% reboot
• - user number: n:1:3:8:9 = 4:3:6:3:1
• - more user, more startup time? strange.
• - need use user number as x-axis to analyze.

3.2 startup latency

• - 150s

3.3 playback lags among peers : minutes

• - 3 monitors node
• - 150s for 1hr period, max 200s

4. chunk propagation

• - life time: 210s in one peer and 250s in network
• - chunk availability percentage: reach 65% in 20s. converge to 80%. Disappear after 200s.
• - a mediate parameter for modeling distributing performance
• - chunk retrieval ratios, a parameter for the final user aware performance.
• - for cctv-n, CRR is high, also only 90%. reach 65% in 20s. converge to 95%.

5. system design choices guide

5.1 algorithms for creating peering partners

5.2 scheduling algorithms (for both uploading and downloading)

5.3. video encoding algorithms

我的问题：

1.1 PPLive has build-in performance monitor system?

• - it has an experiment network.

1.2. copy to media player

• - Windows media SDK.
• - a media file, often WMV - Advanced Systems Format (ASF) [25].
• - ASF: file header + media objects
• - file header: buffering time?
• - media object header: sequence number, number of streams carried in the object, playback duration of the data object

1.3. Chunk

• - e.g. 0.1s
• - corresponding unit in video codec? - Asf encapsulation

1.4. playback deadline

• - who find a chunk does not arrive before its playback deadline? MP report waiting.
• - may media player, when it find, shall it actively prefetch from streaming engine for it? – report. if streaming engine still can not provide? it fails.
• - media player notify streaming engine for it to reboot
• - the actual playback point is somewhere in the middle of the BM playable video

1.5. Offset

• - Under normal circumstances, the buffer map offset should increase at a constant rate: if this rate varies significantly, PPLive reboot occurs.
• - r = 10 blocks/sec
• - We see that when there is a sudden increase in the offset rate, a reboot occurs. Fig 9

1.6. BM width

• - BM width: 2300
• - BM playable width: 2200

1.7. peering topology

• - peering links are not purely random. They are driven by peer visibility and chunk availability, which are largely determined by the peers’ network connections and their locations in the streaming system.
• - one can expect some structure in peering topology. can infer this topology by playback differences
• - relative playback differences are quite stable over the one-hour time period. but in bigger period? it indicates stable peer partner relationship, i.e. low churn ratio.

1.8. CRR 95%, but reboot/freeze peer ratio in 1hr only 2.2%/0.6% for cctv-n in [5,6]hr 1414 peers.

• - CRR <-> R/F ratio

1.9. modeling parameter

• - input:
• - n,
• - churn rate,
• - video rate
• - sys algorithm:
• - - peer partner selection
• - chunk propagation algorithm
• - cache management
• - topology. SN
• - output:
• - freeze/reboot ratio,
• - startup time,
• - lag time
• req
• given the i/o, the possible max bit rate
• given the i/o, how to reach the max bit rate
• freeze/reboot ratio = f(n), f()?

2. Reference

2.1 passive sniffing

Passive sniffing techniques are often constrained to measure a small set of controlled peers.

2.1.1. [11] is the first measurement study of a large-scale P2P streaming system. It considered traffic patterns and peer dynamics of the PPLive IPTV system.

• [11] X. Hei, C. Liang, J. Liang, Y. Liu, and K. W. Ross, Insights into PPLive: A measurement study of a large-scale P2P IPTV system, IPTV workshop in conjunction with WWW2006, May 2006.

[11] was followed by two other passive measurement studies [13] and [21].

2.1.2. Ali et al. [13] focus on the traffic characteristics of controlled PPLive peers on PPLive and SopCast.

[13] S. Ali, A. Mathur, and H. Zhang,  Measurement of commercial peerto-peer live video streaming, First Workshop on Recent Advances in Peer-to-Peer Streaming, Aug. 2006.

2.1.3. Passive sniffing was also utilized to study the traffic pattern of PPLive, PPStream, TVAnts and SopCast in [21].

[21] T. Silverston and O. Fourmaux,  P2P IPTV measurement: A comparison study, University Paris 6 LIP6/NPA Laboratory, Tech. Rep., Oct. 2006.

2.2. active crawling apparatus

2.2.1. measure the global view of the PPLive network [12].

[12] A measurement study of a large-scale P2P IPTV system, IEEE Transactions on Multimedia, Oct. 2007, to appear.

2.2.2. Subsequently, another crawler-based measurement study was conducted in [22]. Vu et al. [22] examine the peer dynamics for a small number of PPLive channels.

[22] L. Vu, I. Gupta, J. Liang, and K. Nahrstedt,  Mapping the PPLive network: Studying the impacts of media streaming on P2P overlays,¡± Department of Computer Science, University of Illinois at Urbana-Champaign, Tech. Rep. UIUCDCS-R-2006-275, Aug. 2006.

2.3. peer selection and chunk scheduling algorithms.

CoolStreaming is documented in [1]

[1] X. Zhang, J. Liu, B. Li, and T.-S. P. Yum,  DONet/CoolStreaming: A Data-driven Overlay Network for Peer-to-Peer Live Media Streaming, IEEE INFOCOM, vol. 3, Mar. 2005, pp. 2102 ¨C 2111.

[26]  Windump, http://www.winpcap.org/windump/.

Yensy James Hall, Patrick Piemonte, and Matt Weyant

这是一篇技术报告。

VoD

1. Meas

• 3 nodes(1 MAC after cable modem, 2 PC after university switch)
• Wireshark
• nineteen days, 64 GB

2. Analysis

• - found geographical location: http://api.hostip.info/get_html.php?ip=
• - could not find the location of 31% of the IP addresses which contributed 4.58% of the data

3. App behavior

• - based on XULRunner, a Mozilla runtime package [11]
• - CoreAVC H.264 codec from CoreCodec [8].
• - signaling traffic is encrypted
• - tracker.ops.theveniceproject.com
• - supernode snode-1.lid.ops.theveniceproject.com
• - negotiates a port number: highly likely that a modified STUN protocol was used, similar to what [4] and [5] observed in their analyses of Skype. UDP or TCP ports?
• - UDP probe (30 bytes) for live detecting
• - TCP and UDP port number 4166, be used in the Now For Friends edition [12]

4. Infrastructure

• - servers on 5 sites, UK London[10], Netherland(Admin node, SN, Web server), Belgium(content servers), Los Angeles[9], California

5. Control it within a network’s boundary

• - port 33333

6. Ctrl and Data traffic

• - [2] use packet sizes to seperate control and data traffic
• Packets under 200 bytes are considered control packets - 45%, and data packets are 1000 bytes or more - 55%.

7. Traffic

• - 700 kbps down and 100-150kbps up
• - rate H.264 : MPEG2 : MPEG4 = 1:2.5:1.75

8. Peer

• - Geographic Locality
  • - experiment 1 fails to get a 1min head peer in local subnet
    • - is this real? only one experiment
    • - if real, need improve here
  • - experiment 2, in all 6918 peers in 23hr, 1:1:1 from UK,US,European.
    • Is peer distribution related by time zone? it is possible
• - 6918 peers in 23hr
  • is big enough? what is it in PPLive? "relatively low user population"
• - "correlation between geographical distance and amount of data was -0.013"
• - Joost server provides 71.24% of the incoming data
  • - How long joost keep download data for sharing? in memory? monitoring the memory.
• - BT Tit-Tac is inappropriate for joost and IPTV/IPVOD.

9. RTT

• - RTT by data size is nonsense. it can not prove RTT is/is not an affect factor for joost peer selection.
• - measure RTT by scriptroute’s ICMP and TCP ping
• - home pc download mainly from Joost server. LAN pc download 52% from Joost server.
• - RTT to joost server is 90-110ms, Hop count: 15-18
  • - Have new feature to select nearest joost server
• - roughly 80% of university client peers are within 200ms but only 10% of home client peers are within the same threshold, other > 600ms.
  • so home pc always download from joost server
• - meas Hop count by scriptroute’s ICMP and TCP traceroute
• - "it is unlikely that Joost selects peers based on topological locality"

10. fairness:

• - sent/receive = 1/2
• - because server provide at least 2/3.

11. Refer

[3] J. Liang, R. Kumar, and K. W. Ross. The KaZaA Overlay: A Measurement Study. In Computer Networks Journal (Elsevier), 2005.

• A comprehensive measurement study of KaZaA’s overlay structure is undertaken in [3]
• looked in depth at the KaZaA and FastTrack overlay networks with both active probing and passive trace analysis.
• The identification of peer-to-peer traffic
• Techniques to analyze and characterize peer-topeer traffic and file-sharing workloads
• The development of crawling systems for Gnutella, Napster, and KaZaA
• A study of scalability issues in the Gnutella network
• A study of the problem of search and replication strategies in unstructured peer-to-peer networks
• A study about the advantages of designing unstructured peer-to-peer systems based on super peers

[2] K. Gummadi, R. Dunn, S. Saroiu, S. Gribble, H. Levy, and J. Zahorjan. Measurement, Modeling, and Analysis of a Peer-to-Peer File-Sharing Workload. In Proceedings of SOSP, 2003.

• [2] discovered that KaZaA does not take advantage of locality to manage its overlay network and proposed performance improvements if KaZaA were localityaware.

[4] S. Guha, N. Daswani, and R. Jain. An Experimental Study of the Skype Peer-to-Peer VoIP System. In Proceedings of IPTPS, February 2006.

[5] S. Baset and H. Schulzrinne. An Analysis of the Skype Peer-to-Peer Internet Telephony Protocol, http://arxiv.org/abs/cs/0412017v1, 2004.

• [4] and [5] examined Skype’s application behavior and supernode infrastructure.

[6] B. Cheng, X. Liu, Z. Zhang, and H. Jin. A Measurement Study of a Peer-to-Peer Video-on-Demand System. In Proceedings of IPTPS, February 2007.

• [6] studied an on-demand P2P video system called GridCast. GridCast was deployed in China in 2006 to over twenty thousand users, hundreds of which were supported concurrently.

Misc

• [7] V. Paxson. Strategies for Sound Internet Measurement. In Proceedings of ACM SIGCOMM Internet Measurement Conference’04, Taormina, Italy, November 2004.
• [1] S. Ali, A. Mathur, and H. Zhang. Measurement of Commercial Peer-To-Peer Live Video Streaming. In Workshop in Recent Advances in Peer-to-Peer Streaming, August 2006.
• http://developer.mozilla.org/en/docs/XULRunner
• http://www.joostteam.com