Broadcast Federation Untangling the Internet Multicast Landscape Yatin Chawathe Research, Menlo Park Joint work with Mukund Seshadri

2 Overview The problem:The problem: q No global multicast/broadcast solution q Non-interoperable broadcast technologies The missing piece:The missing piece: q An internetworking architecture Our approach:Our approach: q Overlay of “peering gateways” with explicit peering agreements

3 The Problem ISP’s multicast network SSM-only network yet another CDN Broadcast CDN Too many non-interoperable broadcast protocols How do clients in one network access content being broadcast in another network? Broadcast Networks (BNs)

4 No single solution is viable IP multicastIP multicast q No viable inter-domain protocol q Address scarcity SSMSSM q Better semantics and business model q But, restricted service model Overlay CDNsOverlay CDNs q Easier to deploy, but less efficient, need more infrastructure

5 An Interconnection Architecture Composition of diverse broadcast networksComposition of diverse broadcast networks q Equivalent of BGP in the unicast IP world Requirements:Requirements: q Support range of net- & app-layer protocols q Scale up in size (# of sessions, # of clients) q Support explicit service agreements

6 Our Approach: Broadcast Federation Federation JOIN request Broadcast Networks (BNs) Broadcast Gateway (BG) Unicast pipes: Explicit service agreements Build an overlay network across broadcast networks: i.e., a Broadcast Federation Build an overlay network across broadcast networks: i.e., a Broadcast Federation

7 Service Model Federation session “owned” by single BNFederation session “owned” by single BN q Convenient rendezvous point q Distribution trees rooted at owner BN Independent of intra-network protocols Independent of intra-network protocols URL-style session names:URL-style session names: q bfed://owner_bn/native_session_name?pmtr=value&… e.g., bfed://multicast.att.net/ :4444 e.g., bfed://multicast.att.net/ :4444 q Parameters provide session-specific information e.g., sources=multiple, metric=bandwidth e.g., sources=multiple, metric=bandwidth

8 Protocol Layers I. Routing q Propagate reachability information II. Tree-building  Handle session JOINs and LEAVEs III. Data-forwarding q Construct transport channels for data packets IV. NativeNet q Customize lower layers for specific BN

9 I. Routing Layer Session-agnostic:Session-agnostic: q Routing from BN to BN q For finer-grained routes: Maintain routes to BN via all reachable BGs “Content-aware” routing:“Content-aware” routing: q Maintain multiple routing tables Real-time vs bulk-data Real-time vs bulk-data Single-source vs multi-source Single-source vs multi-source Latency vs bandwidth Latency vs bandwidth

10 II. Tree-building Layer One tree per session:One tree per session: q Reverse shortest path, rooted at owner BN q Single-source  uni-directional tree Multi-source  bi-directional tree Two components:Two components: q Mediator How does client send JOIN to its “access BN” How does client send JOIN to its “access BN” q SROUTEs How does access BN pick best upstream node How does access BN pick best upstream node

11 For example:For example: q CDN: mediator is part of edge servers q IP multicast network: well-known multicast group Mediator Abstract interface to clientsAbstract interface to clients  Clients send JOINs to Mediator q Mediator forwards them on q Implemented in BN’s native fabric or integrated in BGs BN 1 BN 2 Mediator JOIN

12 SROUTEs: Session-specific Routes Mediator BN 2 BN 1 D B C A Default best route To BN 1 Alternative route to BN 1 via exit-BG A Client sends JOIN request to local MediatorClient sends JOIN request to local Mediator Two possible routes for connecting from BN 2 to BN 1Two possible routes for connecting from BN 2 to BN 1 Mediator forwards JOIN request to default BG (D) for owner BNMediator forwards JOIN request to default BG (D) for owner BN If default BG has no session-specific route, thenIf default BG has no session-specific route, then  It sends SROUTE request toward BN 1 BN 1 returns SROUTE responseBN 1 returns SROUTE response q Contains session-specific costs local to owner BN Default BG (D) computes best session-specific routeDefault BG (D) computes best session-specific route Sends REDIRECT response to mediatorSends REDIRECT response to mediator Mediator send JOIN request to session BG (C)Mediator send JOIN request to session BG (C) JOIN request propagates up to BN 1JOIN request propagates up to BN 1 All messages are soft-stateAll messages are soft-state q Distribution tree automatically adapts to route changes Pros and ConsPros and Cons SROUTEs stored only along distribution tree path SROUTEs stored only along distribution tree path û Increased setup latency JOIN SROUTE request SROUTE response REDIRECT JOIN

13 III. Data Forwarding Layer Mediator BN 2 BN 1 Hop-by-hop TRANSLATE messages establish data pathHop-by-hop TRANSLATE messages establish data path q Map Federation session names into local network addresses q External peers use unicast; within a BN, use native broadcast JOIN: bfed://BN 1 /CDN-URL TRANSLATE: multicast://G:port JOIN: bfed://BN 1 /CDN-URL JOIN: CDN-URL TRANSLATE: udp://IP:port Provides flexible data path allocationProvides flexible data path allocation q E.g., cluster-based BGs assign different backend nodes for different sessions CDN IP multicast SSM TRANSLATE: ssm://S,G:port TRANSLATE: udp://IP:port

14 IV. NativeNet Layer Customization API for each BGCustomization API for each BG á allocate_channel á subscribe/refresh/unsubscribe á reclaim_channel á get_sroutes á send_data â recv_join/recv_leave â recv_data

15 Status We have a prototype implementationWe have a prototype implementation q Linux/C++ user-level application NativeNet implementations for:NativeNet implementations for: q IP multicast, Source-specific multicast, and HTTP-based CDN q Each is lines of code Preliminary results:Preliminary results: q Single BG can handle load on 100Mbps network, 4 BG nodes sufficient for 1Gbps

16 Conclusion Fragmented broadcasting landscapeFragmented broadcasting landscape q Many non-interoperable broadcast protocols Loosely-coupled Federation architectureLoosely-coupled Federation architecture q Internetwork of diverse broadcast technologies q Application-layer Broadcast Gateways Explicit peering agreements Explicit peering agreements Overlay of unicast and broadcast connections Overlay of unicast and broadcast connections

17 Open Questions Automated mediator discovery:Automated mediator discovery: q How do clients discover their “access BN”? Transport mismatch:Transport mismatch: q Multiple routing tables avoids problematic paths, e.g., real-time video via TCP-based BNs q What if the only path has a transport mismatch? Complex routing queries:Complex routing queries: q E.g., combination of bandwidth and system load

18 Rate-unlimited Sessions

19 Rate-limited Sessions