CS 356: Computer Network Architectures

Lecture 24: IP Multicast and QoS[PD] Chapter 4.2, 6.5

Xiaowei Yangxwy@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 routing224.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 one

• 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 MulticastMIT1

MIT2

CMU1

CMU2

UCSD

MIT1

MIT2

CMU2

Overlay Tree

Berkeley

CMU1

CMU

BerkeleyMIT

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 youare 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 loss54

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 VariationsReally only two classes of applications

1) Intolerant and rigid2) Tolerant and adaptive

Other combinations make little sense3) Intolerant and adaptive

- Cannot adapt without interruption4) 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

DukeShaping, 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&TUNC

DukeShaping, policing, marking

Per-hop behavior

Edge Core

103

Edge Router Input Functionality

Packetclassifier

TrafficConditioner 1

TrafficConditioner N

Forwardingengine

Arrivingpacket

Best effort

Flow

1Flo

w N

Classify packets based on packet header

104

Traffic Conditioning

Wait fortoken

Set EF bitPacketinput

Packetoutput

Test iftoken

Set AF “in” bit

token

No token

Packetinput

Packetoutput

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” setincr in_cnt

High-priority Q

Low-priority Q

If “in” setdecr in_cnt

RIO queuemanagement

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” setincr in_cnt

High-priority Q

Low-priority Q

If “in” setdecr in_cnt

RIO queuemanagement

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 hoprouter

internalrouter

edgerouter

CEO

edgerouter

ISP

Company A

Unmarkedpacket flow

Packets in premiumflows have bit set

Premium packet flowrestricted to R bytes/sec

Policing

110

Edge Router Policing

Arrivingpacket

Is packetmarked?

Tokenavailable?

Tokenavailable?

Clear “in” bit

Drop packet

Forwardingengine

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