An Empirical Study of Real Introduction Audio Traffic • Internet is growing • Web facilitates integration of streaming audio – Radio juke boxes A. Mena and J. Heidemann – Broadcast radio USC/Information Sciences Institute – Live concerts • Has been some work on Web and Internet, In Proceedings of IEEE Infocom little audio Tel-Aviv, Israel • This study begins to redress this March, 2000 ! Study RealAudio traffic from Major source Contributions to Understanding Identifying Audio Traffic • Majority of data (60%-80%) is UDP – Limited congestion control • Audio data is mostly unidirectional (from • RealAudio is CBR at 10s of seconds, but at single server), ration 50:1 seconds is bursty on/off • UDP RealAudio flow can be identified by • RealAudio can use 2 flows, one for control and one for data packet length and interdeparture – Most use 2, using UDP for data – Those that use 1 use TCP • So, describe how to simulate audio users • User arrivals correlated with time of day – Like Web • Session lengths are long (mean 78 minutes) – Unlike Web Methodology Outline • Capture 5 long traces from broadcast.com – (Bought by Yahoo! (see link on Web page)) • Introduction • Trace 1 and 2 using sniffer, 3-5 with tcpdump (done) • Methodology • Via CISCO Ethernet switch that replicated traffic " • Results – Minimize impact of measurements on perf – No packets dropped • Simulation – Saved 98 bytes to get audio header, too • Future Work • Conclusions (Trace 1 and 2 not used, much … too short) 1
Outline Terms used in Results • Introduction (done) • IP address of receiver is client • Methodology (done) – Could be proxy or behind firewall • IP address of sender is server • Results " – One for this study, fixed – Overview • User initiates session , with one or more flows – Aggregate – With one or more flows (source-destination pairs) – Users – Control flow: authenticate, start-stop, … – Flows • TCP • Simulation – Data flow: encoded audio information • Inbound traffic – received by server • Future Work • Outbound traffic – sent by server • Conclusions Distribution of Traffic Inbound • Inbound to Outbound ! 1:24 to 1:1 • But 1:1 are mostly when upload from codec – Omit from further analysis Strong time of day Outbound • Other Inbound is primarily acks + feedback correlation – Byte ratios are 28:1, 40:1 and 50:1 Aggregate Traffic Summary of Traffic Traces • Control only small portion of bandwidth – 1% - 3% of bytes • 1/3 TCP, most not HTTP • Overall 99% of all bytes, 98% of all packets are audio • 2/3 UDP • Other is remnants of old flows, connections by admin • No multicast 2
Outline Summary of Audio Flows • Introduction (done) • Identified audio flows by sending 100K or • Methodology (done) more • Results – Port numbers unreliable since negotiated by RTSP – Overview (done) " – Identified about 90% of flows – Aggregate – Users – Flows • Simulation • Future Work • Conclusions Audio Flow Interarrivals Flow Duration Half longer than About 10 seconds 45 minutes; way between requests, longer than Web less than 1 minute or FTP max 10% over 2 hours Audio Flow Round Trip Time (TCP) Surprisingly Audio Flow Data Rates Many non-standard rates - Don’t know how to do for UDP - Median is 750ms 20k is minimal Mostly Stereo over talk modem radio 8k is typical voice 3
Audio Flow Packet Sizes (UDP) Audio Flow Packet Sizes (TCP) - 293 and 495 - 250, 300, 500 bytes - Less regularity - Can use as heuristic than UDP to identify RealAudio - Larger sent after 5 smaller packets Packet Interdeparture Outline • Introduction (done) • Methodology (done) - Ideal rate base • Results mean= median - Here, median lower – Overview (done) - Clustering in multiples – Aggregate (done) of 1.8 seconds " – Users – Flows • Simulation • Future Work • Conclusions Sequential Flows per User Aggregate Users • Users can have more than one flow – Probably a - Only 10% had more than 1 proxy • Not significant - Typically, same selection twice 4
User Arrivals User Duration - Similar to Web -Like flow duration - Like flow arrivals -Trace 5 best since terminated fewer Packet Departure for Individual Flows Outline • Introduction (done) • Methodology (done) • Results – Overview (done) – Aggregate (done) – Users (done) • Given packet sent times: t 0 , t 1 , t 2 " – Flows • Compute δ 1 = t 1 – t 0 , δ 2 = t 2 - t 1 • Simulation • Graph ( δ 1 , δ 2 ) • Future Work • Conclusions Packet Interdeparture CDF – Flow A Packet Interdeparture – Flow A - Most short Even would be along axis Cluster at 1.8 - 20% spaced 1.8+ seconds Bunch at 30ms 5
Packet Departure Zoom – Flow A Packet Interdeparture – Flow B -“On” for 6 packets -“Off” for 1.8 seconds Packet Interdeparture CDF – Flow B Outline • Introduction (done) • Methodology (done) • Results (done) -Flatter than for A • Simulation -“Steps” are in multiples " of 1.8 • Future Work • Conclusions Simulation of Audio Flows Future Work • Place server in network. Assume busy or not • Data sources based on time of day. – Other kinds: individual songs, conferencing … • Pick RTT from CDF (Figure 5 in paper) – Packet traces closer to client • Pick audio flow duration (Figure 4) • Audio congestion control • Pack audio data rate (Figure 6) – For UDP flows (next topic in class) • Multimedia flow identification – Select appropriate packet length • Send data at appropriate rate (Figure 14) – Source-Dest or Packet Length or Port … – On/Off process 6
Conclusions • Measured RealAudio flows to better understand • Different than FTP, HTTP or Telnet • Audio longer duration • 60-70% use UDP • Regular packet length, bit rates and interarrival times • CBR over long time scales, but not short ones • Overall, MM is growing and it does not look like typical traffic 7
Recommend
More recommend
