Final Exam Review

1
Final Exam Review
2
Transport Protocol Design Review
3
TCP UDP

• Protocols implemented entirely at the ends
• UDP provides just integrity and demux
• TCP adds
• Connection-oriented
• Reliable
• Ordered
• Point-to-point
• Byte-stream
• Full duplex
• Flow and congestion control

4
Temporal Redundancy Model

• Sequence Numbers
• CRC or Checksum

Packets
Timeout

• ACKs
• NAKs,
• SACKs
• Bitmaps

Status Reports
Retransmissions

• Packets
• FEC information

5
Reliability Mechanisms

• Mechanisms
• Checksum detects corruption in pkts acks
• ACK packet correctly received
• Duplicate ACK packet incorrectly received
• Sequence number Identifies packet or ack
• 1-bit sequence number used both in forward
  reverse channel
• Timeout only at sender
• Provides reliable transmission over
• An error-free channel
• A forward reverse channel with bit-errors
• Detects duplicates of packets/acks
• NAKs eliminated
• A forward reverse channel with packet-errors
  (loss)

6
Three-Way Handshake

• TCP connection-establishment 3-way-handshake
  necessary and sufficient for unambiguous
  setup/teardown even under conditions of loss,
  duplication, and delay

7
TCP Connection Tear-down
Sender
Receiver
FIN
FIN-ACK
Data write
Data ack
FIN
FIN-ACK
8
Basic Flow Error Control

• Stop-and-Wait
• Sliding Window
• Go-Back-N
• Selective Repeat

9
Whats Different in TCP From Link Layers?

• Logical link, not a physical link
• Must establish connection
• Variable RTT
• May vary within a connection gt Timeout variable
• Reordering
• How long can packets live? gt
• Max
  Segment Lifetime (MSL)
• Cant expect endpoints to exactly match link rate
• Buffer space availability, flow control
• Transmission rate
• Dont directly know transmission rate

10
TCP Beyond the DLL

• Sequence Number Space
• Maximum Segment Size (MSS)
• Silly Window Syndrome (Clark)
• Nagels Algorithm Delayed Acks
• Estimate Adaptive Timeout via MaxRTT (Chebyshev)
• Timeout Granularity (200, 500, or 1000 ms)
• Retransmission Ambiguity - Karns RTT Estimator
• Timestamp Extension

11
Congestion Control vs. Congestion Avoidance

• Congestion Control Goal Stay left of cliff.
• Congestion Avoidance Goal Stay left of knee.
• Right of cliff Congestion collapse.

12
Congestion Control

• Two Models Of Congestion Control
• End-to-end
• Network-based
• Stability
• Equilibrium point(s)
• Fairness
• a 0 maximum throughput fairness
• a 1 proportional fairness
• a 2 minimum delay fairness
• a 8 max-min fairness

13
Max-Min Fairness

• If link not congested then
• If link congested then

f 4 min(8, 4) 4 min(6, 4) 4 min(2, 4)
2
x1
8
10
4
x2
Allocations
6
4
2
x3
2
14
Flow Control Optimization Model

• Given a set S of flows, and a set L of links
• Each flow s has utility Us(xs) ,
• xs is its sending rate
• Each link l has capacity cl
• Modeled as optimization (Kelly 98, Low 99)

where Sl s flow s passes the link l
14
15
Self-Clocking

• Implications of ack-clocking
• More batching of acks gt bursty traffic
• Less batching leads to a large fraction of
  Internet traffic being just acks (overhead)

16
Additive Increase/Multiplicative Decrease (AIMD)
Policy

• Assumption Decrease policy must (at minimum)
  reverse the load increase over-and-above
  efficiency line
• Implication Decrease factor should be
  conservatively set to account for any congestion
  detection lags etc

17
TCP Congestion Control

• Basic Protocol
• cwnd congestion window
• rcv_win receiver advertised window
• ssthresh threshold size (to update cwnd)
• For sending win min(rcv_win, cwnd)
• Slow Start
• Congestion Avoidance

18
Slow Start/Congestion Avoidance Ex.

• Assume that ssthresh 8

ssthresh
Cwnd (in segments)
Roundtrip times
19
The Big Picture
cwnd
Timeout
Congestion Avoidance
Slow Start
Time
20
Packet Loss Detection Timeout Avoidance

• Wait for Retransmission Time Out (RTO)
• Whats the problem with this?
• Because RTO is a performance killer
• In BSD TCP, RTO is usually more than 1 second
• The granularity of RTT estimate is 500 ms
• Retransmission timeout is at least two times of
  RTT.
• Solution Dont wait for RTO to expire
• Use alternate mechanism for loss detection
• Fall back to RTO only if these alternate
  mechanisms fail.

21
Fast Retransmit

• Dont wait for RTO to expire
• Resend a segment after 3 duplicate ACKs
• Recall A duplicate ACK means that an out-of
  sequence segment was received

ACK 2
cwnd 2
segment 2
segment 3
ACK 3
ACK 4
cwnd 4
segment 4
segment 5
segment 6
segment 7
ACK 4
ACK 4
3 duplicate ACKs
ACK 4
22
Fast Recovery

• After a fast-retransmit set cwnd to ssthresh/2
• i.e., dont reset cwnd to 1
• But when RTO expires still do cwnd 1
• Fast Retransmit and Fast Recovery ? implemented
  by TCP Reno most widely used version of TCP
  today

23
Fast Retransmit and Fast Recovery
cwnd
Congestion Avoidance
Slow Start
Time

• Retransmit after 3 duplicated acks
• Prevent expensive timeouts
• No need to slow start again
• At steady state, cwnd oscillates around the
  optimal window size.

24
NewReno

• The ack that arrives after a retransmission
  partial ack should indicate that a second loss
  occurred
• When does NewReno timeout?
• When there are fewer than three duplicate acks
  for first loss
• When partial ack is lost
• How fast does it recover losses?
• One per RTT

25
SACK

• Basic problem is that cumulative acks only
  provide a little information
• Alt Selective Ack for just the packet received
• What if selective acks are lost? ? Carry
  cumulative ack also!
• Implementation Bitmask of packets received
• Selective acknowledgement (SACK)
• Only provided as an optimization for
  retransmission
• Fall back to cumulative acks to guarantee
  correctness and window updates

26
Asymmetric Behavior

• Forward and reverse paths are often independent
  even when they traverse the same set of routers
• Many link types are unidirectional and are used
  in pairs to create bi-directional link (e.g.
  ADSL, cable modem)
• Congestion on the reverse path limits the
  throughput on the forward link

6Mbps
Internet (no congestion, bandwidth gt 6Mbps)
A
I
B
32kbps
27
Advanced Topics inCongestion ControlReview
28
Queuing Disciplines

• Queuing allocates bandwidth and buffer space
• Bandwidth Which packet to serve next
  (scheduling)
• Buffer Which packet to drop next (buffer mgmt)
• Queuing also affects latency

Traffic Sources
Traffic Classes
Class A
Class B
Class C
Drop
Buffer Management
Scheduling
29
Standard Internet Queuing

• FIFO (scheduling discipline)
• Implies single class of traffic
• Drop-tail (buffer management policy)
• Arriving packets get dropped when queue is full
  regardless of flow or importance
• FIFO Issues
• No isolation between flows
• No policing send more packets ? get more service
• Drop-tail Issues
• Routers have large queues to maintain high
  utilizations
• Larger buffers gt larger steady state
  queues/delays
• Synchronization
• Lock-out

30
Packet Drop Dimensions
Aggregation
Per-connection state
Single class
Class-based queuing
Drop position
Head
Tail
Random location
Overflow drop
Early drop
31
Random Early Detection (RED) Issues

• Issues
• Breaks synchronization well
• Sensitive to parameter settings
• Does not adequately isolate cooperative flows
  from non-cooperative flows
• Isolation
• Fair queuing achieves isolation using per-flow
  state
• RED penalty box Monitor history for packet
  drops, identify flows that use disproportionate
  bandwidth

32
Variants on RED

• Adaptive RED Adapt maxp to load
• Flow RED Flow w/ too much traffic is penalized
• BLUE
• On buffer overflow, increment marking prob.
• On link idle, decrement marking probability
• REM Random Exponential Marking

REM
RED
1
Avg queue
33
Comparison of AQM Performance

• REM
• queue 1.5 pkts
• utilization 92
• g 0.05, a 0.4, f 1.15

DropTail queue 94
34
Alternate Congestion Control Models

• Loss-based
• TCP Classic
• TCP Reno
• Accumulation-based schemes
• Use per-flow queue backlog as congestion estimate
  (instead of loss rate)
• TCP Vegas
• Monaco
• Explicit rate-based feedback
• Controller at bottleneck assigns rates to each
  flow

35
TCP Reno (Jacobson 1990)
window
time
CA
SS
SS Slow Start CA Congestion Avoidance
36
TCP Vegas (Brakmo Peterson 1994)
window
time
CA
SS

• Accumulation-based scheme
• Converges, no retransmission
• provided buffer is large enough for no loss.

37
Two Accumulation-Based Schemes

• Monaco
• Accumulation estimation out-of-band / in-band
• Congestion response
• Additive Increase/Additive Decrease (AIAD)
• Vegas
• Accumulation estimation in-band
• Congestion response
• Additive Increase/Additive Decrease (AIAD)

37
38
Accumulation vs. Monaco Estimator


time
1
j
j1
J
39
Accumulation vs. Monaco Estimator
1
jf
Jf
jf1
djf
fi
data
µij
?i,j1
µi
?i
ctrl
Jb
jb1
jb
1
djb
ctrl
out-of-bd ctrl
classifier
FIFO
in-band ctrl, data pkt
39
40
TCP Modeling

• Given the congestion behavior of TCP can we
  predict what type of performance we should get?
• What are the important factors
• Loss rate
• Affects how often window is reduced
• RTT
• Affects increase rate and relates BW to window
• RTO
• Affects performance during loss recovery
• MSS
• Affects increase rate

41
Overall TCP Behavior

• Lets focus on steady state (congestion
  avoidance) with no slow starts, no timeouts and
  perfect loss recovery
• Some additional assumptions
• Fixed RTT
• No delayed ACKs

Window
Time
42
Law

• Equilibrium window size
• Equilibrium rate
• Empirically constant a 1
• Verified extensively through simulations and on
  Internet
• References
• T.J.Ott, J.H.B. Kemperman and M.Mathis (1996)
• M.Mathis, J.Semke, J.Mahdavi, T.Ott (1997)
• T.V.Lakshman and U.Mahdow (1997)
• J.Padhye, V.Firoiu, D.Towsley, J.Kurose (1998)

43
TCP Friendliness

• What does it mean to be TCP friendly?
• TCP is not going away
• Fairness means equal shares
• Any new congestion control must compete with TCP
  flows
• Should not clobber TCP flows and grab bulk of
  link
• Should also be able to hold its own, i.e. grab
  its fair share, or it will never become popular

44
Binomial Congestion Control

• In AIMD
• Increase Wn1 Wn ?
• Decrease Wn1 (1- ?) Wn
• In Binomial
• Increase Wn1 Wn (? / Wnk)
• Decrease Wn1 Wn - ? Wnl
• k0 l1 ? AIMD
• l lt 1 results in less than multiplicative
  decrease
• AIMD (k0, l1) is the most aggressive of this
  class
• SQRT (k1/2,l1/2) and IIAD (k1,l0)
• Good for applications that want to probe quickly
  and can use any available bandwidth, e.g.
  multimedia
• TCP friendly

45
Static Optimization Framework
pl(t)
xi(t)
Feedback?

• Duality theory ? equilibrium
• Source rates xi(t) are primal variables (i is a
  flow)
• Congestion measures pl(t) are dual variables,
  where pl(t) prob of loss on link l at time
  t
• Congestion control is optimization process over
  Internet

46
Overview Equilibrium

• Interaction of source rates xs(t) and congestion
  measures pl(t)
• Duality theory
• They are primal and dual variables
• Flow control is optimization process
• Example congestion measure
• Loss (Reno)
• Queueing delay (Vegas)

47
Active Queue Management (AQM)

• Idea provide congestion information by
  probabilistically marking packets
• Issues
• How to measure congestion (p and G)?
• How to embed congestion measure?
• How to feed back congestion info?

48
AQM Summary
49
ATM ABR Explicit Rate Feedback
RM Cell
Source
Destination

• Sources regulate transmission using a rate
  parameter
• Feedback scheme
• Every (n1)th cell is an RM (control) cell
  containing current cell rate, allowed cell rate,
  etc
• Switches adjust the rate using rich information
  about congestion to calculate explicit, multi-bit
  feedback
• Destination returns the RM cell to the source
• Control policy Sources adjust to the new rate

50
Efficiency vs. Fairness OSU Scheme

• Efficiency high utilization
• Fairness Equal allocations for contending
  sources
• Worry about fairness after utilization close to
  100 utilization . Target Utilization (U) and
  Target Utilization Band (TUB).

overload region
worry about fairness here
999591
TotalLoad
TUB
U
underload region
Time
51
TCP Rate Control

• Step 1 Explicit control of window

Congestion window (CWND)
W
Actual Window Min(Cwnd, Wr)

• Step 2 Control rate of acks (ack-bucket)
  Tradeoff ack queues in reverse path for fewer
  packets in forward path

r
pkts
W
acks
R
Time
52
MulticastReview
53
IP Multicast Architecture
Service model
Hosts
Host-to-router protocol(IGMP)
Routers
Multicast routing protocols(various)
54
IP Multicast Model RFC 1112

• Message sent to multicast group (of receivers)
• Senders need not be group members
• A group identified by a single group address
• Group membership is not explicitly known
• Receivers can join or leave at will
• Packet Distribution tree
• Class D IP addresses Allocation issues
• Multicasts are flooded across MAC-layer bridges
  along a spanning tree
• Scoping Limit how far transmissions propagate

55
IP Multicast Architecture
Service model
Hosts
Host-to-router protocol(IGMP)
Routers
Multicast routing protocols(various)
56
Internet Group Management Protocol

• IGMP signaling protocol to establish,
  maintain, remove groups on a subnet (Control
  Plane)
• Objective Keep router up-to-date with group
  membership of entire LAN
• Each host keeps track of which multicast groups
  are subscribed to

57
IP Multicast Architecture
Service model
Hosts
Host-to-router protocol(IGMP)
Routers
Multicast routing protocols
58
Multicast Routing

• Basic objective Build distribution tree for
  multicast packets
• The leaves of the distribution tree are the
  subnets containing at least one group member
  (detected by IGMP)
• Multicast service model makes it hard
• Anonymity
• Dynamic join and leave

59
Simple Multicast Routing Techniques

• Flood and prune
• Begin by flooding traffic to entire network
• Prune branches with no receivers
• Examples DVMRP, PIM-DM
• Unwanted state where there are no receivers
• Link-state multicast protocols
• Routers advertise groups for which they have
  receivers to entire network
• Compute trees on demand
• Example MOSPF
• Unwanted state where there are no senders

60
How to Flood Efficiently?

• A router forwards a packet from source (S) iff it
  arrives via the shortest path from the router
  back to S
• Reverse path check!
• Packet is replicated out all but the incoming
  interface
• Reverse shortest paths easy to compute ? just use
  info in DV routing tables
• DV gives shortest reverse paths
• Efficient if costs are symmetric

S
y
x
z
Forward packets that arrive on shortest path from
t to S (assume symmetric routes)
t
a
61
Reverse Path Broadcasting (RPB)

• Basic idea Forward a packet from S only on
  child links for S
• Child link of router x for source S Link that
  has x as parent on the shortest path from the
  link to S

S
5
6
x
y
a
child link of x for S
z
b
62
Truncated RPB

• Don't forward traffic onto networks with no
  receivers
• Identify leaves (see below)
• Detect group membership in leaf (IGMP)
• Identify leaves
• Leaf links are the child links that no other
  router uses to reach source S
• Use periodic updates of form
• this is my next-link to source S
• If child is not the next-link for anyone, it is
  a leaf

63
Flood with Truncated Broadcast
G
G
S
G
64
Pruning
G
G
Prune (S,G)
Prune (S,G)
S
G
65
Grafting
G
G
G
Report (G)
Graft (S,G)
Graft (S,G)
S
G
66
After Grafting Complete
G
G
G
S
G
67
Distance-Vector Multicast Routing

• DVMRP consists of two major components
• A conventional distance-vector routing protocol
  (like RIP)
• A protocol for determining how to forward
  multicast packets, based on the unicast routing
  table
• DVMRP router forwards a packet if
• The packet arrived from the link used to reach
  the source of the packet
• Reverse path forwarding check RPF
• Packet forwarded ONLY to child links
• If downstream links have not pruned the tree

68
Multicast Backbone (MBone)

• An overlay network of IP multicast-capable
  routers using DVMRP
• Tools sdr (session directory), vic, vat, wb

R
Host/router
H
MBone router
Physical link
Tunnel
Part of MBone
69
Multicast OSPF (MOSPF)

• Extend OSPF to support multicast
• Multicast-capable routers flag link state routing
  advertisements
• Link-state packets include multicast group
  addresses to which local members have joined
• Routing algorithm augmented to compute
  shortest-path distribution tree from a source to
  any set of destinations
• Compute tree on-demand when first packet from a
  source S to a group G arrives

70
Routing Techniques (Taxonomy)

• Tree building methods
• Data-driven Calculate the tree only when the
  first packet is seen. Ex DVMRP, MOSPF
• Control-driven Build tree in background before
  any data is transmitted. Ex CBT
• Join-styles
• Explicit-join The leaves explicitly join the
  tree. Ex CBT, PIM-SM
• Implicit-join All subnets are assumed to be
  receivers unless they say otherwise (e.g. via
  tree pruning). Ex DVMRP, MOSPF

71
Shared vs. Source-based Trees

• Source-based trees
• Separate shortest path tree for each sender
• (S,G) state at intermediate routers
• Ex DVMRP, MOSPF, PIM-DM, PIM-SM
• Shared trees
• Single tree shared by all members
• Data flows on same tree regardless of sender
• (,G) state at intermediate routers
• Ex CBT, PIM-SM

72
Source-based Trees
Router
Source
S
Receiver
R
R
R
R
S
S
R
73
A Shared Tree
Router
Source
S
Receiver
R
R
R
RP
R
S
S
R
74
Shared vs. Source-Based Trees

• Source-based trees
• Shortest path trees low delay, better load
  distribution
• More state at routers (per-source state)
• Efficient in dense-area multicast
• Shared trees
• Higher delay (bounded by factor of 2), traffic
  concentration
• Choice of core affects efficiency
• Per-group state at routers
• Efficient for sparse-area multicast

75
Protocol Independent Multicast (PIM)

• Support for both shared and per-source trees
• Dense Mode (per-source tree)
• Similar to DVMRP
• Sparse Mode (shared tree)
• Core Rendezvous Point (RP)
• Independent of unicast routing protocol
• Just uses unicast forwarding table

76
Multicast Address-Set Claim (MASC)

• Address allocation goals
• Efficient utilization of address space
• Aggregation of routing entries
• Robust and scalable
• Distributed, collaborative allocation
• Dynamic claim and listen protocol
• Claim prefixes from parent
• Communicate prefixes to local address allocation

77
Reliable Multicast The Goal

• Implement reliability on top of IP multicast
• Why is this hard ?
• Sender cannot keep state for unknown number of
  dynamic receivers
• Algorithms like TCP that estimate path properties
  such as RTT and congestion window dont
  generalize to trees.
• Has to address (N)ACK implosions

78
Implosion
Packet 1 is lost
All 4 receivers request a resend
S
S
Resend request
2
1
R1
R1
R2
R2
R3
R4
R3
R4
79
Retransmission

• Re-transmitter
• Options Sender or other receivers
• How to retransmit
• Unicast, multicast, scoped multicast,
  retransmission group,
• Problem Retransmissions (aka repairs) may reach
  destinations that dont require a retransmission
• A.k.a exposure problem
• Solution Subcast the re-transmission only to
  receivers that need it.

80
Reliable Multicast Transport Issues

• Retransmission can make reliable multicast as
  inefficient as replicated unicast
• (N)ACK-implosion if all destinations ack at once
• Crying baby A bad link affects entire group
• Heterogeneity Receivers, links, group sizes
• Anonymous/Open/Dynamic Group Model
• Source does not know of destinations, and
  destinations may vanish
• Multicast applications do not need strong
  reliability of the type provided by TCP
• Can tolerate some reordering, delay, etc

81
RMT Building Blocks RFC 3048

• NACK only
• Ex SRM uses only end-to-end mechanisms.
• Tree-based ACK
• Aggregators reduce reverse traffic (RMTP-II)
• Asynchronous Layered Coding (ALC)
• Forward-error correcting (FEC) codes
• And no feedback. (a.k.a. proactive FEC)
• Router Assist (e.g. PGM)
• NAKs but router support for aggregation.
• FEC retransmissions (a.k.a. reactive FEC)
  instead of data retransmissions

82
SRM

• Originally designed for wb (white board)
• Receiver-reliable
• NACK-based
• Every member may multicast NACK or retransmission

83
SRM NAK Suppression
Packet 1 is lost R1 requests resend to Source
and Receivers
Packet 1 is resent R2 and R3 no longer have to
request a resend
S
S
Resend request
Resent packet
X
2
1
1
R1
R1
X
R2
R2
X
Delay varies by distance
R3
R3
84
SRM Summary

• All members get all the data that has been sent
  to the multicast group (packet reliability )
• Repair requests responses are multicast.
• Scope of repair requests responses can be TTL
  limited or a separate local recovery group can
  be formed
• Techniques to avoid implosion of repair requests,
  and reduce control traffic NAK backoff timers
• Delay before sending
• Delay based on RTT estimation
• Deterministic Stochastic components
• Periodic session messages
• Full reliability
• Estimation of distance matrix among members

85
Pragmatic General Multicast (PGM)
Packet 1 resent to R2, R3, R4 Not resent to R1
Packet 1 reaches only R1 R2, R3, R4 request
resends
Routers remember resend requests
S
S
Resend request
Resent packet
X
2
1
1
R1
R1
1
R2
R2
1
1
1
1
1
1
R3
R4
R3
R4
86
ALC Protocol Digital Fountain

• Instead of using a single multicast group, split
  data over multiple groups
• Ex Groups at 8, 16, 32, 64, 128, 256 Kbps
• Receivers can receive from 8 - 504 Kbps
• Requires a way of splitting data up
• Hierarchical video codecs
• File transfer with Tornado FEC codes
• Supports very large and heterogeneous groups,
  simple to implement
• Requires sparse mode routing protocols

87
Multicast Congestion Control

• What if receivers have very different bandwidths?
• Send at max?
• Send at min?
• Send at avg?

100Mb/s
R
100Mb/s
S
R
1Mb/s
???Mb/s
1Mb/s
R
R
56Kb/s
88
PGM Congestion Control (PGMCC)

• Receivers measure their loss and RTT
• The slowest receiver sends back an ACK on each
  data packet (i.e. ack clock)
• The sender runs TCP congestion control algorithms
  using these ACKs
• Results in faster responsiveness but somewhat
  high variation in send rate
• Works well for small groups, or if only a single
  receiver at a time is congested

89
Receiver-driven Layered Multicast (RLM)

• Layered video encoding
• Each layer uses its own multicast group
• Receiver subscribes to max group that will get
  through with minimal drops
• Dynamically adapt to available capacity
• Use packet losses as congestion signal
• On congestion, receivers drop a layer
• On spare capacity, receivers add a layer
• Join experiments used for shared learning
• Assume no special router support
• Packets dropped independently of layer

90
How to Find the Sources?

• Broadcast Everywhere
• Receivers decide when they do not want the
  traffic
• Any Source Multicast (ASM) PIM-SM, MBGP, MSDP,
  IGMPv2
• Use a rendezvous point (RP)
• Receivers send joins along reverse path to RP
• Sources send traffic to RP
• Source Specific Multicast (SSM) PIM/MBGP/IGMPv3
• Require receivers to already know source(s)
• Use some out-of-band mechanism

91
IP Multicast Concerns

• Deployment is difficult and slow
• ISPs are reluctant to turn on IP Multicast
• Open Group Model Anyone can join a Group
• Inter-domain routing MSDP (Multicast Source
  Discovery Protocol) doesnt scale
• Address allocation is also complex
• PIM-SM requires a Rendezvous Point (RP) Subject
  to attack
• Multicast tried to solve too many problems

92
Single-Source Multicast (SSM)

• Source-specific channel (S,G)
• Only S can send to G
• Another source S must use a separate channel
  (S,G)
• Hosts join channels, so a member joining only
  (S,G) will NOT receive traffic from S
• Current infrastructure uses Any-Source Multicast
  (ASM)
• Any source can send to any group at any time

93
SSM Advantages

• No RP, No need for MSDP
• All joins are (S,G), so no need for Class D
  address allocation
• Receivers find out about sources through
  out-of-band means (such as a web site)
• SSM-only implementations are much simpler than
  the full PIM-SM
• No RP, No Bootstrap RP Election
• No Register state machine
• No need to keep (,G), (S,G,rpt) and (,,RP)
  state
• No (,G) Assert State

94
Application-level Multicast

• Do we really need network level multicast?
• Efficiency
• Logical rendezvous
• Can we get efficiency by creatively using the
  actual members or a few infrastructure nodes?

95
Narada End System Multicast (CMU)
Stanford
Gatech
Stan1
Stan2
CMU
Berk1
Berk2
Berkeley
Overlay Tree
Stan1
Gatech

Stan2
CMU
Berk1
Berk2
96
Overlay Tree

• The delay between the source and receivers is
  small
• Ideally, the number of redundant packets on any
  physical link is low
• Heuristic
• Every member in the tree has a small degree
• Degree chosen to reflect bandwidth of connection
  to Internet

CMU
CMU
CMU
Stan2
Stan2
Stan2
Stan1
Stan1
Stan1
Gatech
Gatech
Berk1
Berk1
Berk1
Gatech
Berk2
Berk2
Berk2
Efficient overlay
High degree (unicast)
High latency
97
Network Management Review
98
What is Network Management?

• What to do when networks don't operate as
  intended?
• Goal Identify and solve network problems not
  handled by normal network functions such as
  routing, congestion control, MAC protocol, ...
• Examples of network management problems
• Faults
• Failures
• Performance problems
• Configuration changes
• Security violations

99
Why is Network Management Hard?

• Very large networks
• Heterogeneous, multivendor networks
• Multidomain, multiauthority
• Massive amounts of data ...
• At every device.
• At every layer.
• At multiple time scales.
• Focuses on unusual events
• Catch-all category

100
Simple Network Management Protocol (SNMP)

• Introduced in RFC 1157 by M. Schoffstall, et al.
• Updated to SNMPv2 in 1993
• Components
• Managed nodes, each running an SNMP Agent
• One (or more) management stations running an SNMP
  Manager
• Managed Objects (variables) Structured
  collection of all Managed Objects is called the
  Management Information Base (MIB)
• A Manager--Agent communication protocol

101
Management Information Base (MIB)

• MIB variables are represented using Abstract
  Syntax Notation One (ASN.1), an object
  description language.
• Most MIB variables are vendor neutral
• More and more proprietary MIBs.
• A MIB is organized as a directory tree with MIB
  variables at the leaves.
• A MIB for SNMPv2 is called a MIB II.

102
SNMP Communication

• A simple data base query language
• Communication via a UDP socket
• Communication primitives
• GET Get values of one or more variables
• SET Set values of one or more variables
• INFORM Manager to Manager communication
• TRAP Problem report by Agent to Manager(s)
• Manager and Agent use UDP port 161 for GET, SET,
  and INFORM
• Agent sends TRAP to port 162 on mgmt station

103
SNMP Properties

• Stateless gt one management station can handle
  hundreds of agents
• Simple Works as an application protocol running
  over UDP
• Agent and manager apps work on top of SNMP
• Proxy-SNMP can be used to manage a variety of
  devices (serial lines, bridges, modems etc).
• Proxy (similar to bridge) is needed because these
  devices may not run UDP/IP
• For each new device define a new MIB.

104
RMON

• Remote Network Monitoring
• Defines remote monitoring MIB that supplements
  MIB-II and is a step towards internetwork
  management
• Extends SNMP functionality though it is simply a
  specification of a MIB
• Problem w/ MIB-II
• Info is purely local to individual devices
• Cannot easily learn about LAN traffic as a whole

105
Research Problems

• Current network management is really network
  monitoring with human system administrator called
  to solve the problem.
• How do we analyze data and extract useful
  information? (Diagnosis)
• How do we automate the response to a diagnosis?
  (Cure)