CS 414 - Spring 2014 CS 414 – Multimedia Systems Design Lecture 41 – P2P Streaming (Part 5)...

CS 414 - Spring 2014

CS 414 – Multimedia Systems Design

Lecture 41 – P2P Streaming (Part 5)

Klara Nahrstedt

Administrative MP3 deadline Saturday May 3, 5pm

Demonstrations of MP3, May 5, 5-7pm Groups should sign up as follows: Top four groups will be decided Monday, May 5 in

the evening (via email, also posted on the newsgroup/class website) - these groups will compete in front of the Google judges on Tuesday, May 6


Administrative (Change!) Competition of final four groups on

Tuesday 5-6:30pm in 216/218 SC Pizza and Drinks, Tuesday 6:30-7:30pm

in 4403 SC The top four groups should prepare 3 power-point

slides to present Intro Slide – name of your system and your names (1 slide) System Design – overall architecture (1 slide) Features of Your System - interface (1 slide)


Administrative Homework 2 is posted

Deadline May 7, Wednesday midnight 11:59pm Peer Evaluations – due Friday, May 9, midnight

Peer Evaluation Form and Explanation - available on the class website

Submit your Peer Evaluation to [email protected] Note: if you do not submit your peer evaluations, you get

0 for self-evaluation and 100% for your group mates. ¼ Unit projects – due Friday, May 9 midnight (if

you need more time, arrange deadline with instructor)


Final Exam

May 15, 1:30-4:30pm in 216 SCMore information on Wednesday about final

exam format/review session


Outline

Voice over IP via Telecom IP Networks

Peer-to-Peer Internet Voice Distribution


Voice over IP in Residential Areas (e.g., Microsoft Lync)


http://www.voip-info.org/liberty/view/file/4372

VoIP Issues - QoS (Low Latency Queuing) in VoIP Routers


Nahrstedt, Klara

A priority queue is required for VoIP. You can use any queueing mechanism that effectively gives VoIP high priority, but low latency queueing (LLQ) is recommended because it is flexible and easy to configure.The most flexible queueing method that satisfies VoIP requirements is LLQ. LLQ uses the MQC configuration method to provide priority to certain classes and to provide guaranteed minimum bandwidth for other classes. During periods of congestion, the priority queue is policed at the configured rate so that the priority traffic does not monopolize all the available bandwidth. (If the priority traffic monopolizes the bandwidth, it prevents bandwidth guarantees for other classes from being met.) If you provision LLQ correctly, the traffic going into the priority queue should never exceed the configured rate.LLQ also allows queue depths to be specified to determine when the router should drop packets if too many packets are waiting in any particular class queue. There is also a class default that is used to determine treatment of all traffic not classified by a configured class. The class default can be configured with the fair-queue interface configuration command, which means that each unclassified flow will be given an approximately equal share of the remaining bandwidth. Figure 1 shows how LLQ works.

VoIP Issues - Fragmentation and Interleaving in VoIP


http://www.cisco.com/c/en/us/td/docs/ios/solutions_docs/qos_solutions/QoSVoIP/QoSVoIP.html#wp1034022

Nahrstedt, Klara

Nahrstedt, Klara

Even if queueing is working at its best and prioritizing voice traffic, there are times when the priority queue is empty and a packet from another class is serviced. Packets from guaranteed bandwidth classes must be serviced according to their configured weight. If a priority voice packet arrives in the output queue while these packets are being serviced, the VoIP packet could wait a substantial amount of time before being sent. If we assume that a VoIP packet will need to wait behind one data packet, and that the data packet can be, at most, equal in size to the MTU (1500 bytes for serial and 4470 bytes for high-speed serial interfaces), we can calculate the wait time based on link speed.For example, for a link speed of 64 kbps and MTU size of 1500 bytes, we have: Serialization delay = (1500 bytes * 8 bits/byte) / (64,000 bits/sec) = 187.5 msTherefore, a VoIP packet may need to wait up to 187.5 ms before it can be sent if it gets delayed behind a single 1500-byte packet on a 64-kbps link. VoIP packets usually are sent every 20 ms. With an end-to-end delay budget of 150 ms and strict jitter requirements, a gap of more than 180 ms is unacceptable.You need a mechanism that ensures that the size of one transmission unit is less than 10 ms. Any packets that have more than 10-ms serialization delay need to be fragmented into 10-ms chunks. A 10-ms chunk or fragment is the number of bytes that can be sent over the link in 10 ms. You can calculate the size by using the link speed: Fragmentation size = (0.01 seconds * 64,000 bps) / (8 bits/byte) = 80 bytesIt takes 10 ms to send an 80-byte packet or fragment over a 64-kbps link.On low speed links where a 10-ms-sized packet is smaller than the MTU, fragmentation is required. Simple fragmentation is insufficient, though, because if the VoIP packet must wait behind all the fragments of a single large data packet, the VoIP packet still will be delayed beyond the end-to-end delay limit. The VoIP packet must be interleaved or inserted in between the data packet fragments. Figure 2 illustrates fragmentation and interleaving.

Skype

Source: An Analysis of the Skype Peer-to-peer Internet Telephony Protocol, S. Baset, H. Schulzrinne, 2004

Rapid Identification of Skype Traffic Flows, P. Branch et al. , NOSSDAV 2008


Skype Overview Peer-to-peer (P2P) overlay network for Voice-

over-IP (VoIP) and other application Developed by Niklas Zennstrom and Janus Friis

(founders of KaZaA, file-sharing company) Users see Skype as an Instant Messaging (IM)

software Free on-net VoIP service and fee-based off-net

SkypeOut service (allows calling to PSTN and mobile phones)

Runs on Windows, Linux, Pocket PC, …CS 414 - Spring 2014

Skype Network

Super Nodes: Any node with a public IP address having sufficient CPU, memory and network bandwidth is candidate to become a super node

Ordinary Host: this host needs to connect to super node and must register itself with the Skype login server


Components of Skype

Ports Skype client (SC) opens TCP and UDP listening port

configured in its connection dialog box Host Cache (HC)

List of super node IP address and port pairs that SC builds and refreshes regularly

SC stores HC in the Windows registry Codecs

Wideband coded allowing frequencies between 50Hz-8KHz (one of the codecs is implemented by Global IP Sound)


Skype Ports on which Skype listens for incoming connections


Skype Host Cache List

Components of Skype

Buddy List Skype stores buddy information in Windows registry Buddy list is digitally signed and encrypted, local to machine and

not on a central server Encryption

Skype uses 256-bit AES encryption Skype uses 1536 to 2048bit RSA to negotiate symmetric AES

keys NAT and Firewall

SC uses variations of the STUN and TURN protocols to determine type of NAT and firewall


Skype Architecture


STUN and TURN

STUN (Simple Traversal of UDP through NAT) Client-server protocol

TURN (Traversal Using Relay NAT) Increase latency and packet loss


Techniques used in Skype

Firewall and NAT traversal Global decentralized user directory Intelligent routing Security Super-simple UI


Login

During login process SC: Authenticates its user name and password with login

server Advertises its presence to other peers and its buddies Determines type of NAT and firewall it is behind Discovers online Skype nodes with public IP

addresses Login server is the only central component in

Skype network


Skype Login Algorithm


Skype Login Process

After installation and first time startup, HC was observed empty

Bootstrap super nodes: After login for the first time after installation, HC was

initialized with seven (IP,port) pairs Bootstrap (IP,port) information either

Hard coded in SC Encrypted and not directly visible in Skype Windows

registry, or One-time process to contact bootstrap node


Skype Login Process

First time Login Process SC sends UDP packets to some bootstrap SNs SC establishes TCP connection with bootstrap SNs that respond SC perhaps acquires address of login server from SNs SC establishes TCP connection with login server, exchanges

authentication information Subsequent Login Process

Similar to first-time login process SC uses login algorithm to determine at least one available peer

and establishes TCP connection HC was periodically updated with new peers’ (IP,port)


Skype Login Process Comparison of three network setups

Exp A: both Skype users with public IP address Exp B: one Skype user behind port-restricted NAT Exp C: both Skype users behind port-restricted NAT and UDP-

restricted firewall Message flows for first time login process

Exp A and Exp B are roughly the same; Exp C only exchange info over TCP


User Search

Skype uses Global Index technology to search for a user

Skype claims that search is distributed and is guaranteed to find a user if it exists and has logged in during last 72 hours

Search results are observed to be cached at intermediate nodes


Call Establishment and Teardown

Call signaling is always carried over TCP For user not present in buddy list, call placement

is equal to user search plus call signaling If caller is behind port-restricted NAT and callee

is on public IP, signaling and media flow through an online Skype node which forwards signaling to callee over TCP and routes media over UDP

If both users are behind port-restricted NAT and UDP-restricted firewall, both caller and callee SCs exchange signaling over TCP with another online Skype node, which also forwards media between caller and calllee over TCP


Media Transfer and Codec

Bandwidth usage 3-16 Kbytes/s

Skype allows peers to hold a call. To ensure UDP binding, SC sends three UDP packets

per second to the call peer on average No silence suppression is supported in Skype min. and max. audible frequencies Skype codecs

allow to pass through are 50 Hz and 8000 Hz. Uplink and downlink bandwidth of 2KB/s each is

necessary for reasonable call quality


Conferencing

Node A acts as mixer, mixing its own packets with those of node B and sending to C and vice versa

For three party conference, Skype does not do full mesh conferencing

Most powerful machine will be elected as conference host and mixer

Two-way call: 36kb/s Three-way call: 54kb/s


Impact of Skype

Impact on fixed-line operator Skype will introduce SkypIN

Impact on mobile phone operator Skype will be embedded in Wi-Fi/mobile phone WLAN is now limited by

Batter life


Impact of Skype

Skype has shown, at least has suggested, the following Signaling, the most unique property of

traditional phone systems, can now be accomplished effortlessly with self-organizing P2P networks

P2P overlay networks can scale up to handle large-scale connection-oriented real-time services such as voice


Conclusion – skype 2004 Statistics from the paper 2004 - More than 2 million on-line subscribers per

day More than 2.7 billion minutes served

(minutes of free Skype-to-Skype callees) More than 38 million of software download More than 7 million of registered

subscribers More than 1 million concurrently on-line

subscribersCS 414 - Spring 2014

Conclusion – skype 2013

http://www.telegeography.com/products/commsupdate/articles/2014/01/15/skype-traffic-continues-to-thrive/

Conclusion – skype 2014Unique Users: 41,016,000Time Spent: 0h 13mGender: - 46.3% are Male ; - 53.7% are FemaleAge

•16.5% are 18-24•37.6% are 18-34•65.8% are 18-49•21.1% are 25-34•58.5% are 25-54

Marital Status•52.8% are married•45.8% have children

Education - 33.3% have graduated college or higherIncome

•61% have a household income of $50K+•39.1% have a household income of $75K+•22.7% have a household income of $100+•16.4% have a household income of $75,000-99,999

Online Shopping•78.3% have shopped online in the past 30 days•71.8% have purchased online in the past 30 days•16.6% sought or posted product reviews in the last 30 days

Nahrstedt, Klara

http://thenextweb.com/media/2012/06/13/skype-stats-sessions-average-13-minutes-users-54-female-33-are-college-educated/

CS 414 - Spring 2014 CS 414 – Multimedia Systems Design Lecture 41 – P2P Streaming (Part 5)...

Documents

Transcript of CS 414 - Spring 2014 CS 414 – Multimedia Systems Design Lecture 41 – P2P Streaming (Part 5)...