page 2  (29 pages)
to previous section1
3to next section

2.2 Group Communication

A connection manager is as likely to perform a group transaction as it is a point-to-point one. Therefore, CCP requires a group interface to the transaction service, where a list of participants are sent the same message simultaneously from CCP's perspective. Depending on the capabilities of the transport, the client either multicasts the request [6] or simulates group multicast by using sequential interaction with each remote peer. For the latter case, it is suggested, but not required, that the transport service allow multiple transactions to be outstanding at once in order to parallelize group communication. A group interface also exists to convey to CCP the outcome of a group transaction.

2.3 Transport Reliability

To ensure reliability within a datagram framework, the client uses a combination of sequence numbers, timeouts and retransmissions. Each message is marked with a unique 32-bit sequence number, or seqno. If a remote server does not respond to the request after a given timeout period, the client resends the request; it will retry sending the request some number of times before giving up altogether. Timeout duration should be long enough to avoid unnecessary resends which lead to excess traffic, but short enough not to waste time in the event that the original request was actually lost in transit.

The seqno is specific to a particular pair of connection managers, and differs depending on which connection manager was the source of the message. It is incremented each time a message is sent. For the duration of a connection, the transport knows it must only ever receive increasing sequence numbers (until integer wrap around) from a particular site. The seqno in a request message is considered the starting point for synchronization between peer connection managers. During a conference, if a larger than expected sequence number is received with a valid request message, it means there was a temporary loss of communication where requests could not get through; in this case, the transport resynchronizes the sequence numbers between the two peers, by automatically moving the expected seqno value ahead to the new seqno.

2.4 Operating Environment Variability

2.4.1 WAN Operation

An appropriate timeout length is difficult to predict over as varied and dynamic a community of networks as the Internet. Therefore, timeouts are dynamically adjusted on a site-by-site basis. These timeout values are regularly updated, as is done for TCP [2, 8, 9], to reflect the expected roundtrip time (RTT) for a packet between two connection managers. RTT is useful not only for the transport level timeout approximation, but also for media synchronization. A connection manager conveys RTT information to its media agents for the synchronization of data flows [7] that travel over different routes between source and destination.

2.4.2 Variability Due to Heterogeneity

Timeout assignment is further complicated by the fact that other delays figure into the complete timeout computation. In other words, the RTT or base timeout is only used in those instances where the request-reply sequence is virtually instantaneous. These are cases where the reply is generated either immediately on receipt of a request, or after a very short time. However, in other cases request execution time may vary. For example, during connection establishment there are activities that prolong a conferee's reply, e.g., a remote site is configured to use a different video codec than the conference initiator site and coordination to switch the remote codec to match the originator's selection may take several seconds.

For requests that require lengthy activity before issuing a response, the request-reply pair is broken into two components; we refer to this as a two-tier acknowledgment scheme, which has been used successfully in [10]. When a request is sent to a remote connection manager, unless the reply will be nearly instantaneous, the recipient sends an immediate acknowledgment (ACK) of receipt back to the sender. The recipient sends a full-fledged reply once the result of the request is learned. Figure 2-1 contrasts these approaches.