Minutes : SIMPLE : IETF 67 November 8, 2006 - Wednesday Afternoon I Chairs: Robert Sparks, Hisham Khartabil Notetakers: Dean Willis, Paul Kyzivat Summary: * All the known discusses with XCAP have been cleared and we expect the draft to be approved for publication shortly * The IMDN work will explicitly not address MSRP. Miguel will contribute text explaining that and the IMDN draft will be last called by the end of the year * The group agreed to continuing to pursue understanding the optimization of interdomain SIMPLE traffic as a working group item, producing one or more informational documents capturing and refining what we've learned so far. The home for any normative work will be discussed as the necessity for such work is identified. Raw notes follow ---------------------------------------------------------------------------- SIMPLE notes November 8, 2006 Chaired by Robert Sparks and Hisham Khartabil Notes recorded by Dean Willis Agenda accepted as presented. Topic: Status led by Robert Sparks Slides presented Where is XCAP? All discusses believed cleared and document is proceeding (JDR and Jon Peterson) Question: Can you summarize which documents in the list of things to do were not just reported on? Answer: IMDN, Advanced Messaging, optimization requirements, and the one big work item "Roadmap through the SIMPLE Specs". The currently proposed charter includes a milestone for closing. Topic: IMDN Led by Hisham Khartabil Slides presented Help requested verifying RelaxNG schema in document. Issue: IMDN routing in MSRP. IMDN-Record-Route and IMDN-Route header don't make much sense for MSRP. Should they be forbidden, noted as useless, or ignored. Ben Campbell noted that current intent is not to say anything. There may be interesting cases where an MSRP URI is resolved to a cluster of servers. Eric Burger noted that you probably don't want every relay examining every message -- they never actually care about what's in there. Miguel Angel Garcia-Martin suggests that IMDN should come back on the established session rather than trying to follow a record-route. They just don't make sense here. Ben asks if the only use case for IMDN in MSRP is "read reports". Hisham thinks that perhaps processing reports might apply in a cross-session model. Ben believes that cross-session is completely underspecified. When there are multiple MSRP session legs, problems can occur. Aki suggests that we simply abandon all of IMDN for MSRP and use it only for page mode. Eric noted that he didn't even think about MSRP when considering IMDN, but noted that the user interface might well not differentiate between MSRP and MESSAGE. He suggests that we say "MUST ignore when used with MSRP" Miguel argues that we need to reconsider whether IMDN makes sense with MSRP. Ben proposes that we simply do not address MSRP in the IMDN work. Hisham proposes deletion of the material. Eric proposes a statement like "IMDN is not currently applicable to MSRP" be added to the document. Miguel suggests extending this to say that this is based on the lack of use cases, and will provide text to Hisham (TODO: Miguel to provide text). Issue 2: In-Progress State OMA would like progress indications. Eric suggested that progress indications are NOT useful for MESSAGE but might be for MSRP. Robert noted that "put more one thing in" is not appropriate at this stage of life. Ben echoes the sentiment. Hisham things that an "in progress" indicator could be added easily, but percentage indicators would be hard. Miguel proposed withdrawing the requirement, and the chair noted consensus on this proposal. Conclusion: Hisham believes this document will be ready for WGLC after the next rev. Robert hopes WGLC will complete by end-of-year. Topic: SIMPLE Problem Statement led by Avshalom Houri Slides presented Noted by Henning that the assumptions bear more analysis, especially the bundling of subscribers in one domain. Jonathan Rosenberg observed that this is going to be a big problem indepenedent of protocol. Robert Sparks asserted interest in determining the floor of possible the optimization. Discussion of load-distribution and peak hours followed. It was noted that there might be "rush hours" especially around business users and presence changes. Suggested that we add the number of bytes to the load numbers. Noted by Hisham that the number of subscriptions might vary, but that the number of notifications (assuming comparable changes basis) shoud be independent of protocols. Ben Campbell asked about the source of the estimate numbers. Avshalom responded that they are a combination of best-effort guesses and estimates from current carriers. Ben noted that getting better data here would be useful. Henning noted that it is not just important to look at the raw numbers, but at the relative impact of changes and improvements, which would be expected to impact performance in a consistent way even if the base number estimates are wrong. WRT to "State Sizes" slide, it is unclear how the terminology used matches up to standard SIMPLE terminology. Noted that the state size numbers don't imply that all the state is on one machine. Also noted by Henning that the state sizes of "freebie" services haven't seem to have affected the deployment of those services. Cullen reports that he seems to recall having heard from large operators that SIMPLE seems to be less efficient than their current protocols, so they are curious to get some feedback on optimizations. Issue: Groups Explosion slide Henning wondered about the "oops" effect of accidentally subscribing to a large exploder list and how to recover. Once the notify storm starts, can we stop it before it gets done by itself? This probably drives concerns into the list-exploder work. Discussion of exactly what is optimized in the interdomain subscription model appears to be unclear in the document. Discussion of his subject continued for several minutes. Jonathan restates argument as "RLS make big lists possible, and without them, we couldn't get big enough lists to have these problems". Henry wondered if additional traffic from advertising-sponosred sites will aggravate the model. Issue: The ?s Slides, What is Missing? Discussion postponed to close of meeting. Topic: SIMPLE Presence traffic Optimization and Scalability led by Henning Schulzrinne Slides presented Issue: common NOTIFY for multiple watchers (slide) Question (from Mohammed Vakil) ? Why don't we have a single interdomain subscription? It has to do with the management of privacy policy and interdomain trust. There may even be entirely different ways of representing privacy policy. Some optimizations may require unification of policy or a new language for distributing policy as well as trust agreements. Issue: Batched Notify (slide) Several questions raised about aggregation technique. Issue: Timed Presence (slide) Suggested by Brian Rosen that this is really a new user interface mechanism, not a protocol mechanism, and we may not be able to evaluate its utility here. Issue: On-Demand Presence (slide) Noted by JDR that we have a protocol mechanism to do this -- perhaps we should be re-assessing the user requirements here. But we shoud be mandating a change to the user interface in order to optimize the protocol. Brian Rosen noted that one could get much of this by having the source domain continue to collect data, but that it might could be delivered to domain B only on demand. Aki noted that we may be looking at one protocol between the user and its RLS than between the domains. Issue: Adaptive NOTIFY rate (slide) Aki noted that this topic was covered by an older draft of his that may be expired, and that there are a large number of criteria based on which one might do rate adaptation. Topic: General Questions About Optmization and What Should WG Do? led by Robert Sparks Do we have enough of a grasp on this topic to take on a working group document that would be informational about the opportunities and techniques? Do we have any urgency for prescriptive changes? Comment by Hisham Khartabil: We have big numbers, but we have no way of comparing them to any existing system. So we don't really know what the expectations for optimization. Not sure this could ever be an RFC. Comment by Brian Rosen: This work is useful, and we should try and consolidate the various views. It may be that we need a heavily-optiized new protocol between domains that manages the privacy issues. Comment by Jonathan Rosenberg: Don't see any reason why this couldn't become an informational RFC. The numerical analysis and modeling, enumeration of techniques (including UI tricks), and requirements for new mechanism work all need to be done. These could be done as one document or multiple documents. However, if we do protocol work, it might impact the schedueld closure in July. Comment by Paul Kyzivat: Unless we get this stuff sorted out, SIMPLE will not be a widely deployed protocol. A key aspect is that SIMPLE is a richer system than the current generation, and we also need to understand the impact of this richness. Comment by Jon Peterson: Important for this to go forward. The charter problem is not a show-stopper, and it might be possible to migrate some of this work to SPEERMINT. Wouldn't want to get hung up on whether SIMPLE should do the work. Comment by Jonathan Rosenberg: A lot of these techniques are also applicable within a domain, especially a large multi-server domain. Comment by Henning Schulzrinne: Concern that we seem to be latching onto aggregation, and this only really helps when there are a small number of carriers and not a large number of small domains with little requirement for aggregation. Comment by Jonathan Rosenberg: It seems to be the large domains that are bringing these requirements to the WG. Comment by Keith Drage: This discussion indicates exactly why we should produce a document. And once the concepts are identified, we can discuss where we'll take the work. Question by Harald Alvestrand: Are we talking about 50 domains or 50,000? Response by Henning: Depends really on the inter-connectivty of watcher relationships between domains. Henning explained several different scenarios where the aggregation might and might not help. Comment by Harald: In the case of 50 million domains, you get the problem of making 50 million associations. This is analogous to the routing problem, and poses another aggregation model. This requires further analysis. Comment by Andrew Allen: Average users tend to be less diversely connected than IETF workers. Henning responded that the current trend is towards more and smaller domains. Jonathan went on with this to explain that the link density problem scales differently than we might think (a domain would seldom have more links than the number o users, and never more than the number of buddies of users in the domain), but Harald explained that the problem is aggravated for large domains, since they end up having to have links to all the small domains. Chair polled room, and noted no objections on adopting some of this work within the WG. Meeting terminated. ----------------------------------------------------------------------------- Notes from SIMPLE WG, IETF-67, Nov 8, 2006. Scribe: Paul Kyzivat Status of WG work items: - Xcap [ED: draft-ietf-simple-xcap-12 I believe]: Jonathan Rosenberg said that all discusses by IESG cleared last week. Should go to RFC Editor for publication shortly. - IMDN, advanced messaging requirements, optimization requirements, SIMPLE roadmap are all work yet to be completed. - July 07 is target for WG termination. Status report on IMDN (draft-ietf-simple-imdn-01) changes and issues by Hisham Khartabil: - Issue about use of IMDN-Record_route with MSRP. Ben Campbell and Eric Burger questioned whether this is relevant, seem to concur with Hisham that not relevant. Someone raised some potential issues when there is an intermediate server, like a mixer. Question was raised by Ben and Aki Niemi if IMDN should apply to MSRP at all. Eric suggested that IMDN messages should be explicitly ignored when using MSRP because they might be inadvertently included. Miguel Garcia disagreed with ignoring IMDN messages that might be included. Ben proposed not addressing MSRP at all in the IMDN specification, because doing so could get complicated and isn't currently adequately addressed. Eric was reluctant to omit all reference, and instead proposed some non-normative language & a non-applicability statement. There was rough consensus on the latter. Miguel Garcia will write a paragraph for Hisham to incorporate. - Another issue raised - should an in-progress state be added? The request came from Miguel Garcia. After discussion, Miguel concurred with not doing it. - The draft is expected to be ready for WGLC after a couple of small changes. No objections were raised. Avshalom Houri led discussion of draft-rang-simple-problem-statement-01 regarding performance and optimization of SIMPLE based presence systems: - Henning Schulzrinne questioned the conclusions & thinks they are highly dependent on assumptions that aren't known. - Jonathan Rosenberg comments that the statistics in the draft say a lot, that the numbers are very big and the optimizations provide little benefit. Some realization that his may just be the inherent cost of this service. - Miguel Garcia and Hisham Khartabil expressed interest in the quantity of notifications and bytes they transmit. Ben Campbell asked about the assumptions. Discussion & recognition that the assumptions will vary based on the user community. Henning said he is trying to gather some of this info. - There was much discussion of how very large the numbers look, and the significance of this, with no conclusions. It was noted that there are existence proofs of large presence/IM systems, but there was disagreement whether the complexity is comparable. - Explosion of groups raised as a big scaling issue. Henning questioned what to do if you subscribed to an unexpectedly big list and start to get lots of notifications. (How can the subscriber avoid being overwhelmed with notifications?) After discussion this didn't seem a problem. There was some disagreement about how resource lists are used: do I usually subscribe to an RLS in my own domain, or in the domain where the members of that list reside. (The draft assumes the latter, but many questioned the reasonableness of this assumption.) Henning Schulzrinne presented a study on SIMPLE Presence Traffic Optimization and Server Scalability: - New draft, missed the submission deadline for the meeting. Will be submitted shortly. - NOTIFY messages dominate traffic, so the study focuses on that. Henning explained several optimizations that were considered. One was about time based status updates. (Brian questioned whether that would help much and whether we know enough to do it.) Another optimization considered is a recognition that on-demand presence polling is an available alternative to a sustained subscription. - Aki Neimi noted that we may require a different protocol for interdomain presence than for intra-domain. Group discussion about the Problem-Statement draft and the Traffic Study - whether group wants to work on this subject: - Hisham Khartabil suggested we need real numbers for existing systems to compare with. He agreed we should probably adopt the analysis work, though it won't become an RFC. - Brian agreed this is a worthwhile work that needs to be taken on. - A question was raised about the appropriateness of starting this work when the SIMPLE WG is planned to end. Jon Peterson said not to worry about that & SIMPLE could continue, or it might be appropriate for SPEERMINT to take the work. - There was further discussion about how this scales based on the size and number of domains and the number of users in them. Not a lot of understanding. Harald Alvestrand related this to a routing problem. - The group hummed in favor of requesting that this optimization work be added to the charter. }