CS 356: Computer Network Architectures Lecture 24: IP Multicast and - - PowerPoint PPT Presentation

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
• r 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 eth1

• Multicast distribution trees: multiple outgoing

interfaces for a multicast destination address

eth0 eth1

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

• 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

• ne
• Packets do not loop back

– Why?

S

Problems with RPF

• Problems

– multiple routers on a LAN à receiving multiple copies of packets – Not all hosts are in the multicast group. Broadcast is a waste

S R1 R2

Designated router election

• 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

R1 R2

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

R1 R2 G Prune

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

• (a): R4 joins the multicast

group

• (b): R5 joins the group

– The Join message travels to R2

(*, G), if (S,G)

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 source- specific Join messages – Trees may no longer involve RP

PIM-SM

• R1 is the source

(s,G), if

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

41

End System Multicast

MIT1 MIT2 CMU1 CMU2

UCSD MIT1 MIT2 CMU2 Overlay Tree

Berkeley

CMU1

CMU Berkeley MIT UCSD

Internet Quality of Service

48

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

49

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

50

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

51

Utility Curve Shapes

• Stay to the right and you

are fine for all curves

BW U Elastic BW U Hard real-time BW U Delay-adaptive

52

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

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

55

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

57

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

Design question 2: How to maximize V = å U(si)

• Choice #1: add more pipes
• Choice #2: fix the bandwidth but offer

different services

– Q: can differentiated services improve V?

59

If all users’ utility functions are elastic

• å si = B
• Max å U(si)

Bandwidth U

Does equal allocation of bandwidth maximize total utility?

Elastic

60

Design question: is Admission Control needed?

• If U(bandwidth) is concave

à elastic applications

– Incremental utility is decreasing with increasing bandwidth

• U(x) = log(xp)
• V = nlog(B/n) p= logBpn1-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 BW U Elastic

61

Utility Curves – Inelastic traffic

BW U Hard real-time BW U Delay-adaptive

Does equal allocation of bandwidth maximize total utility?

62

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 BW U Delay-adaptive

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?

66

Approaches to QoS

• Fine-grained:

– Integrated services

• RSVP
• Coarse-grained:

– Differentiated services

DiffServ

95

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

96

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

DiffServ Architecture Example

AT&T

UNC

Duke

Shaping, policing, marking Per-hop behavior

98

Per-hop Behaviors (PHBs)

• Define behavior of individual routers rather than end-

to-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)

99

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

100

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

101

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 “in- profile” or low drop precedence – Other packets are marked with one of two higher drop precedence values – Random Early Detection in/out queues

DiffServ Architecture Example

AT&T

UNC

Duke

Shaping, policing, marking Per-hop behavior Edge Core

103

Edge Router Input Functionality

Packet classifier Traffic Conditioner 1 Traffic Conditioner N Forwarding engine

Arriving packet

Best effort

Flow 1 Flow N

Classify packets based on packet header

104

Traffic Conditioning

Wait for token

Set EF bit

Packet input Packet

• utput

Test if token

Set AF “in” bit

token No token

Packet input Packet

• utput

Drop on overflow

Router Output Processing

• Two queues: EF packets on higher priority queue
• Lower priority queue implements RED “In or

Out” scheme (RIO)

105

What DSCP? If “in” set incr in_cnt High-priority Q Low-priority Q If “in” set decr in_cnt RIO queue management

Packets out EF AF

Router Output Processing

• Two queues: EF packets on higher priority queue
• Lower priority queue implements RED “In or

Out” scheme (RIO)

106

What DSCP? If “in” set incr in_cnt High-priority Q Low-priority Q If “in” set decr in_cnt RIO queue management

Packets out EF AF

107

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 Minthresh, 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

108

RIO Drop Probabilities

109

Pre-marking and traffic conditioning

first hop router internal router edge router CEO edge router

ISP Company A

Unmarked packet flow Packets in premium flows have bit set Premium packet flow restricted to R bytes/sec Policing

110

Edge Router Policing

Arriving packet

Is packet marked? Token available? Token available? Clear “in” bit Drop packet

Forwarding engine AF “in” set EF set

Not marked no no

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