588 Section 5

25
588 Section 5 Neil Spring May 4, 1999

description

588 Section 5. Neil Spring May 4, 1999. Schedule. Notes (1 slide) Homework 2 (9 slides) Multicast (11 slides). Notes. Graded Homework Assignment 1 Should have received it this afternoon Generally applicable questions?? Homework 2 due Monday, May 10 - PowerPoint PPT Presentation

Transcript of 588 Section 5

Page 1: 588 Section 5

588 Section 5

Neil Spring

May 4, 1999

Page 2: 588 Section 5

Schedule

• Notes – (1 slide)

• Homework 2 – (9 slides)

• Multicast – (11 slides)

Page 3: 588 Section 5

Notes

• Graded Homework Assignment 1– Should have received it this afternoon– Generally applicable questions??

• Homework 2 due Monday, May 10

• Programming Assignment 2 due May 24

• Final Project too!

Page 4: 588 Section 5

Homework 2

• Dealing with images (1 slide)

• Next few slides: each problem in a little detail

• Make sure you know what we’re asking for

• Give you the opportunity to ask questions on each problem individually

Page 5: 588 Section 5

Homework 2: Problem 1c & 4• Image formats: EPS, PNG, GIF.

• Put your name on em, filename too.

• Visio should work well.

• Text descriptions ok too– topology = (A,B)(B,C)– timing = a -> b, wait t sec.

• OR, printed and mailed to: Neil SpringBox 352350University of WashingtonSeattle, WA 98195-2350

Page 6: 588 Section 5

Homework 2: Problem 1

• Little extra detail because it comes up in – the multicast paper– your second programming assignment

• Routing Schemes– Link State– Distance Vector– Path-based distance vector

• Goal is to decide where to forward a packet

Page 7: 588 Section 5

Problem 1: Link State

• Each router sends out an LSP describing what other routers it’s connected to

• Other routers can overlay LSPs to discover the complete map

• Challenges for link-state: – scalably distributing LSPs (reliable flooding)– scalably processing LSPs

• OSPF has additional features– load balancing

Page 8: 588 Section 5

Problem 1: Distance Vector

• Each router sends a vector of distances to each destination

• Dynamic programming sort of solution:– I can reach my neighbor’s destinations in 1 extra hop

(or better)

• Split horizon improvement– Don’t advertise routes back where they came from

• Challenges for distance vector:– instability after link failure

Page 9: 588 Section 5

Path-based Distance Vector

• Think BGP (1991)• List the (transit) AS’s packets would travel through

– AS’s are stub, multihomed, or transit– Represented by a 16-bit number

• Should avoid loops • BGP

– supports policy based routing– focuses on getting there loop free

Page 10: 588 Section 5

Homework 2: Problem 2

• CIDR: Classless InterDomain Routing

• Classless– no “B”, “C”– just variable length prefixes

• Each internal node has degree 3.

• Pretty simple question

Page 11: 588 Section 5

Homework 2: Problem 3

• Stack of routers to visit along the path• Each router can push a new (more explicit) route on

to the stack to get to the next hop• Is this better?

– Stable?– Faster?– Less error prone?– Possible to implement?

• Justify your assertion!!!

Page 12: 588 Section 5

Homework 2: Problem 4

• Using tcpdump as a tool is fine– My slides from Week 4 might be helpful. Note that

the timer isn’t correct.

• Presenting tcpdump output alone is not fine.• Note that 20 data packets must be sent: yes, all 20

should be in the diagram• Just a count of round trips in the third data packet

drop part (with a little explanation) is fine

Page 13: 588 Section 5

Homework 2: Problem 5

• BW = MSS *C / ( RTT * sqrt(p))

• Periodic packet loss important.

Page 14: 588 Section 5

Multicast

• Multicast Routing in Datagram Internetworks and Extended LANs

• What to multicast?– Stuff you know some set of machines care about

• updates to shared state

• conferencing

– Stuff you don’t know who cares about• Service location

Page 15: 588 Section 5

Why multicast?

• “Minimal” resources demands:– don’t have to unicast to everyone– don’t have to broadcast to those who don’t care

• Broadcast– can’t be filtered in hardware, – generally doesn’t make it very far into the network

• Senders and receivers can come and go; the network figures out how to move bits.

Page 16: 588 Section 5

Groups

• Open: non-members can send to the group

• Closed: can’t

• Pervasive: there are members everywhere

• Sparse: low member to non-member ratio

• Local: few links

Page 17: 588 Section 5

Refinement: Scope control

• Maybe want to try close destinations first.

• Avoids excessive responses

• Using TTL.

• If you know the only recipients you care about are close, don’t bother the Internet– File / Print Services– Parallel Computation

Page 18: 588 Section 5

Single Spanning Tree

• Compute one spanning tree for all multicast

• Listen to see which attached segments care about that multicast

• When a packet arrives on an incident edge, and the other edge cares, forward.

• Have to maintain state about who cares.

• Not transparent (hosts have to keep caring)

Page 19: 588 Section 5

Distance Vector Multicast

• Reverse Path – Flooding– Broadcasting– Truncated– Multicasting

• “there is potentially a different shortest-path tree from every sender to every multicast group”

Page 20: 588 Section 5

Reverse Path Flooding

• Find a good tree

• Described in the RPB section of the book.

• Reverse-path– We know how to get from a source to a

destination, so we presume a packet would come back the same way.

• Flooding– Forward those packets over all outgoing links

Page 21: 588 Section 5

Reverse Path Broadcasting

• Avoid duplicates by electing a – router as the ‘parent’ of a – ‘child’ LAN

• Only the elected parent can send the packet on the lan

• Typically the closest, using address to break ties.

Page 22: 588 Section 5

Truncated RPB

• Routers on child links tell parents– the lan is not a leaf– somebody downstream would care

• Can prune uninterested leaves

• Single spanning tree already had this

Page 23: 588 Section 5

Reverse Path Multicasting

• Don’t waste resources pruning unused multicast trees

• Prune on demand: – Non-membership report (NMR)

Page 24: 588 Section 5

Link State instead?

• We’ve got a map of the network, and a new multicast packet shows up from a new source

• Dijkstra’s on demand

• Cache the result

• Might take a while to get the first packet through

Page 25: 588 Section 5

Issues in multicasting

• Differences in receiver bandwidth

• Reliability– retransmission– redundant transmission

• Ordering/consistency of multiple senders