FASTWEB: experiences on Video over IP

FASTWEB:experiences on Video over IP Andrea Lasagna 27 Maggio 2008 PFI Pisa

Agenda • Fastweb IPTV architecture • Protocols and network problems • Video quality of experience • Closing and summary

… it’s a PVR … it’s a PC … it’s a Gaming Console … it’s a programme guide … it’s satellite TV with no dish! … it’s a videoteque … it’s a FAX …it’s FastwebTV! … it’s voice mail … it’s DTT … it’s Home Cinema Service Innovation: FastwebTV FastwebTV, a new way of watching TV

IPTV building blocks

25.000 km Fastweb Network in figures • 4 billion euros invested since 1999 • 50% population directly covered • 180 local areas • 10.000.000 home passed • 1000 Local Switches with LLU • 25.000 km network

IP Core Network Service-Agnostic Access & Core Technologies Core Network Services Access Network Home / Office FTTH Data, Voice and Video xDSL ULL / WS WI-MAX ? GSM / UMTS agnostic towards... These advantages allow: • Easy creation of new services with guaranteed QoS • Simplified operations • Strong competitive edge FASTWEB infrastructure: • Fully IP  easy addition of new access technologies • Fully owned  total freedom in driving evolution

Medium Enterprise Family FTTx Access Metropolitan PoP Central Office Family xDSL Access Medium Enterprise Family Interconnection at local level Large Business Access Bank Headquarter TI Network OLO Network FASTWEB Network Topology National IPNetwork Access Metropolitan Network Long Distance PoP

BG B/Bone PD B B VR G G B/Bone N N O O MI MI P P TO TO P P C C R R R R A A M M RE RE E E BO BO L L O O F F O O GE GE FI GR GR Access Access RM RM BA BA NA NA Customer CPE Customer CPE Best Effort Data Hi Voice Video QoS enforcement: end-to-end requirement • In a packet network, different traffic components compete for shared communication resources • Each communication trunk and network element contributes to determine the overall quality level of services offered to the Customer base • QoS enforcement policies must be implemented in both the Backbone and Access Layers

BG B/Bone PD B B VR G G B/Bone N N O O MI MI P P TO TO P P C C R R R R A A M M RE RE E E BO BO L L O O F F O O GE GE FI GR GR Access Access RM RM BA BA NA NA Customer CPE Customer CPE Best Effort Data Hi Voice Video QoS enforcement: end-to-end requirement • Traffic Classification at the Edge (source) • Traffic Marking • IP (TOS Byte) • Ethernet (Tag Control Info) • MPLS (EXP Bits) • ATM (CLP Bit, ATM Class) • Forwarding classes Identification • Traffic Matching • Per Hop Behavior Enforcement • Congestion Avoidance/Congestion Management • Marking mantenance, extension, modification

Video over IP services • Based onto multiple video distribution policies • Video on Demand Services (Unicast) • Broadcast Video Services (Multicast) • VoD andBroadcast Video Services based onto MPEG2 over IP streams (H.264 for HD video) • Each stream requires 4 Mbps on average for SD video • Service elements • Video Servers • Registration and validation of Customer accesses and service requests • Video Pumps • Providing video streams towards client stations • Video Station • Client device with extended service access and stream management capabilities

Multicast Forwarding trees – TV Channels Broadcast TV & VoD distribution Unicast Forwarding paths - VOD Video Broadcast Streamer Milan POP Central-server Overlay MAN VOD Video Pumps Back-end Servers National B-bone Turin VOD Video Pumps Central-server Overlay MAN POP National B-bone Rome Central-server Overlay Man VOD Video Pumps POP

Signaling traffic Video Traffic VoD services over FTTH Video Pumps Video Access Request Streaming Farm Video Server Video Server • Registration and validation of the Client station (STB) • Streams activation towards client stations Video Pumps • distribute the video flows Video Station • Set Top Box that allows customers to play video contents Video Output PoP PoP Fastweb MiniPoP Fastweb MiniPoP Residential Customers Residential Customers

Video Access Request VOD Content VoD services over DSL Video Pumps Streaming Farm Video Server PoP Residential Customers

Architecture of Broadcast TV services Multicast Channels • Video MPEG2 coding Transport/Program up to 4Mbps • Around 120 Television Channels ‘broadcasted’ in the network • Video quality with standard resolution PAL 720x576 @25 frame/sec • Up to 400 Mbps simultaneous Multicast Traffic per network link(Backbone & Access) • Contents distributionfrom the central-server (Milan) towards all other MAN over the national backbone

Broadcast TV over FTTH Streaming Farm Video Pumps Video Server Video Server • Registration and validation of the Client station (STB) • Streams activation towards client stations Video Pumps • distribute the video flows Video Station • Set Top Box that allows customers to play video contents Video Output PoP PoP Fastweb MiniPoP Fastweb MiniPoP Residential Customers Residential Customers

Multicast Channells Video Access Request Multicast Channells Broadcast TV over DSL Video Pumps Streaming Farm Video Server PoP Residential Customers

Design Multicast requirements • Total number of multicast sources; • Total number of multicast groups; • Dislocation/distribution of multicast sources (sites); • Overall multicast bandwitdh requirement; • Maximum bandwidth per multicast group (and packet size); • Multicast group type of service (Video or transactional); • Multicast services paradigm: • a) “One to Many” (sources distributed in few sites); • b) “Many to Many” (sources and receivers in all multicast sites) • c) “Some to Many” (different groups of sources and receivers in all multicast sites);

FW IP Multicast building blocks • IGMP(v2) • Manages receivers multicast group (channel) request in the receiver LAN (broadcast domain) • Interface the IP L3 multicast protocol to forward the requested multicast group in the receiver LAN • PIM-SM • IP Multicast protocol: builds the distribution trees from the multicast sources to the receivers that have asked for a multicast group • The most used, robust and scalable multicast protocol deployed over operators network • MSDP • IP multicast protocol used to ‘find’ and exchange multicast source information in the network • SSM • IP multicast protocol, actually a subset of PIM-SSM, simpler, usable if multicast source IP addresses are well known and managed • Anycast • Technique to guarantee redundancy layering on a IP routing protocol

Multicast forwarding • Forget unicast forwarding: IP Destination Address, Routing table. When forwarding unicast, the output interface is selected only matching the incoming packet IP DA in the Routing table where one (and one only) output interface is specified. • Multicast routing is first concerned about where the packet is coming from (RPF Check) in order to build and maintain check the multicast tree. • RPF Check: • The routing table used for multicasting is checked against the “source” IP address in the packet. • If the datagram arrived on the interface specified in the routing table for the source address; then the RPF check succeeds. • Otherwise, the RPF Check fails

IGMP IGMP (v2) Very simple protocol: • Receivers: Join and Leave a multicast group: IPTV Leave Ch1, Join Ch11 • Querier: Maintain the state of the requested channel in broadcast domain (LAN or VLAN) to cooperate with the L3 multicast protocol and ask for sources down to the LAN • General Queries (which multicast groups are requested in this LAN?) • Group Specific Queries • Can be tuned to optimize perfomance (time-outs, robustness variable, number of queries before expiring a multicast group, etc)

PIM-SM need for a Rendezvous Point Receiver: I ask for channel1 (multicast group 224.X.X.X)….. IP Router:…. where is the source for group 224.X.X.X? Source: I am source 224.Y.Y.Y, deliver me towards who’s asking for me…. IP Router….where are the receivers? → A mechanism is needed to make sources and receivers meet… A Rendezvous Point! In PIM-SM sources and receivers ‘meet’ at the Rendezvous Point In PIM SM deployment one or more routers have to provide RP functionalities Every router in the PIM-SM domain must know the RP!

PIM-SM ‘Pull-mode’ protocol Multicast trees are built from receivers up to source exploiting the Rendezvous Point • Shared trees (From Receivers to RP) • Source trees (From RP to sources) • Shortest path trees (From Receivers to sources) Switch over: when a receiver receives the first multicast packet from the RP through the Shared tree, it can directly build and use the SPT (Action done by the first IP PIM router) RPF Check: towards RP for shared trees, towards sources for SPT and Source trees When everything is put together, traffic flows through Shortest Path Trees. SPT connects the closest router to the receiver to closest router to the source Each node (router) in the tree will have a: (S,G) state associated to a list of output interfaces.

Multicast in the access • Ethernet boxes and IP Dslam are well designed for multicast delivery and qos. BNG as well ATM equipment is not… ATM DSLAM with IGMP Proxy and BNG with Multicast (oif mapping) ATM switch with Multicast enabled (IGMP Proxy)

IPTV QoE Engineering approach • QoE Top Down approach: • Characterize the high level metrics (Experience, user perspective), to define low level requirements (ie application, coding, network and transport) • Goal: To guarantee an IPTV flow in respect of the IPTV service requirements from the Source to the end user STB Source: DSL-FORUM TR 126

Transport, Voice, and Core Content & Video Headend Access Infrastructure In-Home VOD / Middleware Voice Services Content Management Local Content Digital Content Internet System end-to-end view This is where quality counts! Define end-to-end network performance requirements to achieve target QoE Need a complete end-to-end view and user needs to ensure network architecture and service success Courtesy of: Nortel, Tim Rahrer

QoE and IP network requirements • A subset of user experience requirements for SD IPTV: • Same video quality as the user is normally used to through other means of distribution (Satellite, terrestrial, cable) • High availability and continuity of the service • Very low visible impairment (error) rate – how low? • Current standards and guidelines converge to a target of one visible impairment per hour • Channel Change time comparable to what the user is used to

Network and IP transport layers • Minimum IP end-to-end bandwidth available for IPTV • End-to-end IP Transport performance objectives for: • Packet Loss • Delay • Delay variation • IP QoS support to handle congestion

Based on field experience TV users may not complain or open a ticket for each error they notice… but they always compare what they get through IP/DSL with traditional broadcasting service, and based on this may decide whether to subscribe or confirm subscription: • Input in the network good enough quality video • Preserve it throughout all the IP delivery chain

IP Transport performance objectivesPacket Loss • IPTV service is highly sensitive to packet loss • Although the impact of a single packet loss depends of several factors such as: • Compression algorithm (MPEG2, H.264, etc.) • GOP Structure • Type of information lost (I,P,B frame, other MPEG information, etc) • Codec performance (encoding and decoding) • Complexity of the video content • Error concealment at the STB • It is highly likely that a single IP packet loss produce a visible impairment to the user – Note that a single IP packet usually transports 7 188 Byte MPEG packets • Packet loss has to be minimized and strictly controlled: • Simple metrics as average Packet Loss Ratio are not enough to describe the packet loss requirement •  what matters is the loss event, its rate (MTBE) and shape (loss period and distance), not only the ratio lost_packets/received_packets.

IPTV IP Transport performance objectivesDelay • The delay introduced by a well performing IP network (say up to hundreds of milliseconds for a huge geographical network) is usually negligible for the IPTV service considering that: • Most of the delay from the live content will be added from the Head-end and video acquisition/coding/transcoding chain • Current satellite broadcast TV service already may insert a delay up to a few seconds • Delay in Channel Change time due to network transfer delay signalling processing (IGMP Leave/Join signalling and first packet reception of the requested channel for multicast service) is negligible (up to few tenths of milliseconds) when compared to the time needed to the STB to buffer enough video content for a smooth start for the play out .This time is usually comparable to a GOP interval which for 4 Mbps MPEG2 video streams is about half a second

IP Transport performance objectivesChannel change - Delay variation • Delay Variation: • Because of the presence of a quite large play-out/de-jitter buffer at the receiving side (STB), all potential jitter introduced by a well performing IP network is removed for a smooth play-out and virtually no packets is lost due to late arrival.

Internet Video challenges • Video over internet is a big challenge • The growing range of video services available over the Internet is already subject to congestion and contention issues • Which type of service? Guaranteed or Best effort • Do contents arrive from the content provider only or also from the consumers? • Do we need Reliability ? Replication or ACK-based mechanisms ? • Do we need QoS? • Rate Adaption codec?

Summary • Fastweb has the experience of several years of Video services over IP • Multicast networking • QoS and QoE measurements and reporting • We are ready to multicast with everyone

SWISSCOM Internet pim-sm E-MBGP E-MBGP pim-sm pim-sm E-MBGP Ir005 Ir003 Ir001 pim-sm I-MBGP pim-sm I-MGBP pim-sm pim-sm MSDP I-MBGP pim-sm pim-sm RR Ih002 Ih001 I-MGBP IM pim-sm pim-sm interface loopback239 description MSDP/RP ip address 81.208.50.50/32 MSDP / RP pim-sm pim-sm pim-sm pim-sm Nr002 Nr001

contact: Andrea.Lasagna@fastweb.it

FASTWEB: experiences on Video over IP