html5-img
1 / 14

Network Architecture (R02) #3 Multicast and Deployment

Network Architecture (R02) #3 Multicast and Deployment. Jon Crowcroft, http://www.cl.cam.ac.uk/~jac22 http://www.cl.cam.ac.uk/teaching/1011/R02. +ve multicast for publisher. Capacity win at sender Some capacity win in network Latency lower potentially For very very popular live content

Télécharger la présentation

Network Architecture (R02) #3 Multicast and Deployment

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. Network Architecture (R02) #3Multicast and Deployment Jon Crowcroft, http://www.cl.cam.ac.uk/~jac22 http://www.cl.cam.ac.uk/teaching/1011/R02

  2. +ve multicast for publisher • Capacity win at sender • Some capacity win in network • Latency lower potentially • For very very popular live content • Might be only technique • Might steal broadcast tv/radio customers into ISP customer base • Ease of writing applications • Especially collaborative tools (wb/nte etc) for ASM • Except many-to-many reliability very hard:(

  3. -ve for IP Multicast • Problems abounded early on with ASM • Only tunnel based implementation • Fanout limit 6! (ethernet:-( • DVMRP limits • First native code broke unicast • Berkeley report • Igmp v1 timers • PIM route loop!

  4. Time to market • Slowed by bugs • Since then, timeshifting for media (tivo) • New Needs • Share trading still big customer • Urgent (zero day defense) software update • See vigilante for example • Market needs • ISP loses money from multicast:) • Big publisher wins • ISP loses money from CDNs too….

  5. Architectural list of problems • Some are same as for CDN • Except who manages things • Even Inter-domain • E.g. neutrality debate is basically about CDN v. ISP and impact on peering • Security perhaps main pb • Esp. potential DDoS leverage… • multiplier bad

  6. State complexity v. packet forwarding • PGM has same state complexity as SSM • Latches rx nack state on fwd filter • Can have local rtx too • Digital Fountain allows some timeshift • Complex to manage • All single ISP/AS, not interdomain • Interdomain addr allocation not solves really • Traffic breaks peering rules (reverse path:( • So does interdomain P2P and CDN traffic, though

  7. Privacy, Integrity, DDoS prev • Need key distribution • key graph for ASM • Re-key cost (for fwd/reverse secrecy) expensive • Need source management • Need receiver control • Police IGMP join to group per group • Same as CDN, but free there already • Auth is from subscriber to cloud

  8. ASM, SSM, CDN, pub/sub, p2p • Traffic Engineering? • Per source? Per Content? • Energy reduction? • With timeshifting? • V. p2p? • Hybrids? • Server assist P2P? • Multicast assist CDN? • In Net record/timeshift?

  9. general deployment tricks… • Overlay • Underlay • Tunnel • Map/encap

  10. Overlays and Underlays • IP was once an overlay • On x.25 and on PSTN • Then moved down to bare metal • ip on photons too • Overlays are a deployment/evolutionary route • see national academy of science on “looking over the fence at network research)

  11. Other overlay schemes • Mbone, 6bone, abone • RON • Application Layer Multicast • IP on SMS and on Fb! • IP on DNS • Typically tunnel…but • IP in IP overhead • IP on VC - complexity • Circuit setup/teardown • #circuits, qos • routing

  12. Underlays • more revolutionary than overlays • Not many examples - • MPLS, gMPLS • Finesse management/routing problem • 3gpp/cellular • Finesse mobility&billing problem • Other?

  13. Multicast, mobile, multihome • Similar • More than 1 address (at time, in space) • Dynamic - add receiver/delete • Different • Group dynamics possibly fast • Mobility limited by physics • Multihoming slow

  14. Next talk for 25/10/10 The Location/Identity split has been pushed since 8+8 as the solution to mobility (and multihoming) Discuss the various approaches (e.g. 8+8 and LISP) and their various merits and demerits

More Related