Yoid Paper: chages the definitions of multicast and broadcast. 
Redefining commonly used terms is BAD!  (although both terms are used
pretty loosely anyway).
 
Review of RSVP - Corrections from last time
Internet Reservation Protocol
    - Soft state (no long-term information)
    - receiver-driven (easier logistically to support multicast that way)
Step 1) PATH msg (connection setup) from source to all listeners
    - records information about path at each router
Step 2) Reservation sendt from receiver to source (RESV)
    - router allocates BW at each point
    - multicast messages will be combined where possible
Both PATH & RESV are periodically refreshed: discovers changes in
topology.
 
Multicast
Why do we need it?
    - group communication (sending data to all members of a group)
        [efficient use of bandwidth]
    - resource discovery: expanding ring multicast - discovery of 1-hop,
2-hop... neighbors
    - rendezvous: link up with an unknown host in a multicast group.
(anycast)
Last 2 are also solved with Google, etc., so what's the point?
Define Efficiency
    - smallest # of packets
    - fewest copies/link
    - shortest latency
    - minimize loss, failures, and response to them
 
Which layer is best?
Application layer - host to host overlay
IP Multicast - specially marked multicast packets, duplicated when
necessary at routers
    - less dependent on trustworthy hosts
    - already supported in router hardware, BUT
    - doesn't solve loss problems without application help
    - vulnerable to DoS (1 packet -> many packets)
    - harder to deploy widely (applications AND routers must support)
 
Service Model: anyone can join, anyone can send
Alternative: EXPRESS - each group has a single sender
 
Business Model
Included in routers so they can say they have the feature
It isn't used because ISPs charge by the bit -- why reduce the number of
    packets?
Charging per receiver would make pricing unpredictable -- no one will use
    it
There's no obvious pricing model -- that's the problem!
 
It CAN work for private intranets (govt, business, education, etc)
 
Overlay Options
Which is cheaper?
- 1 server sends N packets
- Distributed tree and overlay delivers packet to N nodes
The first solution is better, because fewer total packets are in transit!
 
Caching, in a sense, is a form of multicast.  Akamai, by reducing the
amount that a local ISP has to receive from other ISPs, is an economic
model that works.
The amount they can save is bounded by Ziph's law, which says how
frequently unpopular sites are accessed.
 
Questions
- service model? (discussed above)
- routing?
- reliability ?
- congestion control
 
Routing
- flooding: send packets everywhere (enormously inefficient for small
groups)
    Routers must track every packet they've ever seen to avoid loops
- Reverse path multicast: join requests are forwarded along shortest path
to receiver.  Great, if Distance Vector Routing is being used.  Else,
- Protocol Independent Multicast (PIM):
    Rendezvous points
    Join message is unicast routed to RP
 
Overlay routing
Yoid - rendezvous point that stores group membership
        how does this get initialized?  static configure?
Proximity is hazy in Internet topography, so this problem is difficult.
 
Reliabiltity - Scalable Routing Multicast (SRM)
- TCP ack system will cause implosion!
- negative acks can also cause implosion if failure is near source
- In SRM, replacement packet is provided locally.
- NACK and fulfillment of retransmission is multicast to all hosts.