FUNCTIONALITY PROVIDED BY SYSTEMS FOR SYNCHRONOUS CONFERENCING

Carl von Loesch, 1992, 94, 97, 2003

ABSTRACT

CONTENTS

1.	Introduction
1.1		Synchronous conferencing? Huh?
1.2		Problems when dealing with conferencing systems
1.2.1			Growth
1.2.2			Network failures
1.2.3			Sociological and security aspects
2.	Functionality that conferencing protocols need to provide
2.1		Actual communication
2.1.1			User to user (one on one)
2.1.2			Group links
2.1.3			Broadcast channels
2.2		Automatic notification of arrival of friends
2.3		Directory services
2.3.1			Querying who's online from a certain area
2.3.2			Being "visible" within certain areas only
2.2.3			Contact boards (Meet new people)
2.4		Network level operations
2.4.1			Message tracing
2.4.2			Status information retrieval from network entities
2.4.3			Message rerouting
2.4.4			Automatic message rerouting
2.5		Other miscellaneous services
2.5.1			User directory services
2.5.2			Offline message storage systems
2.5.3			User-provided service robots
2.6		User interface requirements
3.	Outlook
4.	References
5.	Author's address



1.	INTRODUCTION
	~~~~~~~~~~~~

1.1		Synchronous conferencing? Huh?

        Computer work is requiring more and more electronical interaction between people and services. People need to talk. Sometimes it is just one small question, that is easier typed into a particular communication program, than to reach for the telephone, and will not necessarily disrupt the callee from important activity as a telephone would do. Electronic mail tends to be cumbersome for this type of needs: You get the spooling and notification delays. Also, when synchronizing on operations, it is far too often necessary to walk over to an other office just to exchange two sentences. In the end one gets tired of walking and goes on working without communication. In these cases I have seen synchronous conferencing improve cooperation greatly.

        One more good use of synchronous conferencing is the ability to set up a conference session across the world, which can't otherwise be done by telephone because of financial reasons. Research projects are already being coordinated through the networks with electronic mail and mailing lists, but most of them haven't discovered the advantages of synchronous conferencing, where electronic conferences can be held in real time, avoiding time loss with misunderstandings or unnecessary elaboration of topics when the synchronous dialogue clears up uncertainties quickly.

        Synchronous conferencing will also have a serious significance in the business world, not only in form of video conference, but also in form of plain text conferencing as it is the cheapest way to arrange a worldwide conference session, 24 hours every day.

        The internet protocol suite provides the good basis for this type of communication and the TCP/IP-based Internet Relay Chat system has established itself as the worldwide biggest international conferencing system, providing the best available structures for synchronous network conferencing. But it is reaching its limits and to free ourselves of its major weaknesses we need a totally new conferencing protocol.

1.2		Problems when dealing with conferencing systems

        Here I'll resume the problems that IRC has faced so far. See also {CNC}.

1.2.1			Growth

        IRC was not designed to deal with thousands of users over a worldwide network of hundreds of server nodes. The protocol broadcasts information about its user database worldwide to each IRC server which causes most of the actual traffic and network load. The database itself contains a lot of data that noone actually needs. Many people just want to talk locally with others at the same site or within the same country, and yet the data is sent worldwide. It should be possible to avoid distribution of data to areas, and yet being able to query this information in a more compact form from distant locations. It would take in-depth modifications to improve this aspect of IRC.

1.2.2			Network failures

        The internet protocol suite is implemented upon a miscellaneous set of network infrastructures in form of soft and hardware. IRC experience has taught us, that networks can be extremely stable but just as well extremely flaky, and of course they can be fast or slow, provide high or low bandwidth. And these characteristics can change dynamically. A link can be very bad for a few hours, then return to pristine service. That's faster than human administration is able to coordinate and adapt to. It is already difficult to find out which network link is misbehaving.

Although many patches have been applied, IRC is still incapable of adapting dynamically to its network. The problem here-in is first of all with the fact that IRC transmits its complete database to each node, and secondarily with the fact that the IRC network has a tree structure. When a link breaks all state data from the other side's network becomes invaluable and is thrown away. Should the link be reestablished, it will have to retransmit the complete database which is itself a huge network load and easily leads to yet another crash of the link. If the site is lucky it has a choice of network paths, so another link is likely to be tried out next.

Probably the likelihood of a network failure caused by the transmission of the database at network linkup causes the greatest load IRC produces for the Internet, certainly not the actual conversation people make. That's why it is clearly not a question of reducing the communication, but of improving the medium. [Update 1997: The IRC software and protocol have been improved to spool changes in state for a while until the network link is re-established.]

1.2.3			Sociological and security aspects

        Vastly underestimated was the rate at which sociological aspects influence the provided service. Against all assumptions, network communication tends to enhance emotional reactions in humans, probably because just "knowing" there's another human at the end of the line doesn't feel the same way as seeing this person physically. Many a useless broadcast message wouldn't have been typed if the person could have seen the annoyed reaction of hundreds or thousands of people receiving it.

        I will call the activity of people disturbing service "network vandalism" although the term is unfair, because it is not correct to judge a person superficially by its electronical actions. So I will consider it a technical aspect, a problem that simply comes with big networks. It just exists and needs to be taken care of. Conferencing protocols must provide the least possible platform for vandalism.

        IRC has seen vandalism both from administration and casual users, disrupting conversation on channels (conference group links), disrupting network links, attacking the protocol itself to achieve unpleasant results. IRC has been improved vastly in this field in the past years, but these problems persist. This is an aspect which must be carefully considered in the design of future protocols. [Update 2003: These problems had only just begun! IRC is still a hell of a battlefield today.]

2.	Details on Provided Functionality
	~~~~~~~ ~~ ~~~~~~~~ ~~~~~~~~~~~~~

2.1		Actual synchronous communication
2.1.1			User to user (one on one)

        Two people want to exchange messages, the most obvious type of network communication. They should be able to setup a window on their screen where everything they type shows up on the other one's screen without too much fuss. But experience has shown that communication might not necessarily like to be limited to plain text. People want to be able to exchange files, pictures, audio. They might want messages to be displayed in different fashions, usually to support atmospheric description of gesticulations, miming, emotions or activity, but also to merely satisfy esthetical needs or to be able to highlight words or lines. Now you might think this is "untechnical", but being able to provide human connotations in electronic conversation has proven necessary to give the conversation a human touch. Just look at the success of the smiley. :-) [Yes, smiley is the correct term. "emoticon" was invented later on and is a very bureaucratic word I'd say.]

        As video conferencing is on the rise, a new protocol should not necessarily provide the means, but be the medium to handle conference control while the actual data is transferred by an other medium. This principle is already being used by IRC clients: They arrange for direct client-to-client communications and file transfers via IRC.

2.1.2			Group links

        A group of people needs to communicate. This sounds simple but it is indeed quite complex, especially the administrative issues. How can people join or leave a group? Who's entitled to let people in or not? How can we ensure that these structures cannot be battered by "vandalism"? This is one of the most hairy aspects of network conferencing.

2.1.2.1				Lists

        In a list each member of the group has all the addresses of the other members and sends his message to all others, either directly or via a multi- cast medium. The list concept has not been used very much in the field of synchronous conferencing, although it is so straight-forward and likely to be the fastest.

2.1.2.2				Channels

        The channel distinguishes itself from the list by the fact that the group members are not specified with every message but sent to all involved transfer agents in advance, this implies that a multicast routing medium is available, like a network of IRC servers.

        To keep this layer flexible it was Stephen van der Berg's suggestion to include an interpreted command language into the transfer agents for a flexible definition of channel characteristics. (He is however better known for procmail these days.)

        But the problem of agents being tampered with and therefore not acting as they should would remain, therefore I have developed the more secure concept of channel programs. They are implemented in one place, or maybe two, and have full control over the channel. They handle people's requests to join a group and inform group members who's in and who's not. This allows for a minimalistic conference control approach as taken by the PSYC.

2.1.2.3				Broadcasts

        A traditional broadcast is a message delivered worldwide to all agents of a service. Broadcast channels are still useful for the purpose of news coverage, as the experiments with the '#report' channel during the gulf war have shown. Network radio is also being experimented with, although a non-multimedia news channel might find a bigger audience. Some issues receive so much netwide interest, it turns out cheaper to the network to simply broadcast these discussions instead of trying to handle huge lists of receivers.

        A slightly more evolved broadcast is one that can be limited in the area of distribution. But broadcasts can probably be completely replaced by proper multicasting, if that can be done with low overhead concerning routing.

2.2		Automatic notification of arrival of friends

        You should be able to leave notification requests pending so that you get automatically informed when a person you want to talk to shows up on the network. At the same time the right of privacy must be preserved. A way must be provided for the awaited person to enter the network without generating the notification message. The service therefore must work in mutual agreement.

2.3		Directory services

        While working, you may spontaneously find yourself in need to contact the programmer of a certain tool, or a specialist in some field, and then you would like to find out if this person is online at the moment, and if not, leave a message.

2.3.1			Querying who's online from a certain area

        A lot of user interests are geographically oriented. Some are only interested to people and things that are near, others care about certain regions, and some are limited by linguistic barriers.

Looking who's on from my site is one of the most common operations. And sometimes you want to find out who's on from Rome or Paris or NYC. IRC provides this info by matching its huge database with a hostmask. A kind of "grep" in unix-speak. This is very quick, but we can't afford this type of databases anymore, so the new service must perform in a way that the request travels to the areas and the local servers return appropriate information. But since that would mean to broadcast in that area, it needs to be actually done in a hierarchical way, vaguely similar to the domain name service system. Depending on the narrowness of the request more people's data might match as they might have requested a limited area of distribution of their data. So this would be provided by a distributed directory service, which we now understand as a logically hierarchical system, not necessarily in the actual implementation.

2.3.2			Being "visible" within certain areas only

        While today with IRC, there is only the option of being visible or invisible in other people's queries, and such invisibility doesn't reduce the network load but instead raises such, in a future SC scenario the user is expected to define the grade of visibility and actual distribution of his data across the network of directory services, with the default state of being visible only at his local site or within the town, which means that a distant request would have to ask for data from precisely that site to get to see his data. Now we could think of one step further, to distinguish between distribution grade and actual visibility grade. That is, the person now also is able to specify, that a distant request is granted his data only if the requesting user matches certain restrictions like network provenience.

2.3.3			Contact boards (Meet new people)

        A major design flaw of IRC is not to distinguish between requests about known and not known people. A lot of people don't want to get in contact with unknown others at all, and therefore don't need to be "known" in the databases worldwide, because when you know your talking partner you can obtain information about this person by direct communication to his site's SC service daemons. However having a database that allows for people to announce their willingness to communicate with as-yet-unknown others is a typical feature of chat systems which should still be provided, but it can definitely be provided in other ways than IRC does, for instance with a few centralised databases. In the same way as users announce their presence it must be possible to announce the availability of public conferencing groups (lists, broadcast channels). Again this means that the normal state of a group link (list, channel, hybrid of the two) is to be known to the parties communication ends only, or, in the case of broad- casting, to the distributing gateways.

2.3.4			Why have directory services?

        These are features that are expected to be provided by a directory service, which must also be completely independent from the other SC functionalities so that SC is viable also in isolated networks without any directory servers.

        [Update '94: Why have directory services on the SC level at all? Isn't it like re-inventing things we already have? If you manage to apply URLs to people and channels, then we already have a wonderful hyperlinked directory service called WWW. Also in E-Mails and in the News URLs can be advertised. So in that case the solution is to have places to register oneself to, where one can point an URL to. Then one can make a real nice directory service based on WWW, since the data now has become static. This is not the last word, but it solves a few problems.]

        [Update '97: PSYC doesn't provide a directory service.. it is not necessary for most situations. These days it's better to look for people using web search engines. LDAP or other directory services could be integrated into PSYC however, if necessary.]

2.4		Network level operations

        Talking about things you can do at a rather raw level, but not limited to administrators.

2.4.1			Message tracing

        Find out how a message travels from one point to another, which gateways it goes through if at all, how quick the lines are between the gateways etc. The equivalent to the traceroute utility on the SC message transfer layer.

2.4.2			Status information retrieval from network entities

        Find out how busy a gateway is, what routing policies it follows, what operating system a certain contact board server runs on, what time it is in Australia, how long a user has been idle. Whatever is useful could be available, each service entity (message protocol daemon, gateway, user client, contact board server, directory service, user-provided service)giving out the information it has.

The retrieval protocol should be independent in such a way that new options can easily be added. Not as with IRC where old servers would typically not forward unknown requests to newer servers, even if those do understand the requests. This reminds us of cleanely seperating the operation layers of SC service entities and setting up independent protocols for each different tasks independently. I'll get to that later.

2.4.3			Message rerouting

        I noticed one of the very advantages of Bitnet over Internet. On Bitnet you can tell your message daemon (usually called RSCS) to send your message along a certain list of gateways. Usually naming one would suffice to avoid the message getting stopped by a network failure somewhere on the standard route.

        Internet misses such an ability. Should the standard route to a site break down there is nothing you can do, although if you could make a specific other site forward the message it would arrive to destination. [Actually such a feature called IP-Source-Routing exists, but it is generally disabled in network routers because of security concerns.]

        Beginners at IRC can be surprised how it is sometimes possible to communicate with remote people although the direct network connection to them is no longer available. This is because IRC messages travel through the IRC tree and not direct links.

        The message transport layer gives us a chance to implement routable messages as we can decide where to forward the messages to. This helps working around network failures and incorrect network configurations. The new routing ability should be available to the user for flexibility, just the way Bitnet offers it.

2.4.4			Automatic message rerouting

        In general users will not want to mess with that however. So the normal case is for the message transport layer daemons to choose the optimal routing.

        Currently, with IRC, this option is only given to IRC admins, and only at a very unflexible level, as the choice of "optimal routing" is merely the choice of one appropriate other IRC server to link up to. But in a more modern concept, this "optimal routing" can be specified in form of routing tables which can be provided by admins and can optionally be overridden by the user's own. They will indicate choice of routing on a target-by-target basis.

2.5		Other miscellaneous services

        This is no synchronous conferencing anymore, but the IRC protocols just like the Bitnet MSG protocol have been used for these services which are closely related to SC.

2.5.1			User directory services

        What do you do when you decide you want to write a mail to a person that you talked to yesterday, but only remember the nickname of. A directory service would tell you the electronic mail address of all people who match that nickname and have entered this information into the directory. This type of service is available on IRC and used tempestively. [Update: NickServ has been taken down.]

        IRC experience teaches us that this type of directory service should not again be implemented as a centralized server. Should just that part of the Internet, where the directory server resides, get isolated from the rest, the complete service disappears. This is unfortunately very often the case of IRC's NickServ. So the new implementation is likely to be on a per-site basis, where each site has its user directory service.

        [Update'97: Once your PSYC client has learned about a person it would very probably have the option of asking this person's PSYC server for additional information like homepage URL or email address.]

        [Update 2003: Elaborate PSYC servers have the ability to forward messages by SMTP to their owners' mailboxes whenever they are absent. Therefore people from the chat world can send them email without actually exposing any mail addresses.]

2.5.2			Offline message storage systems

        When a person isn't there, ways must be provided to be able to leave a message to the person. It should not be necessary for the person to leave the SC software to get into another which writes up an electronic mail. The message then needs to be stored, again it should not be stored on an internet-wide central server, but probably at a site's central server instead, probably in conjection with the directory service. E-mail could not replace this functionality (by implementing sendmail abilities into the user's SC interface, the so-called "client") as the speed of SC is necessary just the same. The receiver might not be away at all, but actually "hide" from the public to be able to choose whom to respond to invisibly, which is actually a distortion of the intended use of the storage system because a 'forwarding' feature is used instead of actual storage. But hey, if the user likes it that way...

2.5.3			User-provided service robots

        People just seem to love setting up their own automatons providing for some more or less useful service, be it a joke server, a multi user card game or just a robot that pretends being human and talks silly. IRC has shown how many users like to experiment with this, so ways must be given for people to setup these robots without generating excessive network load and in a consistent way and optionally consistent with the other communication protocols available (the network entity query protocol for instance).

        Now hopefully the new protocol structure would reduce the overhead of robot communication, and the mere presence of the robot would be much less of a network load as it is with IRC now.

2.6		User interface requirements

        The needs of users have developed very complex interface software to the conferencing systems, at least the ircII program for unix platforms, a client to IRC, is that type of program you can call an operating system by itself. I'll list the typical abilities expected from a high-level user interface:

        Users want to be able to "react" automatically upon receipt of certain messages, being able to send automatic replies, to log the message, to ignore it or to have it displayed in a certain fashion in the appropriate window pertaining to that discussion. Some like graphic interfaces with menus and buttons while others want the command line editing and the commands at a keypress. File transfer {DCC}. Redirection of communication events to external programs. Output of system commands into the communication and much more. But the highest requirement is that these tools need to be totally configurable, both at compilation time and at runtime, and completely programmable by providing a programming language or being a host to a standard external language like Rexx. You can imagine it is not a trivial task to produce such a high-quality conferencing client software.

3.	OUTLOOK
	~~~~~~~

        Getting back to the original task, let me try to put in concrete form what layers and protocols we need. I have seperated many issues and given each a name, but that doesn't mean that in the process of implementation layers will fusion and names disappear.

First of all we need a rudimentary transport layer, that lets us send a set of bytes from one spot to another. IRC uses TCP. One could as well build something UDP based. Then there are several multicast implementations around, not just Multicast IP itself. And if you want to route into BITnet, then you'll have to use IUCV! The best choice is to have an independent interface to the actual network layers, first of all, and let implementors or even users and administrators select the proper network protocols to use. I call this the transport layer [TL]. [In the PSYC'97 architecture this is given by basic MMP.]

        Next we have a layer wherein to implement the distribution of messages, message transport layer [MTL]. That is trivial with point-to- point messages but it gets complex with one-to-many (multicast) messages. These can be of the list, channel and broadcast types. I once had a thought of implementing an interpreted message command language, which wraps itself around the actual message and gives the agents commands on how to deliver it. The advantage is flexibility, but probably that much is not needed. [In the PSYC'97 architecture multicasting can be provided by external protocols which are negotiated via MMP.]

        The message itself has a certain structure which describes what type of message it is and how it should be treated, contents description layer [CDL]. Any message has this in common. [In the PSYC'97 architecture this is the PSYC message format.]

        Next thing is the layer where we define how one joins or leaves lists, especially when the lists are not public, the list management layer [LML]. Also on that layer, but not necessarily with the same protocol, the way those channel definition messages are passed from transfer agent to transfer agent [CML]. Also the radio-type broadcast channels might need some steering layer [BCL]. [In the PSYC'97 architecture these aren't layers - they are (or will be) standardized object interfaces to address those types of objects.]

        And now to the point-to-point protocols. We have a user to user layer which takes a similar role like IRC's CTCP, [UUL]. The contact board layer describes how to make queries, what the replies look like and how to announce oneself etc. [CBL]. The event notification layer lets you know when friends show up, but it might aswell give you hints about network stability problems or similar [ENL]. To get technical info out of transfer agents we will talk some language which could turn out practical to be identical to the language with which we talk to services of any kind [SL]. However features like tracing the network require special treatment, on the transfer agent command layer [TACL]. [PSYC'97: again these are interfaces.]

        So I seem to have 3 layers. The transmission layer, the message transfer layer with its command language and the various protocols put on top of that. Maybe this will influence the development of PSYC. [Update'97: Hee hee. Yeah it did.]

4.	References
	~~~~~~~~~~

{PSYC}	http://psyc.pages.de: Homepage of the Protocol for SYnchronous Conferencing

{CNC}	RFC 1324: "A Discussion on Computer Network Conferencing"
	Darren Reed, May 92.

{IRC}	RFC 1459: "Internet Relay Chat Protocol"
	Jarkko Oikarinen, Darren Reed; May 93.

{CTCP}	"Client-To-Client Protocol",
	Klaus Zeuge (sojge@Minsk.DoCS.UU.SE); May 92.

{DCC}	"Direct Client Connection" (making use of CTCP),
	Troy Rollo (troy@plod.cbme.unsw.oz.au).


5.	Author's Address
	~~~~~~ ~ ~~~~~~~

	 Feel free to contribute suggestions and criticisms.

	 lynX (AT) psyc (DOT) pages (PERIOD) de