U.S. patent application number 11/739171 was filed with the patent office on 2007-08-23 for reliable delivery of multi-cast conferencing data.
This patent application is currently assigned to Microsoft Corporation. Invention is credited to Lon-Chan Chu, Leonard Alan Collins, Yikang Xu.
Application Number | 20070198737 11/739171 |
Document ID | / |
Family ID | 33029780 |
Filed Date | 2007-08-23 |
United States Patent
Application |
20070198737 |
Kind Code |
A1 |
Xu; Yikang ; et al. |
August 23, 2007 |
Reliable Delivery of Multi-Cast Conferencing Data
Abstract
Conferencing data is reliably delivered to computer systems
participating in a hierarchically arranged multi-cast conferencing
session. When a child computer system does not receive a multi-cast
packet (e.g., an IP multi-cast packet), the child computer system
sends a negative acknowledgment to a parent computer system. In
response, the parent computer system re-transmits conferencing data
that was contained in the multi-cast packet to the child computer
system. Conferencing data can be re-transmitted to the child
computer system via uni-cast (e.g., TCP). Accordingly, conferencing
data that is not received or that is damaged via multi-cast can be
repaired via uni-cast. Computer systems can join an existing
multi-cast conference session without having to communicate with
the root computer system. The root computer system adjusts a
multi-cast send rate to compensate for changed network
conditions.
Inventors: |
Xu; Yikang; (Redmond,
WA) ; Collins; Leonard Alan; (Carnation, WA) ;
Chu; Lon-Chan; (Bellevue, WA) |
Correspondence
Address: |
MICROSOFT CORPORATION
ONE MICROSOFT WAY
REDMOND
WA
98052-6399
US
|
Assignee: |
Microsoft Corporation
Redmond
WA
|
Family ID: |
33029780 |
Appl. No.: |
11/739171 |
Filed: |
April 24, 2007 |
Related U.S. Patent Documents
|
|
|
|
|
|
Application
Number |
Filing Date |
Patent Number |
|
|
10436613 |
May 13, 2003 |
|
|
|
11739171 |
Apr 24, 2007 |
|
|
|
Current U.S.
Class: |
709/230 |
Current CPC
Class: |
H04L 12/1822 20130101;
H04L 12/1868 20130101 |
Class at
Publication: |
709/230 |
International
Class: |
G06F 15/16 20060101
G06F015/16 |
Claims
1. In a hierarchically arranged multi-cast conferencing session
including at least a parent computer system and one or more child
computer systems, the parent computer system having a receive
buffer and being network connectable to the one or more child
computer systems, the parent computer system being configured to
flush conferencing data from the receive buffer after receiving an
acknowledgment of reception of the conferencing data from each of
the one or more child computer systems, a method for the parent
computer system to repair conferencing data that was not
sufficiently received by at least one child computer system, the
method comprising: an act of accessing a multi-cast packet
containing conferencing data for the multi-cast conference session,
the multi-cast packet originally being multi-cast by a root
computer system for delivery to other computer systems
participating in the multi-cast conferencing session; an act of
storing the conferencing data in the receive buffer; an act of
detecting that a child computer system did not sufficiently receive
the multi-cast packet; an act of identifying a delivery mechanism
for re-transmitting the stored conferencing data to the child
computer system, based at least on the parent computer system's
position in the multi-cast conferencing session; and an act of
re-transmitting the stored conferencing data to the child computer
system in accordance with the identified delivery mechanism.
2. The method as recited in claim 1, wherein the act of detecting
that a child computer system did not sufficiently receive the
multi-cast packet comprises an act detecting that the child
computer system did not receive the multi-cast packet.
3. The method as recited in claim 1, wherein the act of detecting
that a child computer system did not sufficiently receive the
multi-cast packet comprises an act of receiving a bit map that
indicates a packet containing the conferencing data was not
received.
4. The method as recited in claim 3, wherein the act of receiving a
bit map that indicates a packet containing the conferencing data
was not received comprises an act of a sequence number
corresponding to the packet indicating that the packet was not
received.
5. The method as recited in claim 4, wherein the act of a sequence
number corresponding to the packet indicating that the packet was
not received comprises an act of one or more other sequence numbers
indicating other packets there were received.
6. The method as recited in claim 1, wherein the act of detecting
that a child computer system did not sufficiently receive the
multi-cast packet comprises an act of receiving a negative
acknowledgement message from the child computer system.
7. The method as recited in claim 6, wherein the act of receiving a
negative acknowledgement message from the child computer system
comprises an act of receiving a negative acknowledgement message
that includes a last continuously received packet sequence number,
a last received packet sequence number, and a bit map of the
multi-cast packets received between the last continuous packet
sequence number and the last packet sequence number.
8. The method as recited in claim 1, wherein the act of detecting
that a child computer system did not sufficiently receive the
multi-cast packet comprises an act of failing to receive a
corresponding acknowledgment message from the child computer system
within a round trip time of accessing the multi-cast packet, the
round trip time being at least an estimate of the time for a packet
to travel between the parent computer system and the child computer
system.
9. The method as recited in claim 8, wherein the act of failing to
receive a corresponding acknowledgment message from the child
computer system within a round trip time of accessing the
multi-cast packet comprises an act of failing to receive a
corresponding acknowledgment message within a round trip time based
at least on the difference in the reception time of a prior
multi-cast packet acknowledgement message and the reception time of
the prior multi-cast packet.
10. The method as recited in claim 8, wherein the act of failing to
receive a corresponding acknowledgment message from the child
computer system within a round trip time of accessing the
multi-cast packet comprises an act of failing to receive a
corresponding acknowledgment message collectively acknowledging the
child computer system's receipt of a plurality of multi-cast
packets such that the potential of causing an acknowledgement
implosion is reduced.
11. The method as recited in claim 10, wherein the act of failing
to receive a corresponding acknowledgment message collectively
acknowledging the child computer system's receipt of a plurality of
multi-cast packets comprises an act of calculating the plurality of
multi-cast packets based at least on the number of child computer
systems participating in the multi-cast conference session.
12. The method as recited in claim 1, wherein the act of detecting
that a child computer system did not receive the multi-cast packet
comprises an act of failing to receive a corresponding
acknowledgment message from the child computer system in response
to keep-alive message.
13. The method as recited in claim 1, wherein the act of
identifying a delivery mechanism for re-transmitting the stored
conferencing data to the child computer system comprises an act of
identifying a uni-cast mechanism for re-transmitting the stored
conferencing data.
14. The method as recited in claim 13, wherein the act of
identifying a uni-cast mechanism for re-transmitting the stored
conferencing data comprises an act of identifying TCP as a
mechanism for re-transmitted stored conferencing data.
15. The method as recited in claim 13, wherein the act of
identifying a uni-cast mechanism for re-transmitting the stored
conferencing data comprises an act of detecting that the number of
immediate child computer systems that did not receive the
multi-cast packet is below a specified threshold.
16. The method as recited in claim 1, wherein the act of
identifying a delivery mechanism for re-transmitting the stored
conferencing data to the child computer system comprises an act of
identifying a multi-cast mechanism for re-transmitting the stored
conferencing data based on the number of child computer systems not
receiving the multi-cast packet being above a specified
threshold.
17. The method as recited in claim 16, wherein the act of
identifying a multi-cast mechanism for re-transmitting the stored
conferencing data comprises an act of identifying an IP multi-cast
mechanism for re-transmitting the stored conferencing data.
18. The method as recited in claim 1, wherein the act of
retransmitting the stored conferencing data to the child computer
system in accordance with the identified delivery mechanism
comprises an act of retransmitting the stored conference data to
the child computer system according to a uni-cast mechanism so as
to provide repaired conferencing data to the child computer
system.
19. The method as recited in claim 18, wherein the act of
retransmitting the stored conference data to the child computer
system according to a uni-cast mechanism so as to provide repaired
conferencing data to the child computer system comprises an act of
retransmitting the stored conferencing data according to TCP so as
to repair conferencing data that was not sufficiently received via
IP multi-cast.
20. In a hierarchically arranged multi-cast conferencing session
including at least a child computer system and a parent computer
system, the child computer system being network connectable to the
parent computer system, a method for the child computer system to
receive repair conferencing for repairing conferencing data that
was not sufficiently received when the conferencing data was
originally multi-cast to computer systems participating in the
multi-cast conferencing session, the method comprising: an act of
receiving a last continuously received multi-cast packet having a
last continuously received packet sequence number, the last
continuously received multi-cast packet originally being multi-cast
by a root computer system for delivery to other computer systems
participating in the multi-cast conference session; an act of
receiving a last received multi-cast packet having a last received
sequence number, the last received multi-cast packet originally
being multi-cast by the root computer system for delivery to other
computer systems participating in the multi-cast conference
session; an act of detecting that one or more multi-cast packets
with sequence numbers between the last continuously received packet
sequence number and the last received sequence number were not
received; an act of sending a negative acknowledgement message to
the parent computer system, the negative acknowledgement message
indicating to the parent computer system that the child computer
system did not receive the one or more multi-cast packets with
sequence numbers between the last continuously received packet
sequence number and the last received sequence number; and an act
of receiving repair conferencing data from the parent computer
system, the repair conferencing data for repairing conferencing
data that was not sufficiently received by the child computer
system.
21. The method as recited in claim 20, wherein the act of receiving
a last received multi-cast packet with a last received sequence
number comprises an act of receiving a keep-alive message from the
root computer system.
22. The method as recited in claim 20, wherein the act of sending a
negative acknowledgement message to the parent computer system
comprises an act of sending a negative acknowledgment message
including the last continuously received packet sequence number,
the last received packet sequence number, and a bit map of the
multi-cast packets received between the last continuous packet
sequence number and the last packet sequence number.
23. The method as recited in claim 20, wherein the act of receiving
repair conferencing data from the parent computer system comprises
an act of receiving the repair conferencing data via a multi-cast
mechanism.
24. The method as recited in claim 23, wherein the act of receiving
the repair conferencing data via a multi-cast mechanism comprises
an act of receiving repair conferencing data via IP multi-cast.
25. The method as recited in claim 20, wherein the act of receiving
repair conferencing data from the parent computer system comprises
an act of receiving the repair conferencing data via a uni-cast
mechanism.
26. The method as recited in claim 25, wherein the act of receiving
the repair conferencing data via a uni-cast mechanism comprises an
act of receiving repair conferencing data via TCP.
27. A computer program product for use in a hierarchically arranged
multi-cast conferencing session including at least a parent
computer system and one or more child computer systems, the parent
computer system having a receive buffer and being network
connectable to the one or more child computer systems, the parent
computer system being configured to flush conferencing data from
the receive buffer after receiving an acknowledgment of reception
of the conferencing data from each of the one or more child
computer systems, the computer program product for implementing a
method for the parent computer system to repair conferencing data
that was not sufficiently received by at least one child computer
system, the computer program product comprising one or more
computer-readable media having stored thereon computer executable
instructions that, when executed by a processor, cause the parent
computer system to perform the following: access a multi-cast
packet containing conferencing data for the multi-cast conference
session, the multi-cast packet originally being multi-cast by a
root computer system for delivery to other computer systems
included in multi-cast conference session; store the conferencing
data in the receive buffer; detect that a child computer system did
not sufficiently receive the multi-cast packet; identify a delivery
mechanism for re-transmitting the stored conferencing data to the
child computer system, based at least on the parent computer
system's position in the multi-cast conferencing session; and
re-transmit the conferencing data to the child computer system in
accordance with the identified delivery mechanism.
28. The method as recited in claim 27, wherein the one or more
computer-readable media comprise system memory.
29. A computer program product for use in a hierarchically arranged
multi-cast conferencing session including at least a child computer
system and a parent computer system, the child computer system
being network connectable to the parent computer system, the
computer program product for implementing a method for the child
computer system to receive repair conferencing data that was not
sufficiently received when the conferencing data was originally
multi-cast to computer systems participating in the multi-cast
conferencing session, the computer program product comprising one
or more computer-readable media having stored thereon computer
executable instructions that, when executed by a processor, cause
the child computer system to perform the following: receive a last
continuously received multi-cast packet having a last continuously
received packet sequence number, the last continuously received
multi-cast packet originally being multi-cast by a root computer
system for delivery to other computer systems participating in the
multi-cast conference session; receive a last received multi-cast
packet having a last received sequence number, the last received
multi-cast packet originally being multi-cast by the root computer
system for delivery to other computer systems participating in the
multi-cast conference session; detect that one or more multi-cast
packets with sequence numbers between the last continuously
received packet sequence number and the last received sequence
number were not received; send a negative acknowledgement message
to the parent computer system, the negative acknowledgement message
indicating to the parent computer system that the child computer
system did not receive the one or more multi-cast packets with
sequence numbers between the last continuously received packet
sequence number and the last received sequence number; and receive
repair conferencing data from the parent computer system, the
repair conferencing data for repairing conferencing data that not
sufficiently received by the child computer system.
30. The method as recited in claim 29, wherein the one or more
computer-readable media comprise physical storage media.
31. One or more computer-readable media having stored thereon a
data structure for representing repair information, the data
structure comprising the following: a last continuously received
field representing the sequence number of the last continuously
received multi-cast packet received by a computer system
participating in a multi-cast conferencing session; a last received
field representing the sequence number of the last received
multi-cast packet received by the computer system participating in
the multi-cast conferencing session; and a bit map field
representing a bit map of one or more multi-cast packets with
sequence numbers between the sequence number represented in the
last continuously received field and the sequence number
represented in the last received field.
Description
CROSS-REFERENCE TO RELATED APPLICATION
[0001] This application claims benefit to U.S. patent application
Ser. No. 10/436,613 filed on May 13, 2003.
BACKGROUND OF THE INVENTION
[0002] 1. The Field of the Invention
[0003] The present invention relates to network communication
technology, and more specifically, to reliable delivery of
multi-cast conferencing data.
[0004] 2. Background and Relevant Art
[0005] Computer networks have enhanced our ability to communicate
and access information by allowing one computer or device
(hereinafter both referred to as a "computing system") to
communicate over a network with another computing system using
electronic messages. When transferring an electronic message
between computing systems, the electronic message will often pass
through a protocol stack that performs operations on the data
within the electronic message (e.g., packetizing, routing, flow
control). The Open System Interconnect ("OSI") model is an example
of a networking framework for implementing a protocol stack.
[0006] The OSI model breaks down the operations for transferring an
electronic message into seven distinct "layers," each designated to
perform certain operations in the data transfer process. While
protocol stacks can potentially implement each of the layers, many
protocol stacks implement only selective layers for use in
transferring data across a network. When data is transmitted from a
computing system, it originates at the application layer and is
passed down to intermediate lower layers and then onto a network.
When data is received from a network it enters the physical layer
and is passed up to higher intermediate layers and then eventually
received at the application layer. The application layer, the upper
most layer, is responsible for supporting applications and end-user
processes, such as, for example, electronic conferencing
software.
[0007] Often, when two computing systems are to communicate with
each other, the two computing systems will first establish a
connection (e.g., a Transmission Control Protocol ("TCP")
connection). Thus, when a number of different computing systems are
to participate in an electronic conference, the different computing
systems may establish connections among one another. Accordingly,
each computing system participating in the electronic conference is
then able to share conference data with every other computing
system participating in the electronic conference. The established
connections can result in the computing systems being configured in
a logical hierarchy, such as, for example, that of a T.120
conferencing session. A logical hierarchy can include a root
computing system having connections to one or more intermediate
computing systems, that are in turn eventually connected to one or
more leaf computing systems (potentially through connections to one
or more other intermediate computing systems). Accordingly, a
logically hierarchy can include a significant number of established
connections.
[0008] During an electronic conference, conferencing data typically
originates at an intermediate or leaf computing system in one
branch of the logical hierarchy. The intermediate or leaf computing
system transfers the conferencing data up the logical hierarchy
(e.g., by utilizing established TCP connections) to the root
computing system. The root computing system then transfers the
conferencing data down the logical hierarchy (e.g., by utilizing
established TCP connections) to all the intermediate and leaf
computing systems in the logical hierarchy. Accordingly, for
conferencing data to reach an intermediate or leaf computing system
the conferencing data may travel over a number of established
connections. For example to deliver conferencing data to a leaf
computing system, the conferencing data may travel over first
connection between a root computing system and a first intermediate
computing system, over second connection between the first
intermediate computing system and a second intermediate computing
system, and over a third connection between the second intermediate
computing system and the leaf computing system.
[0009] Many connection-oriented protocols, such as TCP, provide the
features of end-to-end error recovery, resequencing, and flow
control. Accordingly, utilizing a connection-oriented protocol to
transfer conferencing data increases reliability. However, to
realize the features of connection-oriented protocols, state
information, such as, for example, send and receive buffers,
congestion control parameters, and sequence and acknowledgment
number parameters must be maintained for each TCP connection.
Further, some state information must be transferred along with
conferencing data when conferencing data is transferred between
computing systems. Maintenance and transfer of state information
consumes computing system resources (e.g., system memory), consumes
network bandwidth, and potentially increases network latency. In an
electronic conference with a number of intermediate and leaf
computing systems the bandwidth consumed by transferred state
information can be relatively large.
[0010] As a result, some electronic conferencing applications have
utilized multi-cast protocols (e.g., multi-cast Internet Protocol
("IP")) to transfer conferencing data from a root computing system
down to other computing systems in a logically hierarchy. In
electronic conferences utilizing multi-cast protocols, each
intermediate and leaf computing system listens on the same
designated multi-cast address for conferencing data. Accordingly, a
root computing system need only transmit conferencing data to the
designated multi-cast address to deliver the conferencing data to
all the other computing systems. During normal operation, each
computing system listening on the designated multi-cast address
will then receive the conferencing data.
[0011] However, since multi-cast protocols are typically not
connection-oriented, multi-cast protocols do not provide any
reliable messaging features (e.g., end-to-end error recovery,
resequencing, flow control, etc). Thus, when multi-cast data is
lost or damaged there is little, if anything, that can be done to
recover the lost or damaged data. This is unfortunate, since lost
or damaged conferencing data can significantly reduce the
usefulness of an electronic conference. Further, since multi-cast
conferencing data is transmitted to every computer system, lost or
damaged multi-cast conferencing data can potentially affect every
intermediate and leaf computing system participating in the
electronic conference. Therefore systems, methods, computer program
products, and data structures for reliably delivering multi-cast
conferencing data would be advantageous.
BRIEF SUMMARY OF THE INVENTION
[0012] The foregoing problems with the prior state of the art are
overcome by the principles of the present invention, which are
directed towards methods, systems, and computer program products
for reliable delivery of multi-cast conferencing data. A number of
computer systems participate in a hierarchically arranged
multi-cast conference session that includes at least a parent
computer system and one or more corresponding child computer
systems. The parent computer system (which may or may not be a root
computer system) accesses a multi-cast packet (e.g., an Internet
Protocol ("IP") multi-cast packet) containing conferencing data for
the multi-cast conference session. The parent computer system
stores the conferencing data in a receive buffer until receiving an
acknowledgment from each of one or more corresponding child
computer systems indicating reception of the conferencing data.
[0013] A child computer system detects, for example, by utilizing
sequence numbers, that the child computer system did not receive
the multi-cast packet. The child computer system sends a negative
acknowledgement message to the parent computer system to indicate
that the multi-cast packet was not received. In response, the
parent computer system identifies a mechanism for re-transmitting
the stored conferencing data to the child computer system. When the
parent computer system is the root computer system, the parent
computer system may identify a multi-cast or a uni-cast mechanism
(e.g., utilizing a Transmission Control Protocol ("TCP")
connection) for re-transmitting the conferencing data.
[0014] On the other hand, when the parent computer system is not
the root computer system, the parent computer system can identify a
uni-cast mechanism. Thus, conferencing data can be re-transmitted
to a child computer system via uni-cast when it is indicated that a
multi-cast packet is not received. Accordingly, embodiments of the
present invention can more reliably deliver conferencing data
through recovery via connection-oriented protocols, while still
realizing potential bandwidth savings and reduced latency
associated with multi-cast protocols. Further, embodiments of the
present invention allow both multi-cast capable computer systems
and computers that are not multi-cast enabled to participate in the
same conferencing session. Multi-cast capable computer systems can
participate in the conferencing session via multi-cast and
computers that are not multi-cast enabled can participate in the
conferencing session via uni-cast.
[0015] In some embodiments, a parent computer system invites a
child computer system to join an existing multi-cast conference
session. The parent computer system access a multi-cast address for
the multi-cast conference session and transmits a multi-cast invite
message, including at least the multi-cast address, to the child
computer system. In response to the multi-cast invite, the child
computer system sends a multi-cast status message indicating to the
parent computer system the capability to receive multi-cast
packets. In response to the multi-cast status message, the parent
computer system sends a next multi-cast sequence number to the
child computer system. The next multi-cast sequence number
indicates the multi-cast sequence number that is to be associated
with the next multi-cast packet received at the child computer
system. Accordingly, the child computer system can dynamically join
an existing multi-cast conference session without significantly
impacting other computer systems already participating in the
existing multi-cast conference session.
[0016] From time to time, a root computer system can adjust a
current send rate for multi-cast packets. When the root computer
system's immediate child computer systems acknowledge reception of
a sequence of multi-cast packets within a specified period of time,
a current send rate can be increased. On the other hand, when the
immediate child computer systems do not acknowledge reception of a
sequence of multi-cast packets within a specified period of time
(e.g., as a result of network congestion or latency), the send rate
of multi-cast packets can be decreased. Accordingly, a root
computer system can adjust a send rate to compensate for changes in
the transmission characteristics (e.g., available bandwidth and
latency) of networks used to deliver multi-cast packets.
[0017] Additional features and advantages of the invention will be
set forth in the description that follows, and in part will be
obvious from the description, or may be learned by the practice of
the invention. The features and advantages of the invention may be
realized and obtained by means of the instruments and combinations
particularly pointed out in the appended claims. These and other
features of the present invention will become more fully apparent
from the following description and appended claims, or may be
learned by the practice of the invention as set forth
hereinafter.
BRIEF DESCRIPTION OF THE DRAWINGS
[0018] In order to describe the manner in which the above-recited
and other advantages and features of the invention can be obtained,
a more particular description of the invention briefly described
above will be rendered by reference to specific embodiments thereof
which are illustrated in the appended drawings. Understanding that
these drawings depict only typical embodiments of the invention and
are not therefore to be considered to be limiting of its scope, the
invention will be described and explained with additional
specificity and detail through the use of the accompanying drawings
in which:
[0019] FIG. 1 illustrates a suitable operating environment for the
principles of the present invention.
[0020] FIG. 2 illustrates an example of a network architecture that
facilitates delivery of multi-cast conferencing data with increased
reliability.
[0021] FIG. 3 illustrates an example flowchart of a method for
joining an existing multi-cast conference session.
[0022] FIG. 4 illustrates an example flowchart of a method for more
reliably delivering multi-cast conferencing data.
[0023] FIG. 5 illustrates an example flowchart of a method for
adjusting a multi-cast send rate.
[0024] FIG. 6 illustrates an example protocol stack that
facilitates appropriate synchronization of uni-cast and multi-cast
sequencing numbers.
DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS
[0025] The principles of the present invention provide for reliably
delivering multi-cast conferencing data to computer systems
participating in a multi-cast conference session. When multi-cast
conferencing data is lost or damaged during delivery, the lost or
damaged conferencing data can be repaired via connection-oriented
uni-cast delivery. Computer systems can join an existing multi-cast
conference session without significantly impacting other computer
systems already participating in the existing multi-cast conference
session. A root computer system can adjust a multi-cast send rate
to compensate for changed network conditions.
[0026] Embodiments within the scope of the present invention
include computer-readable media for carrying or having
computer-executable instructions or data structures stored thereon.
Such computer-readable media may be any available media, which is
accessible by a general-purpose or special-purpose computer system.
By way of example, and not limitation, such computer-readable media
can comprise physical storage media such as RAM, ROM, EPROM, CD-ROM
or other optical disk storage, magnetic disk storage or other
magnetic storage devices, or any other media which can be used to
carry or store desired program code means in the form of
computer-executable instructions, computer-readable instructions,
or data structures and which may be accessed by a general-purpose
or special-purpose computer system.
[0027] In this description and in the following claims, a "network"
is defined as one or more logical communication links that enable
the transport of electronic data between computer systems and/or
modules. When information is transferred or provided over a network
or another communications connection (either hardwired, wireless,
or a combination of hardwired or wireless) to a computer system,
the connection is properly viewed as a computer-readable medium.
Thus, any such connection is properly termed a computer-readable
medium. Combinations of the above should also be included within
the scope of computer-readable media. Computer-executable
instructions comprise, for example, instructions and data which
cause a general-purpose computer system or special-purpose computer
system to perform a certain function or group of functions. The
computer executable instructions may be, for example, binaries,
intermediate format instructions such as assembly language, or even
source code.
[0028] In this description and in the following claims, a "computer
system" is defined as one or more software modules, one or more
hardware modules, or combinations thereof, that work together to
perform operations on electronic data. For example, the definition
of computer system includes the hardware components of a personal
computer, as well as software modules, such as the operating system
of the personal computer. The physical layout of the modules is not
important. A computer system may include one or more computers
coupled via a network. Likewise, a computer system may include a
single physical device (such as a mobile phone or Personal Digital
Assistant "PDA") where internal modules (such as a memory and
processor) work together to perform operations on electronic
data.
[0029] In this description and in the following claims, a "logical
communication link" is defined as any communication path that
enables the transport of electronic data between two entities such
as computer systems or modules. The actual physical representation
of a communication path between two entities is not important and
may change over time, such as, for example, when a routing path is
changed. A logical communication link can include portions of a
system bus, a local area network, a wide area network, the
Internet, combinations thereof, or portions of any other path that
facilitates the transport of electronic data. Logical communication
links are defined to include hardwired links, wireless links, or a
combination of hardwired links and wireless links. Logical
communication links can also include software or hardware modules
that condition or format portions of data so as to make the
portions of data accessible to components that implement the
principles of the present invention (e.g., proxies, routers,
gateways, etc).
[0030] In this description and in the following claims,
"conferencing data" is defined as data associated with an
electronic conference. Conferencing data can be transferred between
computer systems participating in the electronic conference.
Conferencing data is defined to include audio and/or video streams,
visual and/or non-visual data, and/or data files that are delivered
from a sending computer system (e.g., a root computer system) to a
receiving computer system (e.g., an intermediate or leaf computer
system). For example, conferencing data can include voice over
Internet Protocol ("IP") data (audio stream data), camera video
data (video stream data), application sharing and whiteboard data
(visual data), chat text data (non-visual data), and/or file
transfer data (data file). Conferencing data can be transferred
using a wide variety of protocols or combination of protocols, such
as, for example, Internet Protocol ("IP"), User Datagram Protocol
("UDP"), Transmission Control Protocol ("TCP"), Real-Time Transport
Protocol ("RTP"), and Real Time Streaming Protocol ("RTSP").
[0031] In this description and in the following claims, "send rate"
is defined as the speed with which conferencing data is transferred
(or is to be transferred) onto a logical communication link, across
a logical communication link, or received from a logical
communication link. A send rate can be measured in a variety of
different units, such as, for example, Megabits per second ("Mbps")
and Megabytes per second ("MBps").
[0032] Those skilled in the art will appreciate that the invention
may be practiced in network computing environments with many types
of computer system configurations, including, personal computers,
laptop computers, hand-held devices, multi-processor systems,
microprocessor-based or programmable consumer electronics, network
PCs, minicomputers, mainframe computers, mobile telephones, PDAs,
pagers, and the like. The invention may also be practiced in
distributed system environments where local and remote computer
systems, which are linked (either by hardwired links, wireless
links, or by a combination of hardwired and wireless links) through
a network, both perform tasks. In a distributed system environment,
program modules may be located in both local and remote memory
storage devices.
[0033] FIG. 1 and the following discussion are intended to provide
a brief, general description of a suitable computing environment in
which the invention may be implemented. Although not required, the
invention will be described in the general context of
computer-executable instructions, such as program modules, being
executed by computer systems. Generally, program modules include
routines, programs, objects, components, data structures, and the
like, which perform particular tasks or implement particular
abstract data types. Computer-executable instructions, associated
data structures, and program modules represent examples of the
program code means for executing acts of the methods disclosed
herein.
[0034] With reference to FIG. 1, an example system for implementing
the invention includes a general-purpose computing device in the
form of computer system 120, including a processing unit 121, a
system memory 122, and a system bus 123 that couples various system
components including the system memory 122 to the processing unit
121. Processing unit 121 can execute computer-executable
instructions designed to implement features of computer system 120,
including features of the present invention. The system bus 123 may
be any of several types of bus structures including a memory bus or
memory controller, a peripheral bus, and a local bus using any of a
variety of bus architectures. The system memory includes read only
memory ("ROM") 124 and random access memory ("RAM") 125. A basic
input/output system ("BIOS") 126, containing the basic routines
that help transfer information between elements within computer
system 120, such as during start-up, may be stored in ROM 124.
[0035] The computer system 120 may also include magnetic hard disk
drive 127 for reading from and writing to magnetic hard disk 139,
magnetic disk drive 128 for reading from or writing to removable
magnetic disk 129, and optical disk drive 130 for reading from or
writing to removable optical disk 131, such as, or example, a
CD-ROM or other optical media. The magnetic hard disk drive 127,
magnetic disk drive 128, and optical disk drive 130 are connected
to the system bus 123 by hard disk drive interface 132, magnetic
disk drive-interface 133, and optical drive interface 134,
respectively. The drives and their associated computer-readable
media provide nonvolatile storage of computer-executable
instructions, data structures, program modules, and other data for
the computer system 120. Although the example environment described
herein employs magnetic hard disk 139, removable magnetic disk 129
and removable optical disk 131, other types of computer readable
media for storing data can be used, including magnetic cassettes,
flash memory cards, digital versatile disks, Bernoulli cartridges,
RAMs, ROMs, and the like.
[0036] Program code means comprising one or more program modules
may be stored on hard disk 139, magnetic disk 129, optical disk
131, ROM 124 or RAM 125, including an operating system 135, one or
more application programs 136, other program modules 137, and
program data 138. A user may enter commands and information into
computer system 120 through keyboard 140, pointing device 142, or
other input devices (not shown), such as, for example, a
microphone, joy stick, game pad, scanner, or the like. These and
other input devices can be connected to the processing unit 121
through input/output interface 146 coupled to system bus 123.
Input/output interface 146 logically represents any of a wide
variety of different interfaces, such as, for example, a serial
port interface, a PS/2 interface, a parallel port interface, a
Universal Serial Bus ("USB") interface, or an Institute of
Electrical and Electronics Engineers ("IEEE") 1394 interface (i.e.,
a FireWire interface), or can even logically represent a
combination of different interfaces.
[0037] A monitor 147 or other display device is also connected to
system bus 123 via video interface 148. Speakers 169 or other audio
output device is also connected to system bus 123 via audio
interface 149. Other peripheral output devices (not shown), such
as, for example, printers, can also be connected to computer system
120.
[0038] Computer system 120 is connectable to networks, such as, for
example, an office-wide or enterprise-wide computer network, a home
network, an intranet, and/or the Internet. Computer system 120 can
exchange data with external sources, such as, for example, remote
computer systems, remote applications, and/or remote databases over
such networks.
[0039] Computer system 120 includes network interface 153, through
which computer system 120 receives data from external sources
and/or transmits data to external sources. As depicted in FIG. 1,
network interface 153 facilitates the exchange of data with remote
computer system 183 via logical communication link 151. Network
interface 153 can logically represent one or more software and/or
hardware modules, such as, for example, a network interface card
and corresponding Network Driver Interface Specification ("NDIS")
stack. Logical communication link 151 represents a portion of a
network (e.g., an Ethernet segment), and remote computer system 183
represents a node of the network. For example, remote computer
system 183 can be computer system that transmits conferencing to
computer system 120. On the other hand, remote computer system 183
can be a receiving computer system that receives conferencing from
computer system 120.
[0040] Likewise, computer system 120 includes input/output
interface 146, through which computer system 120 receives data from
external sources and/or transmits data to external sources.
Input/output interface 146 is coupled to modem 154 (e.g., a
standard modem, a cable modem, or digital subscriber line ("DSL")
modem) via logical communication link 159, through which computer
system 120 receives data from and/or transmits data to external
sources. As depicted in FIG. 1, input/output interface 146 and
modem 154 facilitate the exchange of data with remote computer
system 193 via logical communication link 152. Logical
communication link 152 represents a portion of a network and remote
computer system 193 represents a node of the network. For example,
remote computer system 193 can be a computer system that transmits
conferencing data to computer system 120. On the other hand, remote
computer system 193 can be computer system that receives
conferencing data from computer system 120.
[0041] While FIG. 1 represents a suitable operating environment for
the present invention, the principles of the present invention may
be employed in any system that is capable of, with suitable
modification if necessary, implementing the principles of the
present invention. The environment illustrated in FIG. 1 is
illustrative only and by no means represents even a small portion
of the wide variety of environments in which the principles of the
present invention may be implemented.
[0042] FIG. 2 illustrates example network architecture 200. The
computer systems in network architecture 200 are connected to one
another by logical communication links 241-247 (hereinafter
referred to simply as "links"), resulting in the depicted
hierarchical configuration, such as, for example, that of a T.120
electronic conference. Accordingly, some computer systems are
viewed as parent computer systems of other computer systems. For
example, root computer system 202 can be viewed as a parent
computer system of intermediate computer systems 212 and 213. On
the other hand, some computer systems are viewed as child computer
systems of other computers systems. For example, leaf computer
systems 222, 223, and 224 can be viewed as child computer systems
of intermediate computer system 212. Similarly, leaf computer
systems 226 and 227 can be viewed as child computer systems of
intermediate computer system 213.
[0043] Some computer systems are viewed as both child computer
systems and parent computer systems. For example, intermediate
computer system 212 can be viewed as a child of root computer
system 202 and a parent computer system of leaf computer systems
222, 223, and 224. Similarly, intermediate computer system 213 can
be viewed as a child of root computer system 202 and a parent
computer system of leaf computer systems 226 and 227.
[0044] The computer systems depicted within conference boundary 271
(the solid line) are participating in electronic conference 270. Of
the participating computer systems, those depicted within
multi-cast boundary 251 (the dashed line) are participating in
multi-cast session 250 and can receive conferencing data (for
electronic conference 270) that has been multi-cast (e.g., IP
multi-cast). Root computer system 202 can allocate a designated
multi-cast address (e.g., an IP multi-cast address) as a
destination network address for multi-cast packets containing
conferencing data. When a computer system joins multi-cast session
250, the joining computer system is made of aware of the designated
multi-cast address. Accordingly, the joining computer system can
listen on the designated multi-cast address for multi-cast packets
containing conferencing data. For example, intermediate computer
systems 212 and 213 and leaf computer systems 223, 224, and 226 can
listen on a designated multi-cast address for multi-cast packets
from root computer system 202. As depicted by arrows 261-265,
multi-cast packet 282, which contains conferencing data 252, is
multi-cast to intermediate computer systems 212 and 213 and leaf
computer systems 223, 224, and 226.
[0045] Other participating computer systems, such as, for example,
computer systems that do not support multi-cast, can participate in
electronic conference 270 via uni-cast. For example, intermediate
computer system 213 and leaf computer system 227 may communicate
via a TCP connection. Accordingly, after receiving multi-cast
packet 282, intermediate computer system 213 can extract
conferencing data 252. Intermediate computer system 213 can then
include conferencing data 252 in TCP packet 283 for delivery to
leaf computer system 227. As depicted by arrow 266, intermediate
computer system 213 can delivery TCP packet 266 to leaf computer
system 227.
[0046] FIG. 3 illustrates an example flow chart of a method 300 for
joining an existing multi-cast session. The method 300 will be
described with respect to the computer systems in network
architecture 200.
[0047] The method 300 includes an act of accessing a designated
multi-cast address for a multi-cast session (act 301). Act 301 can
include an intermediate computer system, such as, for example,
intermediate computer system 212, identifying an IP multi-cast
address currently being used by the intermediate computer system.
Alternatively, a root computer system, such as, for example, root
computer system 202, can allocate an IP multi-cast network address.
An allocated IP multi-cast address may be an IP address from a
reserved range of IP address, such as, for example, between
224.0.0.0 and 239.255.255.255. An IP multi-cast address can be
allocated using an allocation protocol, such as, for example,
Multicast Dynamic Client Allocation Protocol ("MDHCP").
[0048] An IP multi-cast address can be allocated sequentially or
randomly from a range of IP multi-cast addresses supplied by an
administrator. Before allocating an IP multi-cast address, a root
computer system can perform a check to determine if the IP
multi-cast address is already in use (e.g., by an existing
multi-cast session). To reduce the negative impacts associated with
a plurality of computer systems allocating the same IP multi-cast
address, an IP multi-cast address and a root computer system's IP
address can be combined to form a unique identifier for a
multi-cast session. When a multi-cast packet is received, a
receiving computer system checks both the IP multi-cast address and
root computer system's IP address. When the check determines that
the multi-cast packet is for a multi-cast session the receiving
computer system is not participating in, the multi-cast packet can
be discarded.
[0049] The method 300 includes an act of sending a multi-cast
invite message, including at least the designated multi-cast
address, to the child computer system (act 302). Act 302 can
include a parent computer system, such as, for example,
intermediate computer system 212, sending a multi-point
communication service ("MCS") Connect-Initial message to a child
computer system, such as, for example, leaf computer system 222. A
multi-cast invite message can include a session identifier data
structure representing the designated multi-cast address, a
designated multi-cast port, and a network address of the multi-cast
sender, such as, for example, an IP address of root computer system
202. One of the fields of the session identifier data structure can
represent a designated multi-cast address for a multi-cast session.
Another field of the session identifier data structure can
represent a designated port for the multi-cast session. Yet another
field of the data structure can represent a network address of the
multi-cast sender.
[0050] The method 300 includes an act of receiving a multi-cast
invite message, including at least the designated multi-cast
address, from the parent computer system (act 305). For example,
leaf computer system 222 can receive the multi-cast invite message
sent from intermediate computer system 212. A received multi-cast
invite message can include a session identifier, for example,
represented in a session identifier data structure. When a child
computer system receives a session identifier data structure, the
child computer system can maintain the fields of the session
identifier data structure in memory. Accordingly, a child computer
system can use a session identifier data structure to facilitate
configuration of a network interface and for verifying that
multi-cast packets are associated with a particular multi-cast
session.
[0051] The method 300 includes an act of receiving a multi-cast
packet at the designated multi-cast address (act 306). Act 306 can
include receiving a multi-cast packet transmitted from the root
computer system for reception by computer systems participating in
a multi-cast session. For example, as indicated by arrow 267, leaf
computer system 222 can receive multi-cast packet 282. Reception of
multi-cast packet 282 indicates to leaf computer system 222 that a
received multi-cast invite message contained appropriate connection
information (e.g., designated multi-cast address, designated
multi-cast port, and network address of root computer system 202)
for joining multi-cast session 250.
[0052] The method 300 includes an act of sending a multi-cast
status message indicating the capability to receive multi-cast
packets (act 307). Act 307 can include a child computer system
sending a multi-cast status message to a parent computer system in
response to receiving a multi-cast packet. For example, in response
to receiving multi-cast packet 282, leaf computer system 222 can
send a multi-cast status message to intermediate computer system
212. The multi-cast status message can be an acknowledgment message
acknowledging that leaf computer system 222 received multi-cast
packet 282.
[0053] The method 300 includes an act of receiving a multi-cast
status message indicating that the child computer system is capable
of receiving multi-cast packets (act 303). Act 303 can include a
parent computer system receiving a multi-cast status message
indicating that the child computer system can receive multi-cast
packets for the multi-cast session. For example, intermediate
computer system 212 can receive a multi-cast status message from
leaf computer system 222. A received multi-cast status message can
be an acknowledgment message acknowledging that leaf computer
system 222 received multi-cast packet 282. Since intermediate
computer system 212 also receives multi-cast packet 282,
intermediate computer system 212 can verify that a received
multi-cast status message is appropriate (e.g., that the multi-cast
packet was received at the designated multi-cast address and port,
etc.).
[0054] The method 300 includes an act of sending a next multi-cast
sequence number to the child computer system (act 304). Act 304 can
include a parent computer system sending a next multi-cast sequence
number to child computer system in response to receiving a
multi-cast status message. For example, intermediate computer
system 212 can send a multi-cast invite-confirm message including
the next multi-cast sequence number to leaf computer system 222 in
response to leaf computer system 222 acknowledging receipt of
multi-cast packet 282. The next multi-cast sequence number can
indicate the sequence number that is to be associated with the next
multi-cast packet for multi-cast session 250.
[0055] The method 300 includes an act of receiving a next
multi-cast sequence number from the parent computer system (act
308). Act 308 can include a child computer system receiving a next
multi-cast sequence number from a parent computer system. For
example, leaf computer system 222 can receive a multi-cast
invite-confirm message including the next multi-cast sequence
number from intermediate computer system 212. The next-multi-cast
sequence number indicates to leaf computer system 222 the sequence
number that is to be associated with the next multi-cast packet for
multi-cast session 250. Accordingly, leaf computer system 222 can
begin to indicate to intermediate computer system 212 when
multi-cast packets are not received.
[0056] When leaf computer system 222 joins multi-cast session 250,
both multi-cast session boundary 251 and a conference boundary 271
can be expanded to include leaf computer system 222. This expansion
is collectively represented by expanded conference boundary 273
(the dotted line). Leaf computer system 222 joins both multi-cast
session 250 and electronic conference 270 without ever sending data
to root computer system 202. Further, little, if any, resources are
expended at root computer system 202 as a result of leaf computer
system joining. Accordingly, leaf computer system 222 joins
multi-cast session 250 (an existing multi-cast session) without
significantly impacting other computer systems already
participating in multi-cast session 250.
[0057] FIG. 4 illustrates an example flow chart of a method 400 for
more reliable delivery of multi-cast conferencing data. The method
400 will be described with respect to the computer systems in
network architecture 200.
[0058] The method 400 includes an act of accessing a multi-cast
packet containing conferencing data (act 401). Act 401 can include
accessing a multi-cast packet that includes conferencing data for a
multi-cast session. The multi-cast packet can be a multi-cast
packet that was originally multi-cast by a root computer system for
delivery to other computer systems participating in the multi-cast
session. A multi-cast packet can be accessed by a root computer
system, an intermediate computer system, or a leaf computer system
participating in the multi-cast session. For example, within
multi-cast session 250, root computer system 202, intermediate
computer system 212, or intermediate computer system 213 can access
multi-cast packet 282.
[0059] Accessing a multi-cast packet can include accessing
conferencing data contained in the multi-cast packet. For example,
root computer system 202 may access conferencing data 252 before
transmitting multi-cast packet 282 to computer systems
participating in multi-cast session 250. Intermediate computer
system 212 and intermediate computer system 213 can access
conferencing data 252 after they receive multi-cast packet 282.
[0060] The method 400 includes an act of storing conferencing data
in a receive buffer (act 402). Act 402 can include a root computer
system or intermediate computer system storing accessed
conferencing data in a receive buffer. For example within
multi-cast session 250, root computer system 202, intermediate
computer system 212 and/or intermediate computer system 213, can
store conferencing data 252 in a receive buffer. It may be that
parent computer system simultaneously stores conferencing data from
a plurality of multi-cast packets.
[0061] Conferencing data can remain stored in a receive buffer
(e.g., in system memory) until all of a computer system's
corresponding multi-cast session child computer systems acknowledge
receipt of the conferencing data. For example, intermediate
computer system 213 can store conferencing data 252 until leaf
computer system 226 acknowledges receipt of conferencing data 252.
Since leaf computer system 227 is participating in electronic
conference 270 via uni-cast, leaf computer system 227 will not
acknowledge receipt of conferencing data 252. Conferencing data can
be flushed (removed) from a receive buffer after receiving
appropriate acknowledgments from corresponding child computer
systems. For example, after receiving acknowledgments from leaf
computer system 226 and leaf computer 227, intermediate computer
system 213 can flush conferencing data 252 from a corresponding
receive buffer.
[0062] The method 400 includes an act of receiving a last
continuously received multi-cast packet (Act 406). Act 406 can
include an intermediate or leaf computer system receiving a last
continuously received multi-cast packet. For example, any of the
computer systems participating in multi-cast session 250 can
receive a last continuously received multi-cast packet transmitted
from root computer system 202.
[0063] An ACK window parameter value can be maintained at a parent
computer system to schedule the transmission acknowledgment
messages from child computer systems. An ACK window parameter value
indicates to child computer systems the number of multi-cast
packets that are to be received between acknowledgment messages. An
ACK window parameter value can change dynamically as child computer
systems connect to and disconnect from the parent computer system.
An ACK window parameter value can be configured such that the
likelihood of an acknowledgment implosion at the parent computer
system is reduced.
[0064] For example, for a parent computer system having "m"
children computer systems, an ACK window parameter value "N" can be
configured according to the equation (N/2)<=m<=N. Thus, for a
parent computer system having 5 child computer systems, an ACK
window parameter value of 5, 6, 7, 8, 9, or 10 may be selected. If
7 were selected, this would indicate to a child computer system
that the child computer system is to send an acknowledgement
message to the parent computer system after the reception of every
7 multi-cast packets. Child computer systems can randomly select a
first multi-cast packet for acknowledgment to further reduce the
likelihood of an acknowledgment implosion at the parent computer
system.
[0065] As multi-cast packets are transmitted to computer systems
participating in a multi-cast session, each multi-cast packet is
assigned a sequence number. Different multi-cast packets can be
assigned different sequence numbers so that the different
multi-cast packets can be distinguished from one another. For
example, sequence numbers can be assigned incremental (e.g., by
adding one) so that a subsequent multi-cast packet can be
distinguished from prior multi-cast packet. Upon reaching a maximum
sequence number, assigned sequence numbers may "roll-over" and
begin at zero. Sequence numbers can be used to indicate a packet
ordering to a receiving computer system. Table 1 contains an
example sequence of multi-cast packets for an ACK window parameter
value of 5. TABLE-US-00001 TABLE 1 Order of Receipt Packet Sequence
Number 1 Multi-cast Packet A 4 2 Multi-cast Packet B 6 3 Multi-cast
Packet C 5 4 Multi-cast Packet D 8 5 Multi-cast Packet E 7
[0066] Although received in an order that differs from
corresponding sequence numbers, a receiving computer system can use
the sequence numbers to appropriately re-order the multi-cast
packets after reception. For example, a receiving computer system
could re-order the sequence of multi-cast packets in the following
order: Multi-cast Packet A, Multi-cast Packet C, Multi-cast Packet
B, Multi-cast Packet E, Multi-cast Packet D. Accordingly,
Multi-cast Packet D can be viewed as a last continuously received
multi-cast packet.
[0067] When no conferencing data is multi-cast for a specified time
threshold, a root computer system can multi-cast a keep alive
message having an appropriate sequence number (e.g., incremented
form the last sequence number). Computer systems participating in a
multi-cast session can acknowledge receipt of a keep alive message
by sending an acknowledgment message to a corresponding parent
computer system. Acknowledgment of a keep alive message indicates
to a parent computer system that a corresponding child computer
system is still capable of receiving multi-cast packets for the
multi-cast session. For example, leaf computer system 226 can send
an acknowledge message to intermediate computer system 213 to
indicate continued capability to received multi-cast packets for
multi-cast session 250.
[0068] When a parent computer system receives acknowledgment
messages from all corresponding child computer systems, the parent
computer system can in turn acknowledge receipt of the keep alive
message to its parent computer system. Acknowledgments can continue
up a hierarchical tree to a root computer system. For example, upon
receiving acknowledgement messages from each of leaf computer
systems 222, 223, and 224, intermediate computer system 212 can in
turn send an acknowledgment message to root computer system 202.
Keep alive messages can be sent out at specified keep-alive
intervals. Keep alive intervals can be defined using exponential
increases, such as, for example, 2 sec., 4 sec., 8 sec., 16 sec.,
etc. After a busy time, a keep alive interval can be decreased. On
the other hand, after longer periods of idle time a keep alive
interval can be increased.
[0069] The method 400 includes an act of receiving a last received
multi-cast packet (act 407). Act 407 can include an intermediate or
leaf computer system receiving a last received multi-cast packet.
For example, any of the computer systems participating in
multi-cast session 250 can receive a last received multi-cast
packet multi-cast from root computer system 202. Table 2 contains a
second example sequence of multi-cast packets for an ACK window
parameter value of 6. TABLE-US-00002 TABLE 2 Order of Receipt
Packet Sequence Number 1 Multi-cast Packet F 15 2 Multi-cast Packet
G 16 3 Multi-cast Packet H 17 4 Multi-cast Packet I 18 5 Multi-cast
Packet J 21 6 Multi-cast Packet K 23
[0070] Table 2 indicates that a last received packet was Multi-cast
Packet K.
[0071] The method 400 includes an act of detecting that one or more
multi-cast packets were not received (act 408). Act 408 can include
detecting that one or more multi-cast packets with sequences
between the last continuously received multi-cast packet and the
last received multi-cast packet were not received. For example,
referring back to Table 2, Multi-cast Packet I can be viewed as a
last continuously received multi-cast packet and Multi-cast Packet
K can be viewed as a last received multicast packet. Accordingly, a
computer system participating in a multi-cast session may detect
that multi-cast packets corresponding to multi-cast sequence
numbers 19, 20, and 22 were not received.
[0072] The method 400 includes an act of sending a negative
acknowledgment message to a parent computer system (act 409). Act
409 can include a child computer system sending a negative
acknowledgment message that indicates the child computer system did
not receive one or more multi-cast packets having multi-cast
sequence numbers between the last continuosly received multi-cast
packet and the last received multi-cast packet. For example, when
appropriate, leaf computer system 222 can send a negative
acknowledgment message to intermediate computer system 212
indicating that leaf computer system 222 did not receive one or
more multi-cast packets for multi-cast session 250. Similarly, when
appropriate, intermediate computer system 212 can send a negative
acknowledgment message to root computer system 202 indicating that
intermediate computer system 212 did not receive one or more
multi-cast packets for multi-cast session 250.
[0073] A sent negative acknowledgment message can include a data
structure representing the packet sequence number of the last
continuously received multi-cast packet, the packet sequence number
of the last received multi-cast packet, and a bit map indicating
received and missing multi-cast packets between the last
continuously multi-cast packet and the last received multi-cast
packet. For example, a participating computer system that received
the sequence of multi-cast packets in Table 2, could send a
negative acknowledgement message with values of 18, 23, and a bit
map indicating that 19, 20, 21, and 22 are sequence numbers of
packets between 18 and 23 and that 19, 20, and 22 are marked as
missing packets. Accordingly, a child computer system provides
repair information that can be used by a corresponding parent
computer system to replace conferencing data that was not received
and/or repair damaged conferencing data.
[0074] The method 400 includes an act of detecting that a child
computer system did not sufficiently receive a multi-cast packet
(act 403). Act 403 can include a parent computer system receiving a
negative acknowledgment message from a child computer system. For
example, intermediate computer systems 212 may receive a negative
acknowledgment message from leaf computer system 222, leaf computer
system 223, or leaf computer system 224. Similarly, root computer
system 202 may receive a negative acknowledgment message from
intermediate computer system 212 or intermediate computer system
213.
[0075] A received negative acknowledgment message can include
repair information identifying conferencing data that was not
received by a child computer system and/or potentially identifying
damaged conferencing data. Repair information can be represented in
a repair information data structure. One of the fields of the
repair information data structure can represent the last
continuously received multi-cast packet that was received by a
child computer system. Another field of the repair information data
structure can the last received multi-cast packet that was received
by the child computer system. Yet another field of the repair
information data structure can represent a bit map of any
multi-cast packets received between the last continuously
multi-cast packet and the last received multi-cast packet received
by the child computer system.
[0076] Accordingly, a parent computer system can use repair
information to identify that conferencing data was not sufficiently
received at the child computer system. A parent computer system can
identify that conferencing data was not sufficiently received when
a multi-cast packet is not received at all by the child computer
system (i.e., the packet was lost). Alternatively, the parent
computer system can identify that conferencing data was not
sufficiently received when the parent computer system determines
that conferencing data received at the child computer system was
damaged.
[0077] Packet loss can be detected from received repair
information. Referring back to Table 2, a parent computer system
could identify from a received bit map that a child computer system
did not receive multi-cast packets having sequence numbers 19, 20,
and 22.
[0078] In some embodiments, a parent computer system detects that a
child computer system did not receive a one or more multi-cast
packets when an acknowledgment message is not received after a
number of packets indicated by an ACK window parameter value. For
example, when an ACK window parameter value is 7, a parent computer
system should receive an acknowledgment message from a child
computer system after every 7 multi-cast packets. If after
reception of a 7.sup.th multi-cast packet, the parent computer
system does not receive an acknowledgement message the parent
computer system may determine that the child computer system has
not received one or more multi-cast packets.
[0079] A parent computer system may wait a specified time threshold
for an acknowledgment message. As depicted by arrows 261 and 262
multi-cast packet 282 is delivered to intermediate computer system
212 and leaf computer system 224 respectively. When multi-cast
packet 282 is the last packet in an ACK window, packet 282 can
trigger an acknowledgment message from leaf computer system 224.
Upon receiving multi-cast packet 282, intermediate computer system
212 will wait the specified time threshold to receive an
acknowledgment message from leaf computer system 224. If an
acknowledgment message is not received within the specified time
threshold, intermediate computer system 212 may determine that leaf
computer system 224 has not received one or more multi-cast
packets.
[0080] A specified time threshold can be a round-trip time ("RTT")
defined as the allowable time difference in accepting a multi-cast
packet between a parent computer system and a child computer
system. When a root computer system sends a multi-cast packet it
records its local sending time. Subsequently, when a child computer
system receives the multi-cast packet it records its local time.
Then, when the child computer system is ready to send an
acknowledgment message, it records a local delay time (e.g., for
packet processing) inside the acknowledgement message. When the
parent computer system receives the acknowledgment message it
records the current time and the time elapsed since the parent
computer system sent the multi-cast packet. By subtracting the
delay time at the child computer system, the parent calculates the
RTT to the child computer system. If the parent computer system is
the root computer system it will calculate the real RTT to the
child computer system.
[0081] The method 400 includes an act of identifying a delivery
mechanism for re-transmitting the stored conferencing data (act
404). Act 404 can include a parent computer system identifying a
delivery mechanism for re-transmitting stored conferencing data to
a child computer system. For example, it may be that intermediate
computer system 212 identifies a delivery mechanism for
re-transmitting conferencing data 252 to leaf computer system 222.
Similarly, it may be that that root computer system 202 identifies
a delivery mechanism for re-transmitting conferencing data 252 to
intermediate computer system 212.
[0082] A delivery mechanism can be identified based at least on the
parent computer system's position in a hierarchically arranged
conferencing session. An intermediate parent computer system can
identify a uni-cast mechanism, such as, for example, TCP, as a
mechanism for re-transmitting stored conferencing data. For
example, intermediate computer system 212 can identify uni-cast as
a mechanism for re-transmitting lost or damaged conferencing data
to leaf computer system 222. However, a root computer system (e.g.,
root computer system 202) may identify either a uni-cast mechanism
or a multi-cast mechanism for re-transmitting stored conferencing
data.
[0083] When a threshold number of the root computer system's
immediate child computer systems have lost conferencing data, the
root computer system can determine that multi-cast is an
appropriate mechanism for re-transmitting the conferencing data. An
increased number of the immediate child computer systems needing
repair can be indicative of an increased number of other computer
systems lower in the hierarchy also needing repair. That is, when
some intermediate computer systems (e.g., intermediate computer
systems 212 and 213) have not received multi-cast data, there is an
increased likelihood that other child computer systems (e.g., leaf
computer systems 222, 223, 224, and 226) have also not received the
multi-cast data. Accordingly, re-transmitting the conferencing data
via multi-cast may be more efficient. For example, root computer
system 202 can identify multi-cast as a mechanism for
re-transmitting lost or damaged conferencing data to computer
systems participating in multi-cast session 250.
[0084] On the other hand, when less than the threshold number
immediate child computer systems have lost conferencing data, the
root computer system can determine that uni-cast is an appropriate
mechanism for re-transmitting the conferencing data. A decreased
number of the immediate child computer systems needing repair can
be indicative of a reduced number of other computer systems lower
in the hierarchy also needing repair. That is, when a reduced
number of intermediate computer systems (e.g., only intermediate
computer systems 213) have not received multi-cast data, it is
likely that a reduced number of other child computer systems (e.g.,
only leaf computer system 226) have also not received the
multi-cast data. Accordingly, re-transmitting the conferencing data
via uni-cast may be more efficient. For example, root computer
system 202 can identify uni-cast as a mechanism for re-transmitting
lost or damaged conferencing data to intermediate computer system
213.
[0085] The method 400 includes an act of re-transmitting the stored
conferencing data according to the identified delivery mechanism
(act 405). Act 405 can include a parent computer system
re-transmitting conferencing data from a receive buffer to the
child computer system (e.g., via uni-cast or multi-cast). For
example, intermediate computer system 212 can re-transmit
conferencing data (from a corresponding receive buffer) to leaf
computer system 222 via TCP. Alternately, root computer system 202
can re-transmit conferencing data (from a corresponding receive
buffer) to multi-cast session 250 via IP multi-cast.
[0086] A protocol stack at a parent computer system can assign
uni-cast sequence numbers such that the uni-cast sequence numbers
synchronize with multi-cast sequence numbers of multi-cast packets.
FIG. 6 illustrates an example protocol stack 600 that facilitates
the synchronization of uni-cast and multi-cast sequence numbers.
Protocol stack 600 includes transport layer 615, data framing layer
622, uni-cast layer 614, multi-cast layer 613 and application layer
611. Transport layer 615 corresponds to a transport layer protocol,
such as, for example, TCP or User Datagram Protocol ("UDP"). Lower
layers of protocol stack 600 (not shown) can receive packets from a
network and transfer the packets up to transport layer 615. On the
other hand, transport layer 615 can receive packets from data
framing layer 622 and transfer packets down to the lower layers for
delivery onto the network. Data framing layer 622 corresponds to a
framing protocol, such as, for example, X.224. Uni-cast and
multi-cast packets can be framed using similar types of framing
headers, such as, for example, an X.224. Using similar types of
framing headers potentially makes recovery of missing packets more
efficient as both uni-cast and multi-cast packets can be
binary-identical.
[0087] Uni-cast layer 614 and multi-cast layer 613 operate together
to synchronize the transfer of packets to and from application
layer 611. Application layer 611 corresponds to one or more
application layer processes, such as, for example, Generic
Conference Control ("GCC") applications and/or T.120 applications.
When a uni-cast packet, such as, for example, uni-cast packet 621,
is transferred from transport layer 615 towards application layer
611, the uni-cast packet may first be received by multi-cast layer
613. Similarly, when a uni-cast packet, such as, for example,
uni-cast packet 622, is transferred from application layer 611
towards transport layer 615, the uni-cast packet may first be
received by multi-cast layer 613.
[0088] Accordingly, multi-cast layer 613 can preserve the causality
of packets such that the transfer of uni-cast repair packets (or
the transfer of uni-cast packets to computer systems that do not
support multi-cast, such as, for example, leaf computer system 227)
is appropriately synchronized with the transfer multi-cast packets.
When a uni-cast packet is being transferred from transport layer
615 towards application layer 611, multi-cast layer 613 can ensure
that the uni-cast packet is delivered to application layer 611
after a corresponding multi-cast packet (e.g., multi-cast packet
626) of the same priority. Similarly, when a uni-cast packet is
being transferred from application layer 611 towards transport
layer 615, multi-cast layer 613 can ensure that the uni-cast packet
is delivered to data framing layer 622 after a corresponding
multi-cast packet (e.g., multi-cast packet 627) of the same
priority.
[0089] The method 400 includes an act of receiving repair
conferencing data from the parent computer system (act 410). Act
410 can include a child computer system receiving repair
conferencing data for repairing conferencing data that was not
sufficiently received by the child computer system. Repair
conferencing data can be received via uni-cast or multi-cast. For
example, if intermediate computer system 212 received multi-cast
packet 282 but leaf computer systems 222 did not, a TCP connection
(e.g., that was created when the leaf computer system 222 joined
electronic conference 270) can be re-used over link 243 to
re-transmit conferencing data 252. This conserves network resources
since no TCP connection need be established over link 241 to repair
conferencing data at leaf computer system 222. Accordingly,
embodiments of the present invention can more reliably deliver
conferencing data through recovery via connection-oriented
protocols, while still realizing potential bandwidth savings and
reduced latency associated with multi-cast.
[0090] FIG. 5 illustrates an example flow chart of a method 500 for
adjusting a multi-cast send rate. The method 500 will be described
with respect to the computer systems in network architecture
200.
[0091] The method 500 includes an act of identifying a current send
rate for conferencing data (act 501). Act 501 can include a root
computer system identifying a current send rate (e.g., four
kilobytes per second, ten kilobytes per second, one megabyte per
second, etc.) for sending conferencing data to computer systems
participating in a multi-cast session. The current send rate is a
rate the root computer system will transmit conferencing data
(e.g., by configuring a packet size and transmission interval) to
other computer systems participating in the multi-cast conferencing
session. For example, root computer system 202 can identify a
current send rate for transmitting conferencing data to computer
systems participating in multi-cast session 250. When a multi-cast
session is initially established a current send rate can be an
initial send rate having a decreased likelihood of causing
congestion on links of a multi-cast session (e.g., links 241, 242,
243, 244, 245, and 246), such as, for example, one kilobyte per
second.
[0092] The method 500 includes an act of identifying a next
sequence number (502). Act 502 can include a root computer system
identifying the next sequence number that is to be associated with
the next transmitted multi-cast packet. For example, root computer
system 202 can identifying the sequence number that is to be
associated with the next multi-cast packet transmitted to computer
systems participating in multi-cast session 250.
[0093] The method 500 includes an act of selecting a rate change
packet sequence number a specified threshold greater than the next
packet sequence number (act 503). Act 503 can include a root
computer system selecting a rate change packet sequence number that
indicates when the root computer system can potentially adjust the
current send rate. For example, root computer system 202 can select
a rate change sequence number that indicates when computer system
202 can potentially adjust the current send rate for multi-cast
session 250.
[0094] A specified threshold (e.g. a specified number of packets)
can be set so that the root computer system (e.g., computer system
202) has an opportunity to receive at least one acknowledgment
message from each of the root computer system's immediate child
computer systems (i.e., intermediate computer systems 212 and 213).
Thus, an appropriate specified threshold can be set so that the
difference of the next packet sequence number subtracted from the
rate change packet sequence number is greater than the root
computer system's ACK window parameter value. An appropriate
specified threshold provides an interval for immediate child
computer systems to send acknowledgment messages acknowledging all
the multi-cast packets in a sequence of multi-cast packets received
within the root computer system acknowledgment window. For example,
if an ACK window parameter value were 5 (representing that an
acknowledgment message is to be sent after the reception of every 5
multi-cast packets), a specified threshold could be set to at least
6 multi-cast packets. Accordingly, if a next sequence number were
17, a rate change packet sequence number could be set to at least
23.
[0095] The method 500 includes an act of transmitting at least a
next multi-cast packet having the next packet sequence number (act
504). Act 504 can include a root computer system transmitting a
next multi-cast packet in accordance with the current send rate.
For example, root computer systems 202 can transmit a next
multi-cast packet to computer system participating in multi-cast
session 250 in accordance with the current send rate for multi-cast
session 250. It may be that a sequence of multi-cast packets (e.g.,
packets within an acknowledgment window), including the next
multi-cast packet and a rate change multi-cast packet having the
rate change packet sequence number, is transmitted.
[0096] The method 500 includes an act of adjusting the send rate
based at least on whether the one or more immediate child computer
systems indicated reception of the next multi-cast packet (act
505). Act 505 can include a root computer system decreasing the
current send rate in response to receiving a negative
acknowledgment message (or no message at all) from an immediate
child computer system. For example, root computer system 202 can
decrease the current send rate for multi-cast session 250 in
response to receiving a negative acknowledgment message from
intermediate computer system 212 or 213. It may be that an
immediate child computer system sends a negative acknowledge or is
prevented from sending a message at all due to network
congestion.
[0097] After a reduction in send rate, the root computer system can
reset a rate change sequence number to verify that the decreased
send rate is sustainable. When a root computer system receives
negative acknowledgment messages from a plurality of immediate
child computer systems, the root computer may decrease the current
send rate the same amount it would have reduced the send rate if
one negative acknowledgment was received. This reduces the
potential of dropping the current send rate to a rate significantly
below a sustainable send rate.
[0098] On the other hand, act 505 can include a root computer
system increasing the current send rate in response to receiving
acknowledgment messages from each immediate child computer system.
For example, root computer system 202 can increase the current send
rate for multi-cast session 250 in response to receiving
acknowledgment messages from both intermediate computer system 212
and intermediate computer system 213. Accordingly, a root computer
system can adjust a send rate to compensate for changes in the
transmission characteristics (e.g., available bandwidth and
latency) of networks used to deliver multi-cast packets.
[0099] A root computer system may increase and/or decrease a send
rate by a predetermined amount based on a previous adjustment in
send rate. Table 3 represents an example of how a send rate can be
adjusted. TABLE-US-00003 TABLE 3 Previous Adjustment To Increase To
Decrease No Change Double Cut by Quarter/Linear Decrease Double
Double Cut by Half Increase a Quarter Increase a Quarter/Linear Cut
by Quarter/Linear Increase Decrease Linear Increase Increase a
Quarter/Linear Linear Decrease Increase Cut by Half Increase by a
Quarter Cut by Quarter/Linear Decrease Cut by a Quarter Increase by
a Quarter Cut by Quarter/Linear Decrease Linear Decrease Increase a
Quarter/Linear Cut by Quarter/Linear Increase Decrease
[0100] When it is determined that a current send rate is to be
adjusted, a previous adjustment is considered. For example, when it
is determined that the send rate is to be increased (as a result of
receiving appropriate acknowledgment messages) and a previous
adjustment was cutting the send rate in half, the current send rate
can be increased by a quarter. A no change previous adjustment can
occur when adjusting an initial send rate.
[0101] The term "Increase By A Quarter/Linear Increase" represents
that a current send rate can be increased by a quarter or a smaller
amount (e.g., 1/16.sup.th). When a current send rate is less than
the previously recorded highest send rate, the root computer system
can increase the send rate by a quarter. Below a previously
recorded highest send rate, increasing by a quarter may be
appropriate since there is some confidence that an increased send
rate near the previously recorded highest send rate will not cause
network congestion. On the other hand, when a current send rate is
greater than the previously recorded highest send rate, the root
computer system can linearly increase the send rate. Above a
previously recorded highest send rate, there may be no way to
determine if an increased send rate will cause network congestion.
Accordingly, a more conservative linear increase may be
appropriate.
[0102] Similarly the term "Cut By A Quarter/Linear Decrease"
represents that a current send rate can be decreased by a quarter
or a smaller amount (e.g., 1/16.sup.th). When the number of lost
multi-cast packets reported inside a negative acknowledgment
message is less than a cutoff limit (e.g., 4 multi-cast packets),
the root computer system can linearly decrease the current send
rate. On the other hand, when the number of lost multi-cast packets
reported inside a negative acknowledgment message is more than the
cutoff limit, the root computer system decease the current send
rate by a quarter. Use of a cutoff limit increases the chance of
making an appropriate adjustment based on the severity of packet
loss. When a decreased number of multi-cast packets are lost (e.g.,
1 or 2), a linear decrease may sufficiently reduce network
congestion enough to mitigate further packet loss. When an
increased number of packets are lost, such as, for example, when a
burst of packets are lost, a more significant decrease in the
current send rate may be needed to sufficiently reduce network
congestion.
[0103] The present invention may be embodied in other specific
forms without departing from its spirit or essential
characteristics. The described embodiments are to be considered in
all respects only as illustrative and not restrictive. The scope of
the invention is, therefore, indicated by the appended claims
rather than by the foregoing description. All changes, which come
within the meaning and range of equivalency of the claims, are to
be embraced within their scope.
* * * * *