DCON BOF meeting minutes

Chairs: Brian Rosen [BR] & Simon Romano [SR]

Minutes by Simon Romano, based on Meetecho recordings (see below) 

DCON BOF session at IETF 82 can also be viewed in the form of a recording with synchronized video, audio, slides and jabber chat. To access such material, please go to the following URL: http://ietf82.conf.meetecho.com/index.php/Recorded_Sessions

- Intro by the chairs

http://recordings.conf.meetecho.com/Recordings/watch.jsp?recording=dcon_bof&chapter=part_0

[BR]: Agenda bashing. Just a quick introduction to the two session presentations: (i) Distributed Conferencing background and problem space description; (ii) DCON feasibility analysis.

[SR]: DCON background. A solution for the construction of a scalable conferencing framework, made of a number of interoperating conferencing islands, with each such island being 100% backward-compatible with the standard XCON architecture. Work in DCON should hence concern the definition of a mechanisms for spreading information among such islands and having them be synchronized in a seamless fashion.
Strict liaisons exist with other IETF WGs, XCON and mediactrl being the closest ones.
A lot of work already done (see feasibility analysis in the next presentation), but a number of issues still have to be dealt with. Some material is already available as a starting point, with special reference to the identification of DCON requirements. 
We clearly need solutions at the media level, as also remarked on the mailing list by Alan Johnston.

[Spencer Dawkins] I liked what I have seen so far. At a high level I really think you guys are going in the right direction.

[Hadriel Kaplan] Normally we need these things in the IETF.  Interoperability is needed, especially when there are multiple vendors involved. You talk about iteroperability among multiple "XCONs". Do you expect this to happen among multiple vendors?

[BR]: If you want to make big conferences, you'll probably end up with multiple vendors. There are lots of different models, also with respect to moderation (centralized vs distributed controllers).

[Jonathan Lennox]: Do you envision this as actually being interdomain? Having the servers be under different administrative domains definitely makes things much more difficult.
[BR & SR] We think so. DCON might be interdomain.
[BR] Anyhow, an excellent question to bring up when we talk about the charter.
[Cullen Jennings] I like the ideas that are going around. I know that dealing with the media plane is complicated, but I nonetheless believe we should not skip this part. Things like, e.g., how we can chain together different mixers belonging to different conferencing islands are definitely challenging.
[BR] That was one of the items that Simon brought up, actually.
[Jorg Ott] One question on the term "distributed": do you envision an architecture where all the nodes are equal", or do you see some kind of hierarchycal substructure in those entities?
[SR] Up till now we made the hypothesis that we have an overlay made of just two layers. At the higher layer you have focus peering entities; at the lower layer you have the other standard XCON entities. But we are totally open to discussion with respect to this point.
[Jorg Ott] One more question: focus discovery. I think that finding things in the envisaged environment has a completely different scope when compared to managing a conference. I'm not sure these two things can be easily taken up in the same scope.
[BR] I don't think we're trying to get crazy here; we're just recognizing that there needs to be "some" solution to that and this does not need to be fancy.
[SR] When we made the feasibility study we assumed that the distributed focus elements get in contact just because they manage users that know each other (e.g. because they are "buddies" in an IM-like setup).
[Alan Johnston] This is a real problem, worth solving. It would be useful to come up with protocols for this. I do like the high level approach that is being proposed and I strongly agree with Cullen that we need to figure out what part of the media plane is doable.
- Feasibility analysis
http://recordings.conf.meetecho.com/Recordings/watch.jsp?recording=dcon_bof&chapter=part_1
[SR] Results of a preliminary study carried out at the University of Napoli and aimed at demontrating the effectiveness of the distribution approach proposed in DCON. Focus on scalability. Proof of concept implementation based on the Meetecho architecture. Conference events distribution and conference focus orchestration realized through XMPP-based communication at the upper layer. Figures show that distribution can bring to a huge imporvement in the capability of the overall system to scale. Other potential topics of interest include load balancing, resiliency and federation. These are not necessarily in the charter, but might be worth discussing.
- Charter text discussion
http://recordings.conf.meetecho.com/Recordings/watch.jsp?recording=dcon_bof&chapter=part_2
[BR] The charter itself circulated both on the DISPATCH and the DCON mailing lists. Let's now focus on the scope. Does the charter address all (and just) the things that need to be taken into account?
[Jorg Ott] What does "scalable" mean (first line of the charter text).
[BR] That's a reasonable comment, i.e., in what order of magnitude are we trying to scale", right?
[SR] The idea is that we should be able to keep the pace of load increases by adding new "islands" upon necessity.
[BR...arguing with his co-chair :-)] If we go for a hierarchycal approach (especially a two-level one) we do have limits on how scalable we can be. 
[Jorg Ott] Right. We need to have some reference value allowing us to say that, at some point in time, we have achieved the WG's objectives.
[BR] So, a reasonable thing would be to add a sentence indicating the range of figures we deem satisfactory with respect to the scalability properties of a DCON system.
[Gonzalo Camarillo] You may want to use as a benchmark not the overall number of users, but rather the capacity of the involved conference servers.
[BR] Sure. So I think we'll work this out on the list and address the general comment "how scalable are we going to be".
[SR] Just to clarify: I talked about a two-level hierarchy, but nothing prevents us from thinking of more than two levels, if needed. The architecture itself, from the protocol standpoint, is completely agnostic eith respect to the number of levels in the hierarchy. This said, I'm obviously in favor of adopting the benchmarking approach proposed by Gonzalo.
[BR] With my chair hat on, I would say that if we state in the charter that we go for two layers, it is better to just stick to two layers. If needed, we can always re-charter and do more work.
[Jonathan Lennox] Are you making any assumption about the topology of the DCON infrastructure?
[SR] The basic assumption is tha XCON uses a star topology for what concerns signalling (the media path is independent of this). With DCON we're not prescribing any specific topology. You can actually go for a full mesh, for a DHT ring, or whatever.
[Alan Johnston] I agree that your number of about a hundred thousand entities involved sounds reasonable. With respect to the charter text, we definitely need to craft a couple of sentences dealing with the media discussion we had.
[Spencer Dawkins] I guess that the most important issue we can have if we go beyond the two-level hierarchy is related to its potential impact on discovery. If that's the case, you might want to have that conversation as part of the discussion. 
[BR] I don't think this can be a problem.
[SR] As an indivdual, if I already had to choose a technical solution for this, I would definitely go for XMPP, which provides you with built-in discovery functionality (thanks to the automatic instantiation of server-to-server channels).
[Jonathan Lennox] Clearly this naive way of looking at discovery wouldn't work easily from an administrative point of view (i.e., in case the different islands are managed by different administrative domains).
[BR] I think you're right. We probably need to have some charter clarity on what we call "discovery".
[SR] Jonathan, would you be willing to contribute to this?
[Jonathan Lennox] Personally I would be open to this. It depends on ???? (I'm not able to understand this part, sorry :-( )
[Cullen Jennings] About media again. One question is whether the participants in different sites receive roughly the same media.
[BR] Can you send some text?  
[Cullen Jennings] I'm not complicating the problem by bringing this up. I just think this needs to be taken into account. The charter should state wheter different participants are going to get different media, or they are all receiving the same media (which, in my view, makes things quite more complicated). I'm not sending any text, since I'm chairing a WG which is managing a huge number of e-mails right now :-).
[BR] Can I ask you your personal opinion?
[Cullen Jennings] I think we should say that having the same media for all users is a goal we have just in the optimal situation. Otherwise, we can fall back to less stringent requirements.
[SR] Actually this is the same issue we have in XCON. I would say that in the most open case, where, e.g., you have no moderation, you can try and let all users receive the same media. Anyhow, this is a complicated issue and we are aware of it.
[Cullen Jennings] Agreed. And I'll be happy to have Brian and you write some charter text covering this :-).
- Deliverables:
[SR] I have to apologize. I forgot to mention the (obviously needed) Requirements draft, in the list of deliverables.
[Robert Sparks] Do the words "no new protocol" appear in the carter text?
[Cullen Jennings] I think XDSP (XCON DCON Synchronization Protocol) does represent in all respects a new protocol.
[Robert Sparks] There were comments that there are things out of scope since you were going to reuse existing protocols. Making those things that are out of scope more ecplicit would probably be beneficial.
[Jonathan Lennox] I don't think "synchronization" is the right term here, since the current name seems to assume that you have these two things (XCON and DCON) and you need to synchronize them. This in not actually what you seem to have in mind, since what we have to do is to use the DCON framework as a means to synchronize distributed XCON islands.
[SR] You're definitely right. We'll have to clarify this. We should highlight the fact that we are going for a DCON-enabling protocol.
[Jorg Ott] Do you have some term on concurrent operations and how you're going to solve conflicting ones?
[SR] There's nothing related to this currently in the charter, but this is definitely something we should look after.
[BR] Exactly. We'll have to add something about these timing conflicts.
[BR] I'm going to get to a couple of issues, by taking hums from the room.
1. Is this something that is worth doing in the IETF?
2. Is there enough energy to be devoted to thid in the community?
So, point 1., call for hums --> I would say that there's a strong consensus for doing it with a notable number of people who thought we should not do it.
Point 2., call for hums "If we're going to do something, should this be within the IETF?" --> I would say stron consensus.
Now a show of hands of those who think they will have time and are willing to contribute to the WG activities (without recording names) --> I see about 6 people, not a large number. 
Finally, people who are willing to review documents and participate in the mailing list --> around 15.
That's all folks!

Thanks to everybody,
Simon