CS 356: Computer Network Architectures Lecture 24: IP Multicast and QoS [PD] Chapter 4.2, 6.5 Xiaowei Yang xwy@cs.duke.edu
Overview Two historic important topics in networking Multicast QoS Limited Deployment
IP Multicast
What is Multicast Many-to-many communications Applications Internet radio Video conferencing News dissemination
Communication models Unicast One-to-one Unicast routing Multicast Anycast Broadcast
Design questions How does a sender know who is interested in the packet? Each sender maintains the group membership? How to send a packet to each receiver?
Multicast Architecture Nodes interested in many-to-many communications form a multicast group Each group is assigned a multicast address Routers establish forwarding state to multicast addresses Members of a multicast group receive packets sent to the group s multicast address
Group Management Routers maintain which outgoing links connect to multicast group members A host signals to its local router its desire to join or leave a group Internet Group Management protocol (IPv4) Multicast Listener Discovery (IPv6)
Multicast Addresses IPv4: 224.0.0.0/4 (28 bits) IPv6: 1111 1111 / 8 Mapping an IP multicast address to an Ethernet multicast address 01-00-5E-00-00-00 to 01-00-5E-7F-FF-FF Internet Multicast [RFC1112] Map the lower-order 23-bit IP address to Ethernet multicast address IPv6 has a similar mapping scheme
Router forwarding algorithm if IP-destination is on the same local network or IP-destination is a host group, send datagram locally to IP-destination else send datagram locally to NextHop ( IP-destination )
Receiving a Multicast Packet Host configures the network adaptor to listen to the multicast group Examine the IP multicast address, and discard packets from non-interested groups
Types of multicast Any source multicast Many-to-many A receiver does not specify a sender Source specific multicast A receiver specifies both the group and the sender TV, radio channels
Design questions How does a sender know who is interested in the packet? Sends to a multicast group Receivers join the group Routers maintain the group membership How to send a packet to each receiver? Unicast? Flooding?
Multicast routing 224.16.0.10 eth0 eth0 eth1 eth1 Multicast distribution trees: multiple outgoing interfaces for a multicast destination address
Distance Vector Multicast Routing Protocol Using existing distance vector routing protocol Establish multicast forwarding state Flood to all destinations (reverse path flooding) Key design challenge: loop-avoidance Q: how many broadcast loop-avoidance mechanisms have we learned? Prune those not in the group
Reverse path flooding S Reverse shortest-path flooding If packet comes from link L, and next hop to S is L, broadcast to all outgoing links except the incoming one Packets do not loop back Why?
Problems with RPF S R1 R2 Problems multiple routers on a LAN à receiving multiple copies of packets Not all hosts are in the multicast group. Broadcast is a waste
Designated router election R1 R2 Address the duplicate broadcast packet problem Routers on the same LAN elect a parent that has the shortest distance to S Parent is one with the shortest path Routers can learn this from DV routing messages If tie, elect one with the smallest router ID
Truncated reverse path flooding Start with a full broadcast tree to all links (RPB) Prune unnecessary links Hosts interested in G periodically announce membership If a leaf network does not have any member, sends a prune message to parent Augment distance vector to propagate groups interested to other routers Only do so when S starts to multicast This prune message can be propagated from router to router to prune non-interested branches
A pruning example Prune R1 R2 G
Protocol Independent Multicast (PIM) Problem with DVMRP Broadcast is inefficient if few nodes are interested Most routers must explicitly send prune messages Dependent on routing protocols Solution Dense mode: flood & prune similar to DVMRP Sparse mode: send join messages to rendezvous point (RP) Not dependent on any unicast routing protocol, unlike DVMRP
PIM-SM 1. Routers explicitly join a shared distribution tree Unlike DVMRP which starts from a broadcast tree 2. Source-specific trees are created later for more efficient distribution if there is sufficient traffic
PIM-SM (*, G), if (S,G) (a): R4 joins the multicast group (b): R5 joins the group The Join message travels to R2
Join PIM-SM assigns each group a special router known as the rendezvous point (RP) A router that has hosts interested in G sends a Join message to RP A router looks at the join message and create a multicast routing entry (*,G) pointing to the incoming interface. This is called an all sender forwarding entry It propagates join to previous hop closer to RP
Forwarding along a shared tree If a source S wishes to send to the group S sends a packet to its designated router (R1) with the multicast group as the destination address R1 encapsulates the packet into a PIM register message, unicast it to RP PR decapsulates it and forwards to the shared trees
Source specific tree Problems Encapsulation is inefficient Solution: RP sends Join message to source S R3 now knows the group (S,G)
Source specific tree Problem: shared trees are inefficient as paths could be longer than shortest path Solution If s sends at high rates, routers send sourcespecific Join messages Trees may no longer involve RP
PIM-SM (s,g), if R1 is the source
PIM: final remarks Unicast independent Assuming a unicast routing protocol has established correct forwarding state Scalability challenges Per (S,G) forwarding state!
Remarks on IP multicast Many design choices Facing many challenges: used to be a very active resource topic Economic model s not clear: who pays for the service? Reliability Scalability Heterogeneity
End System Multicast Berkeley MIT MIT1 UCSD MIT2 CMU1 CMU Berkeley UCSD Overlay Tree MIT1 MIT2 CMU2 CMU1 CMU2 41
Internet Quality of Service
Motivation Internet currently provides one single class of best-effort service No assurance about delivery Many existing applications are elastic Tolerate delays and losses Can adapt to congestion Real-time applications may be inelastic 48
Inelastic Applications Continuous media applications Lower and upper limit on acceptable performance Below which video and audio are not intelligible Internet telephones, teleconferencing with high delay (200-300ms) impair human interactions Hard real-time applications Require hard limits on performance E.g., industrial control applications Internet surgery 49
Design question #1: Why a New Service Model? What is the basic objective of network design? Maximize total bandwidth? Minimize latency? Maximize ISP s revenues? the designer s choice: Maximize social welfare: the total utility given to users (why not profit?) What does utility vs. bandwidth look like? Must be non-decreasing function Shape depends on application 50
Utility Curve Shapes U Elastic U Hard real-time BW BW U Delay-adaptive Stay to the right and you are fine for all curves BW 51
Playback Applications Sample signal à packetize à transmit à buffer à playback Fits most multimedia applications Performance concern: Jitter: variation in end-to-end delay Delay = fixed + variable = (propagation + packetization) + queuing Solution: Playback point delay introduced by buffer to hide network jitter 52
Characteristics of Playback Applications In general lower delay is preferable Doesn t matter when packet arrives as long as it is before playback point Network guarantees (e.g., bound on jitter) would make it easier to set playback point Applications can tolerate some loss 54
Applications Variations Rigid and adaptive applications Delay adaptive Rigid: set fixed playback point Adaptive: adapt playback point E.g. Shortening silence for voice applications Rate adaptive Loss tolerant and intolerant applications Four combinations 55
Applications Variations Really only two classes of applications 1) Intolerant and rigid 2) Tolerant and adaptive Other combinations make little sense 3) Intolerant and adaptive - Cannot adapt without interruption 4) Tolerant and rigid - Missed opportunity to improve delay 57
Design question 2: How to maximize V = å U(s i ) Choice #1: add more pipes Choice #2: fix the bandwidth but offer different services Q: can differentiated services improve V?
If all users utility functions are elastic U Elastic Does equal allocation of bandwidth maximize total utility? å s i = B Bandwidth Max å U(s i ) 59
Design question: is Admission Control needed? If U(bandwidth) is concave à elastic applications Incremental utility is decreasing with increasing bandwidth U(x) = log(x p) V = nlog(b/n) p = logb p n 1-p Is always advantageous to have more flows with lower bandwidth No need of admission control; This is why the Internet works! And fairness makes sense U Elastic BW 60
Utility Curves Inelastic traffic U Delay-adaptive U Hard real-time BW BW Does equal allocation of bandwidth maximize total utility? 61
Is Admission Control needed? If U is convex à inelastic applications U(number of flows) is no longer monotonically increasing Need admission control to maximize total utility Admission control à deciding when the addition of new people would result in reduction of utility Basically avoids overload U Delay-adaptive BW 62
Incentives Who should be given what service? Users have incentives to cheat Pricing seems to be a reasonable choice But usage-based charging may not be well received by users
Over provisioning Pros: simple Cons Not cost effective Bursty traffic leads to a high peak/average ratio E.g., normal users versus leading edge users It might be easier to block heavy users
Comments End-to-end QoS has not happened Why? Can you think of any mechanism to make it happen?
Approaches to QoS Fine-grained: Integrated services RSVP Coarse-grained: Differentiated services 66
DiffServ
Motivation of DiffServ Analogy: Airline service, first class, coach, various restrictions on coach as a function of payment Economics and assurances Pay more, and get better service Best-effort expected to make up bulk of traffic, Revenue from first class important to economic base Not motivated by real-time or maximizing social welfare 95
Basic Architecture Agreements/service provided within a domain Service Level Agreement (SLA) with ISP Edge routers do traffic conditioning Shaping, Policing, and Marking Core routers Process packets based on packet marking and defined per hop behavior (PHB) More scalable than IntServ No per flow state or signaling 96
DiffServ Architecture Example Duke Shaping, policing, marking UNC Per-hop behavior AT&T
Per-hop Behaviors (PHBs) Define behavior of individual routers rather than endto-end services; there may be many more services than behaviors No end-to-end guarantee Multiple behaviors need more than one bit in the header Six bits from IP TOS field are taken for Diffserv code points (DSCP) 98
Per-hop Behaviors (PHBs) Two PHBs defined so far Expedited forwarding aka premium service (type P) Possible service: providing a virtual wire Assured forwarding (type A) Possible service: strong assurance for traffic within profile and allow source to exceed profile 99
Expedited Forwarding PHB Goal: EF packets are forwarded with minimal delay and loss Mechanisms: User sends within profile and network commits to delivery with requested profile Rate limiting of EF packets at edges only, using token bucket to shape transmission Priority or Weighted Fair Queuing 100
Assured Forwarding PHB Goal: good services for in-profile traffic Mechanisms: User and network agree to some traffic profile How to define profiles is an open/policy issue Edges mark packets up to allowed rate as inprofile or low drop precedence Other packets are marked with one of two higher drop precedence values Random Early Detection in/out queues 101
DiffServ Architecture Example Duke Shaping, policing, marking UNC Per-hop behavior AT&T Edge Core
Edge Router Input Functionality Traffic Conditioner 1 Arriving packet Packet classifier Flow 1 Flow N Traffic Conditioner N Best effort Forwarding engine Classify packets based on packet header 103
Traffic Conditioning Drop on overflow Packet input Wait for token Set EF bit Packet output No token Packet input Test if token token Set AF in bit Packet output 104
Router Output Processing Two queues: EF packets on higher priority queue Lower priority queue implements RED In or Out scheme (RIO) What DSCP? AF EF High-priority Q Packets out If in set incr in_cnt Low-priority Q RIO queue management If in set decr in_cnt 105
Router Output Processing Two queues: EF packets on higher priority queue Lower priority queue implements RED In or Out scheme (RIO) What DSCP? AF EF High-priority Q Packets out If in set incr in_cnt Low-priority Q RIO queue management If in set decr in_cnt 106
Red with In or Out (RIO) Similar to RED, but with two separate probability curves Has two classes, In and Out (of profile) Out class has lower Min thresh, so packets are dropped from this class first Based on queue length of all packets As avg queue length increases, in packets are also dropped Based on queue length of only in packets 107
RIO Drop Probabilities 108
Pre-marking and traffic conditioning Company A Packets in premium flows have bit set CEO internal router Premium packet flow restricted to R bytes/sec ISP Unmarked first hop router edge router Policing edge router packet flow 109
Edge Router Policing AF in set Token available? no Clear in bit Arriving packet Is packet marked? Not marked Forwarding engine EF set Token available? no Drop packet 110
Remarks on QoS Dead at the Internet scale Areas of success Enterprise networks Residential uplinks Datacenter networks
Conclusion Multicast Service model Sample routing protocols QoS Why do we need it? Integrated Services Differentiated Services Motivated by business models