SAM RG @ IETF 66 - Montreal July 13, 2006 Meeting Minutes (taken by Scott Boone) Chairs: John Buford Jeremy Mineweaser --- --- [Buford] WG Overview RG Chartered in May. IP Multicast deployment is slow Some have combined application layer multicast (ALM) tech with native multicast. Are we capable of specifying a hybrid multicast framework that leverages IP multicast where it exists and uses ALM elsewhere is adaptive --- [Buford] Survey of ALM, OM, Hybrid Tech Problem Statement Many possible applications for IP multicast, but slow deployment. NOSDAV 03 keynote details challenges to deployment. We need to offer more flexible deployment options (incremental, etc) This will create more inertia behind applications and encourage more demand for multicast in the network. Other issues - highly dynamic group membership, millions of small groups Other network environments - VPNs, GIG, other Taxonomy Vanilla IP multicast is out of scope Hybrid (Universal Multicast) in scope ALM (overlay [overcast, RMX, AMCast, scattercast], end system) in scope Terms ALM - implemented at app layer. trade between efficiency and ease of deployment overlay - proxies create multicast trees, note that this term is confusing, but research lit calls it overlay hybrid - combine ALM and IP Tree creation types (four) centralized: manager node takes RTT measurements, good tree quality but poor scalability. ALMI mesh-based: members of group are in a mesh. nodes select links out of mesh to use as data path. needs lots of state tree-based: group members self-organize. needs loop detection. lack global knowledge. state is more scalable. Yoid, HMTP implicit: create an overlay with specific properties. forwarding rules implicitly define a tree. NICE, Can, Scribe RP: node that can be designated as a starting point for a group, used in centralized tree-based systems metrics: stress - stress on links stretch - average receiver path length degree - node adjacency e2e delay control message overhead robustness ALM research systems have demonstrated possibility of multicast using end systems as routing agent Comment from Steve Casner : The issue is with IP Multicast is mainly business, not that of implementation; multicast is often implemented in routers but isn't turned on. public directory stores information end point node has app software that lets it participate in mcast session software on RP manages how end system joins tree - request could go to root then be propagated through tree - other ways advantages one advantage of ALM is that router state is not required, it's levied on end systems not using any special IP addresses. deployment is in hands of user (+/-) disadvantages inefficient trees dependent on host resources departing host effects downstream hosts Narada (CMU), comparison of ALM multicast and IP unicast performance (delay) ALMI centralized control for managing joins, limited to small groups nodes do background probe messages to feed back distance metrics to controller includes some reliability mechanisms experiment with a single tree, 9 trans-atlantic sites tree has to converge at the beginning since there's no knowledge falls off sometimes for a while if there's network failures analyzed vs. Yallcast and Endsystem Multicast NICE (UMD) hierarchical proximity based clusters, log N layers, managed by soft-state O(log N) rtts to join, and O(k log N) messages protocol support for cluster split, merges SIGCOMM 2002 comparison of Nice vs. Narada (stress & stretch) longer decay time for narada to converge Overlay Multicast ALM has performance issues, what if we put proxies inside network? design issues where to place - putting proxies in ISPs how much bandwidth scattercast (OM e.g.) no router upgrade, but does require infrastructure support INFOCOM'05 paper analyzing OM models of POM, NICE, NARADA compared e2e delay OM offers middle ground between ALM and native multicast still need wide deployment to provide e2e service Hybrid what if network is regionalized, some parts have native multicast, some only have ALM? can we connect these regions and create e2e interop while we are building out capability in the network? HMTP combines ALM with native multicast designated members act as gateways to the native areas constructs a group-shared tree, RTT used as distance metric maintenance methods HMTP was used in a system called Universal Multicast (UM) best example of a hybrid system UM is a framework, doesn't require HMTP but was used we have a lot of information about various systems Banerjee & Bhattacharjee for this RG we want to get a survey of the existing work and produce an I-D. don't reproduce what's been done, but get a view of the design points. Our analysis could organize existing work and the criteria that we want to adapt to. we want to approach networks with different design points (e.g., small groups, tree metrics, latency in joining) Comment X. Fu: There are some designs points here. How can you incorporate mobility in analysis phase. Response: We're not saying "here's a design", we're trying to coordinate it with different features. Same in the QoS state; if we want to support multi layer coding techniques, there's a number of papers on that in the ALM area. Then we can see if the design decisions match up with Comment: Yuji: There is an application like that. We must be concerned about mobility multicast and scalability. Comment: Steve Casner: In OM, do you anticipate that would be a node providing service to a variety of applications, or is it specific to certain applications? Buford: OM concept was first introduced in a time when OM was a variation of Content Delivery Networks (CDN). Perhaps there is a business model where one could sell enhanced AL multicast to some clients. Maybe there's a biz model, but since there's an increasing use of p2p overlays in internet and tele apps like skype, we can make argument that systems may reach critical mass where they want to build OMs for their specific apps. Maybe there is a different scenarios where they are dedicated to specific apps or app types (e.g., gaming.) Sincewe are at an early stage we should be open with respect to scenarios. Comment: ?? Where we deploy mcast in academic networks we use things like access grid. We use bridges elsewhere. Doesn't give incentive to implement native mcast. One disadvantage of ALM is that it disincentivises people to deploy native mcast. A little bit like tunnel brokers with IPv6, once you have them there's no need to deploy it natively. Buford: We can also say that endgame is that applications can have e2e multicast support, and they don't have that now in any unified way. Bigger question is that one. ??: Where do you see AMT fitting into model? Buford: Can you elaborate? ??: This has been worked on in MBONE. Buford: We want this group to be compatible with other IETF work, not divergent. ??: How did you measure delay in analysis? Buford: We're reporting analysis by other researchers so can't categorically answer that. A lot of these are based on simulations so it's an average from when packet reaches source and gets to each endpoint. In some apps such as bidir streaming, delay is an important consideration. ??: How small are small groups? Buford: OM Study shows 10-1000 nodes. ??: Ten users isn't interesting if it's 10k. Numbers can be a lot different with different numbers of users, how random are, and how big content is. A lot of researches don't look at how designs cover a broad range of content, we need some additional metrics to make sure things don't break. Falk: Speaking as IRTF chair. Jabber room was neglected, so one was just created. Agenda posted, which didn't make it to Bill: Until service providers discover they have all this extra traffic that could be eliminated, they won't look at native multicast. Question is whether that balance point is ever going to come. --- Application Scenarios [N. Kawaguchi] Application areas of SAM issues large number of groups large number of members topology resource constraints (BW, latency, error) congestion control, scalability need application networks adhoc, sensor, home, office/building content video/audio, info sharing (whiteboard), sensor data also need to consider who will be communicating. human-human is normal, but there's some cases where it's machine-human, human-machine, or machine-machine. human will send data to machines in some cases. machine-machine coming in ubiquitous environment, such as for sensor systems. current apps skype - p2p audio/video conf skypecast - audio conf for 100 people p2pradio - radio streaming. e.g., www.streamerp2p.com video - kontiki sharecast - p2p streaming service xcast - explicit multicast - not an app, but a protocol. VIC and RAT currently used [showing video demo of xcast] multi-point application for IPv6 xcast includes all destinations in a single packet in forwarding flags routers dupe packet based on destinations, and modifies the forwarding flags. xcast gets away from global group management, works well for small group communication. [end video per irtf chair request] question: how small is group membership response: 30 people. question: can't this exceed MTU? Buford: this talk is supposed to focus on app scenarios, not on xcast. prefer to take xcast discussion offline, continue focusing on scenarios that drive applications. another wide demonstration. using nemo devices on tour de france bicycles to put webcams on them and transfer video and audio future application areas multicast in the ad-hoc environment. sam is required but not yet solved multicast over AODV, ODSR ad-hoc emergency networks to create infrastructure where it's been destroyed military sensor networks. based on ad-hoc networks, but current ones do not use multicast. SAM is another application area. MIT House_n environment. sensor networks for home environment. what about current SAM research? studies have not stabilized how can we r&d and deploy systems? need standardization of API for SAM too many algorithms and protocols for real world deployment, rich and high quality app is required should not depend on specific protocol example APIs scribe (pastry based p2p mcast relay cast sim tools p2psim mace overlay weaver in summary, we particularly need API standardization. ??: Looking at applications, and trying to consider requirements. Most of nodes in these are both sources and receivers. Are there cases where there will be a number of receivers moving around as well as sources? Kawaguchi: I don't have a feeling of the scale. ??: Do you believe that there's two solution sets for the two different scales of different sizes of receivers and hosts. Kawaguchi: I agree we may need multiple solutions for different types of hosts. ??: We had this problem in network multicast where we tried to have one model that met all needs. Protocols ended up getting fragmented by modes that were efficient for different classes of applications. Buford: Just to recap the point - is supporting different modalities good or bad in your view? ??: Generally bad. But if you need multiple and it's only two, you can swallow that. ??: We have not enough deployment of IP native multicast. In ad hoc networking environment, how can we say that we don't have enough IP native multicast? Buford: I don't think that's the argument. Suppose an ad hoc network env has one or more nodes also connected to a wider network. Can we do e2e, can we have an ad hoc network item that has a local mode technology also working? ??: This RG is going to include ad hoc network as part of agenda? Buford: Other people in IETF are working on this, but we want to track these and make sure our framework interoperates with them. --- Overview of requirements draft that was posted to the email list Requirements for SAM [Yuji Imai] p2p/alm/om system already exists video and audio (end system, skype) file sharing (gnutella, etc) necessary characteristics for some applications service connectivity cycle end user freely starts distributions when they want. mbone and ALM both have a lot of complexity. mbone gives multicast a bad reputation current p2p multicast has an advantage over the mbone in that it's self-organized this is much easier to manage than mbone. apps also solve bandwidth inflation issue. more reliable because it retransmits. overcomes multicast issues, but becomes ugly. showing graph of how windows update p2p approach wastes bandwidth on a day where a mandatory update was released concern about not being able to recover fairness and cooperativeness base requirements 1. multicast capability - 1:*, *:* 2. service-connectivity cycle 3. .... adaptivity requirements 4. fast routing convergence - catch up with unicast routing path changes 5. dynamic topo change - mobile/manet might be assumed 6. dynamics of group membership, necessary to assume changes in membership ??: Is there a requirement to changeover within 10 seconds based on our fast reroute requirements? Yuji: I can, based on applications. ??: Can you give me numbers based on different application types? Yuji: Yes, no time. Buford: To summarize, we need to capture numeric requirements based on application class. ??: Hope that WG can produce this set and give something to IETF to consider. Buford: We have draft 0, have very little feedback. One message is that quantative values need to be in requirements and we need to identify different apps to make requirements more specific. Yuji: Other comments are welcome too. ??: If you have N solutions at app layer and K at network layer, do we have a large number of combinations to test? Yuji: Yes, that's a reality. Falk: This is an IRTF RG. One way is to come up with point solutions and experiment with them, then reduce space of all possible solutions. In IETF you would want this more baked and option set reduced. In RG this can be less coordinated. ??: Depending on what you define as user, letting them pick type of multicast is a mistake. Who is architecting the service is acceptable. End user choice of a protocol is usually a train wreck. Mineweaser: Would you be opposed to end systems deciding to perform a function itself vs. relying on network? ??: From streaming perspective, a user choosing unicast or multicast stream isn't good. Fine if it's automated. ??: An example of what you're saying is like realaudio that tries multicast then falls back. Mineweaser: Also something where there's multiple ALM schemes then the system picks best in the area, or best for the group dynamics. --- Overview of GIG [Mineweaser] review of SAM RG charter purpose is to review because we haven't looked at it yet, then lead into GIG discussion charter look at improvements for multicast performance given a variety of parameters key design consideration in charter - not just a question of protocol to use but we're also looking at system as a whole, investigate where state is placed in the network, examine sensitivity of state explosion as properties of group, network, application. not necessary a right answer, not about transitioning towards global native multicast. NM isn't necessarily right answer in every case. interested in building framework which allows you to optimize placement of state information in the network. overarching goal to improve scalability. many of these across the board challenges apply to the DoD's Global Information Grid want to make sure people have a sense of what's behind some of the comments in the charter. want to make sure people are familiar with the GIG. this presentation is pretty modest and want to make main challenges clear. scope of gig scope of the GIG is all military services in the U.S. and several related agencies. doesn't include everything that is government. does not include state and local, law enforcement, emergency responders, etc. may eventually provider interfaces to some of these in the longer term. includes transport infrastructure, computing infrastructure, apps/services. includes data that transits the above. in RG we'll mostly be talking about transport network pieces of GIG are coming into place today, will be emerging over course of the next decade. appropriate to look at in terms of an IRTF RG because there's time to create new solutions that will be deployed when the needs are expected. GIG is global in range and reach, where it's located/ instantiated will vary in time depending on where network capability is needed. significant fraction of the network is mobile in several ways. some are handheld comms devices, some are integrated/imbedded in mobile platforms. how is this different from what's happened before? the benefit of having an overarching architecture will improve interoperability and increase capabilities. these two factors correlate closely to SAM RG, we'd like to see these same things happen with multicast in particular. we want to increase scalability of of the system, for them to switch which tech they are using as needs change or as group changes, etc. want to reduce footprint at the edge. simplicity is important, want to be flexible and not need special equipment everywhere. major programs (groups working on developing specific products) four key transport programs WIN-T: warfighter information network-tactical is a series of ground mobile systems TSAT: SATCOM system JTRS: wireless radios GIG-BE: terrestrial infrastructure other programs airplanes, ships, mobile vehicles that are reliant on the transport network systems had been designed with extensibility in mind. e.g., a radio might not immediately have mcast capability, but can be upgraded later on challenges ip convergence IA/network security mission-oriented ops and resource management transport performance in diverse/dynamic topologies IP convergence - in the past, an app was identified, and everything was delivered in a vertical integration fashion. separate networks were built to meet new requirements. lots of scalability and interop problems when there was a desire to interconnect apps. trend is to migrate towards a shared infrastructure. single resource pool where allocations can be performed at runtime as needs arise. GIG is a shared resource but not a general purpose of network. moving from stovepipes but the GIG is different from internet at large because the requirements are a union of the stovepipes, not an intersection of them. users want to retain optimized properties of their custom networks as they moved to a common shared resource. drives need for QoS capabilities and P&P. many networks will be resource constrained and we need to ensure that the most critical data will get through. ??: Newbie to GIG. Is that related to ...? Do you want to be able to search and lookup? Mineweaser: Search, discovery, and data management are part of GIG vision. Considered separately from the transport network. From programatic standpoint they're developed separately. key challenge for network architecture is to provide IA on the common network. path that has been selected here is "black core, red edge." common network is transmitting IP encrypted cyphertext datagrams. plaintext network only appears at the edge of the network near to the host. this complicates network management, quality of service, and multicast, particularly for schemes like ALM. black core topology is not visible to the application endpoints since it appears like a single point. running ALM in a network like this and doing so in a way that's optimized can be a challenge. interest in ALM/OM schemes, but they would have to be cognizant of having limited knowledge of significant parts of network topology. dynamic discovery requires that mobile nodes must find each other despite both of them moving. as we move to black core/red edge model, perimeter security becomes less and less effective. seeking out new schemes that allow security for multicast traffic and administrative insight into what's happening. if some old 'network services' move to 'user controlled systems' there are capacity and resource constraints. need to form internetworking relationships and build groups without prior arrangements. if mcast scheme requires advanced setups, it is likely to be of limited use to GIG applications. user may know that they are part of group X, but not who all is part of X. schemes that require everyone to know full membership may not be applicable. mission orientation. GIG is intended to achieve missions. competition between missions. economics based models on internet today is seen as a less prominent model than GIG. operating models which allow us to share resources and to provide policies that guide config and utilization of resources across network. point back to QoS and P&P mentioned earlier; example of how we want to do mission oriented resource management. differs from commercial model in that access is not based on paying an operator, based on overarching view of GIG resources at a time. an admin domain need not be self-sustaining. commercial systems constrained by individual components being economically self-sustaining; here we are free to design an architecture where components don't generate revenue since there's an overarching central control and authority. ??: do you believe that's really true that price doesn't matter? Mineweaser: To the extent I suggested it's no object, that's not the case, but it need not be a dominating factor. Willingness to recognize that some systems are a service to a community. ??: history on separate networks is two things - people want to either control and not let others use network and spend their money. Still had to allocate costs back out because if you don't it'll end up going fragmented like the design before. Mineweaser: I agree. transport performance has been covered for unicast much more than it's been covered for multicast. would be interested if this research group would look at the performance of multicast in the presence of dynamic topologies. networks with high delay*bandwidth, rates of mobility, and intermittent connectivity. in the past we saw for unicast in particular that performance was poor if you were trying to run in diverse/dynamic topologies, approach was often to provide middle boxes that would enhance performance, this worked when we were in stovepiped environment where we would match an enhancement technique to an application, and if it resulted in unfriendly behavior there were no friends to upset. as we move to shared environment, the old schemes no longer work so well. interesting new schemes that allow us to perform similar enhancements and lets us allocate resources in a way that meets objectives of centralized authority. there's a few cross-cutting issues. need for high security mechanisms and robustness to continue operations despite continued attacks, loss of nodes etc. multicast needs to recognize the role of security in op of protocol and the interactions between security with overhead and robustness. the resource management aspects should be prominently considered. a system which is highly efficient/scalable but not practical to manage is going to be an issue in the gig. whenever possible GIG wants automated management. maintain good performance over dynamic topologies without needing to change applications. a framework can be of use if we can design apps to a framework for multicast. can use various properties e.g., size of mtu, group size. then we can have a system that flexible. ??: In general, to what degree have you tried to evaluate best available technologies in industry for each components and make description of how well they mesh with technologies. How much have you looked at existing wheels? Mineweaser: We can talk about this specific kind of analysis as it relates to multicast and transport performance in future sessions. Steve Casner: Set of goals and requirements result in an empty set where you can't meet all of them. Mineweaser: Are there specific examples where you think there's major drivers towards an empty set? Steve Casner: Just speaking theoretically. Ability to combine these functions, include QoS, manage them, have cost not be infinite... Falk: Nobody said the cost's not going to be infinite. Mineweaser: Remains to be shown. It would be a valuable product to see how specific goals interact and if you want to be at endpoint on one goal you have to get performance of a lesser grade for other goals, and then have a framework that lets you trade how well different goals are met. Steve Wolf: Principal problem is trying to harmonize requirement for central control with distributed nature of most internet applications. Mineweaser: Yes. --- DMMP. [Lei] Xiaoming Fu: Describe why ALM is introduced. You want to do this kind of thing without needing full support from network multicast. Concerns that delay and bandwidth are not good for some users. Need some kind of scheme that allows you to interact in this way plug and play. Can compose multicast relying on infrastructure nodes such as in other proposals. DMMP gives a tradeoff between reliance on network and availability for end users. End users trying to say that you can select a small number of high capacity nodes to be core members. Mesh structure is subject to change over time. When membership leaves or the congestion situation changes you can dynamically exchange mesh information. Core is dynamic, and mesh is dynamic as well. You will choose alternative to make dynamic situation better. Distribution tree can be maintained in dynamic tree. last objective of proposal is to be reactive and resilient to network changes. If you have network/node failure, it should be self-healing. Overview of architectural framework. Requires centralized node to create mesh knowledge. A "super node" will in turn be formed when you have a number of receiver nodes. Super nodes are also end hosts. Initially you have some kind of mechanism that will later on patch super nodes to other end nodes, they are faces for the overlay infrastructure. Mesh maintained in control plane with overlay mesh maintainers and construction. Based on clusters of super nodes. Each represents a group of topology. Clusters are a subset of group. ??: Assuming that receivers are mobile, do mesh-based nodes follow them around, or do the nodes jump? Answer: This isn't intended to support mobility in the first place. You can switch on the multicast function and join the meeting. When you have network change or capacity change over time. Control function maintained by control messages. In data plane it's based on constructed overlay constructs based on control functions. Overlay mesh is chosen by using RSPF algorithm. Data plane f'n is available. Take metrics to maintain overlay mesh. First possible metric is bandwidth, others include latency for example. Super nodes have availability. Whenever you have a new session created, a super node should be created. Main purpose here is to see whether people here are interested in such a topic. As a research topic, we would like to see if this is anything of interest for the group or if you have some other group opinions. Can be a small group, but could be useful for multicast users in a plug and play way. RP end hosts are two types. Leaf and non-leaf nodes. Non-leaf nodes are placed in order of out-degree. Records of how end host involved in multicast can be arranged. Decides which should be super node. This structure poses a problem where there's a scalability concern if there's a large number of groups. assumptions DMMP is required in some selected nodes. source, RP, end hosts. each source node should have knowledge of RP. out-of-band channel. figure that shows dynamics of member join take a look at the slides online for detail and we would appreciate comments. identified several security threats. more investigation is necessary. open issues scalability/efficiency security nat/firewall traversal e2e qos ??: What's the driver? Is there anyone who would like to deploy this and can't do it otherwise? Is it research for the purpose of research? Would be a perfect fit for the information grid people. Placement of super nodes is the main component of creating an efficient distribution tree. If you assume knoweldge you can do this. X. Fu: The driver is a european project to take a piece of time looking at the issue concerning multicast. Some concerns with network layer multicast. ??: Where's the problem statement? X. Fu: We have an internal document. Identification of multicast solutions will be part of work inside SAM RG and we're happy to contribute. ??: Would be nice to show a problem statement up front. X. Fu: Useful to have common understanding. ??: I think research is good. Twist on it is what we get end users to do, not what we get engineers to do. We need to look at what people will actually implement or use. X. Fu: You say what's targeted user of work? ??: We've gotten multicast to work, but we haven't been able to overcome bureaucracy to get it going. --- [Buford] Spend a couple minutes talking about work plan. Dow Street has some slides on routing in the GIG, then we'll have open discussion. Work plan problem statement + scenarios requirements for SAM framework survey of ALM/OM/hybrid technologies and performance metrics spec of SAM framework spec of deployment scenarios meetings within IETF and at conferences that bring wider networking community together. We will have "P2P Multicasting" workshop at IEEE consumer comms and networking conference (IEEE CCNC 2007) in January 2007 in Las Vegas, following the Consumer Electronics Show. Also plan meetings at IETF 68 and another networking conference in 2007, venue TBD. www.samrg.org did a hands check on how many people would attend if there was a meeting at IETF 68, a number of people responded yes. Steve Casner: Do you anticipate that this group will move in workshop mode, or be 20-30 people in a smaller room hashing out things? Buford: In any group there's going to be a range of participation. Fine if we have 50-100 people in the room, there will be a core group of people who will be active. --- Dow Street: GIG Routing Requirements Some current IETF protocols do not solve all GIG problems. Analyzing what the problems are that aren't solved. Looking at 2015, so we have time to do research. 10^5 routers, 10^7 hosts. Sub-administrations within an overall authority. Lots of heterogeneity. Assuming IPv6 will be packet format. Don't want to preclude specific use of IPv6 destination address or semantics for IP multicast. Lots of RF and mobile nodes and mobile infrastructure. Impacts multicast in a number of ways. Lots of link intermittency. Intermittent links in trees have issues. Multicast senders, receivers, and RPs may be moving. Recently kicked off a study on IP multicast over dynamic topologies (not quite MANETs, but macro-mobile networks) We have seen multicast solutions for MANET, and for fixed, but our topology is a middle ground. nature of the routing commons - we don't have the problem of having a business case. we can tell everyone to turn on multicast. that said, because we have RF everywhere, we can't afford to unicast where we don't need to. Some parts of the DoD network today, multicast already makes up more than 60% of the network traffic. We extensively use IP multicast in its current form, but there's more things we need to do more. ??: What kind of traffic is that? Dow: Anycast multicast. Applications are mostly for situation awareness. Everyone wants everyone else to know what they're doing. Some single source multiple destinations is used for sensor data. very strong requirements for security. widespread use of IPsec gateways; we have a limited ability to communicate from end nodes to nodes within the network infrastructure. limits applicability over ALM, overlays. interested in group membership control because we need to be able to manage how network resources are used. as John mentioned earlier we'll be helping to describe these problems. some of the solutions for these problems are applicable in other networks, and that will be part of fleshing out the problem statement. ??: Regarding mobile RPs, how often do they move and how fast? Dow: We're looking at a topology where we have some control over where we want to initially establish RPs and what characteristics we want to take into account. ??: Have you considered using bidir PIM? Dow: Yes. ??: Have you looked into multicast IPsec like ???? Dow: We have limits of how much information can be transferred over IPsec boundary. ??: You're talking about HAIPE devices and e2e multicast. Something like security at edge and at core. Is there no need at all for e2e security. Dow: Let me talk with you offline. Open discussion. End of Meeting.