2.5.13 Multicast Addr. Exten. & Simple Transmitter Opti. (maestro) bof

Current Meeting Report

MAESTRO BOF, Dave Oran

AGENDA

History - modify multicast model, do we need a working group on this?

A number of people think if we simplify the multicast model there are significant benefits in reducing complexity. changes: addressing model, assume single sender.

We want to look at the problems today and see how proposed simplications might help.

Ground rules: talk about problems and how they map to the proposed simplifications. from two perspectives, isp's and architectural view.

Bryan Lyles, Sprint Deployment Strategy

Today, multicast enabled, working with vendors and customers to make it work. built on PIM-SM, MSDP, MBGP, IGMPV2, GLOP.

Short Term - push current protocols, work in ietf to enhance base.

Certain kinds of applications want single server (radio station, politician giving speech, dont want opposition heckling him)

Hugh Holbrook, Stanford/Cisco

Some multicast applications work well with unicast others its impossible, high data rates, many receivers questions to isp's - how do you bill for it. make billing reflect cost. so charge by size of group.

dmm - if i am a source, receivers on same isp are onnet, other receivers are offnet. want to billed for offnet folks.

brad cain - bill by bandwidth, can isp's break even on multicast.

Queries flow down tree, counts flow back up, somehow gather data to bill src. access control for large groups, restrict senders in advance (pirates on tv station), important for commercial applications too.

kevin almeroth - why does it work with radio, lawyers are the answers, no one owns a multicast address, if they did you could sue someone for using yours without permission.

security - source provides passwd to receivers

www.dsg.stanford.edu/hollbrook/express

Jeremy Hall, uunet

Problems - scalability, single source model ok, hard to implement. you are trying to restrict something that is not restrictable. lots of protocols running as ships in the night, ok when it works, never know which one is not working correctly. way too much ad hoc stuff going on. which protocol is broken. nice to be able to trace a problem from the sender, to the receiver. receiver says i'm not receiving this content. have to figure out from that info, where the source is and what the problem is.

Some applications hide the group, so you cant figure out where to troubleshoot. people dont understand how it works, so they cant help you debug. need education.

Billing problems, counting receivers might be nice but is hard as groups get big. onnet vs offnet. tried to employ things that are parallel to unicast. unicast routing tries to dump traffic asap, mulitcast wants to keep as long as possible. current model doesnt scale. anyone can source to any group and thats a security problem. there are a lot of security issues with multicast.

Mark Handley, ACIRI

Internet Standard Multicast, where it came from and why it had nice properties. direct extension of the unicast model, host sends packets to destination address, it gets there. Nice architecure, senders dont need to know about receivers. recievers dont need to know who senders are. distributed binding is useful resource. senders and receivers dont need to know about topology, robust, route around failures etc. hosts dont need to knows about routing protocool. need distinction between service model and its implementation in the network. separates what the application wants and how the network achieves it. Clean separation of routing and transport/application layer.

What can we do with it:

Regular one to many applications - video distribution, data distribution many to many applications - conferening, games, dont know members in advance, distributed binding is very robust, changes the way you design applications (eg wb)

Many to few applications - server discovery

Scoping, used to have ttl scoping, poor for traffic engineering, great for self organizing applications, expanding ring search, we lost the ttl in pim, admin scoping getting it back, mzap

Security - can only restrict traffic safely with encryption. content providers want authentication, have the mechanisms already.

problems:

- forwarding table size, aggregation helps some;
- how can isp's make money;
- lack of scalable routing protocol, bgmp, hierarchical pim,
- bi-direction pim with grib, bgmp will probably work,
- hierarchical pim too;
- lack or good network management and diagnostic tools.

serious growing pains, transition from dvmrp painful

distributed binding a key - wb, sdr, mimaze applications

important to avoid constraining network mechanisms to support only one to many applications

Bryan - lots of differences of opionion in the community.
Hugh - avoid overly commplicating things for futures applications when we have existing applications that need support now.

jon crowcroft, ucl, www.cs.ucl.ac.uk/research/rama

Enhancing deering multicast, enhancing the addressing scheme. class D address is a channel, not really an ip address. Anonymously names a group of receivers, allows anyone to send to it. alternatives, allow end systems to be explicit DCM/connectionless multicast - add list of addresses, transparency and fault tolerance

David Oran - Final Questions

we have 5 minutes, where should we go with this?

Brian Whetten - wishes had heard more from isps about problems.

TODO - decide which problems are of deployment and which are based on what we are deploying.

Scott Petrak - 3 things: think about low bandwidth hosts at the end, like wireless; thing 2 i missed; small number of senders a worthy optimization.

Dorian Kim - deployment problems have been maturity of implementation issues and how to make all the hacks play together. havent tried running native multicast at scales we want. will find more answers as we deploy and ramp up, at this point probably not worth limiting model.

Hum votes
- create a mailing list 2/3 hum
- no mailing list 1/3 hum

Slides

None received.