Next: Multiple Source Ordering
Addressing reordering of messages from a single source first; there are many
possible schemes, almost all of which require a sequence number or a
timestamp. A few examples are:
- Ignore the problem. A suitable example is for session messages
reporting presence in a conference.
- Deal with messages immediately. Discard any packets that are older
than the latest seen. Quite a number of applications may be able to operate
effectively in the manner. However, some networks can cause very severe
reordering, and it is questionable as to whether this is desirable.
- Using the timestamp in a message and the local clock, estimate the
perceived delay from the packet being sourced that allows (say) 90% of
packets to arrive. When a packet arrives out of order, buffer it for this
delay minus the perceived trip time to give the missing packet(s) time to
arrive. If a packet arrives after this timeout, discard it. A similar
adaptive playout buffer is used in vat for removal of audio jitter. This is
useful where ordering of requests is necessary and where packet loss can be
tolerated, but where delay should be bounded.
- Similar to above, specify a fixed maximum delay above minimum perceived
trip time, before deciding that a packet really has been lost. If a packet
arrives after this time, discard it.
- A combination of  and . Some delay patterns may be so
odd that they upset the running estimate in . Many conference control
functions fall into this category, i.e. time bounded, but tolerant of loss.
- Use a sliding window protocol with retransmissions as used in TCP.
Only useful where loss cannot be tolerated, and where delay can be unbounded.
Very tightly coupled conferences may fall into this category, but will be
very intolerant to failure. Should probably only be used along with
application level timeouts in the transmitting application.
It should be noted that all except  require state to be held in a
receiver for every source. As not every message from a particular source
will be received at a particular receiver due to CCCP's multiple destination
group model, receiver based mechanisms requiring knowing whether a packet
has been lost will not work unless the source and receiver use a different
sequence space for every (source, destination group) pair. If we wish to
avoid this (and I think we usually do!), we must use mechanisms that do not
require knowing whether a packet has been lost.
Thus the above list of mechanisms becomes:
- Have CCCP ignore the problem. Let the application sort it out.
- Have CCCP deal pass messages to the application immediately. Discard
any packets that are older than the latest seen.
- As above, estimate the perceived delay within which (say) 90% of
packets a particular source arrive, but delay all packets from this
source by the perceived delay minus the perceived trip time.
- As above, calculate the minimum perceived trip time. Add a fixed
delay to this, and buffer all packets for this time minus their perceived
- A combination of  and , buffering all packets by the
smaller of the two amounts.
- Explicitly ack every packet. Do not use a sliding window.
Note that just because CCCP cannot provide more elaborate mechanisms, this
does not mean an application itself (with some semantic knowledge) cannot
build a more elaborate mechanism on top of any of ... However it does
mean that message timestamps and sequence numbers must be available at
the application level.
Next: Multiple Source Ordering