Subject: Re: Maestro BoF Results

From: christophe diot <[email-masked]>
Date: Mon, 02 Aug 1999 08:59:58 -0700

David Oran wrote:
> 
> The Routing Area held a BoF at the Oslo IETF whose purpose was to discuss
> potential refinements to the IP multicast model in two areas:
>   1) Enhanced two-part multicast addressing to ease scalability and
> deployment
>      headaches,
>   2) Optimizations to exploit the single-sender case
> 
> The BoF announcement, along with its scope and agenda, may be found at:
> http://www.ietf.org/ietf/99jul/maestro-agenda-99jul.txt.
> 
> I am sending this message to who I think are all the relevant WG mailing
> lists, and it will also be sent out via IETF-announce, so please let me know
> directly if I've missed a relevant group rather than risk clogging peoples'
> mailboxes with multiple forwards.
> 
> The minutes of BoF are attached below. One of the conclusions from the BoF
> was to continue discussions on these subjects to ascertain if there is a
> critical mass of support to charter one or more Working Groups to pursue
> IETF standards (or other outputs) in these areas. We are therefore
> resurrecting a moribund Routing Area mailing list for this purpose:
>         [email-masked]
> Subscription is via [email-masked]
> 
> Thanks to all who participated in the BoF and in advance for useful
> low-flamability discussion on the mailing list.
> 
> Regards, Dave Oran (routing co-area director)
> 
> 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)

If I remember well, this is not exactly what we said ... 
What we "also" sayed is that we 
encouter problems with providing stable and robust multicast service, 
and that we are not really satisfied with the current protocol
architecture 
and with its implementation (difficult to know if the architecture or
the implementation is broken).

The conslusion of the talk was that Sprint would like IETF to consider 
a protocol architecture that would be stable, more simple, and more
scalable.

> 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 radia, 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

-- 
=======================================================

christophe Diot         | tel: 1(650)375.4539
Sprint ATL              | fax: 1(650)375.4490
1 Adrian Court          | [email-masked]
Burlingame CA 94010     | www.sprintlabs.com
USA                     |

---

From: David Oran <[email-masked]>
Date: Mon, 2 Aug 1999 11:17:41 -0400

MAESTRO BOF, Dave Oran
----------------------

AGENDA

Jeremy Hall, uunet
------------------

Mark Handley, ACIRI
-------------------

What can we do with it:

problems:

Hum votes