Rate Report Data in OpenContinue Packets
CU-SeeMe Development Group
Document Draft: 002
Protocol Feature Designer: Tim Dorcey, tdc1@cornell.edu
Document Author: Richard Kennerly, rbk1@cornell.edu
Revised: August 18, 1995
Protocol Specification - Rate Report Data addition to OpenContinue Packets
Status:
-------
Implemented in Mac CU-SeeMe 0.83b1
Implemented in Windows CU-SeeMe 0.70a1
Abstract:
---------
Quote from Tim Dorcey:
"Each data transmitter (source client or forwarding reflector), adjusts
its transmission rate according to observed network conditions. However,
users are allowed to set upper and lower bounds within which the data rate
adjustment is confined. The RateReportData feature is used to periodically
communicate the current values of the user set bounds, as well as the rate
currently in operation. Reception rate bounds are examined by data
transmitters in order to control their transmission rate to that recipient.
Transmission rate bounds are used for informative display and to enforce
admission control policies on reflectors."
Implementation:
---------------
The RateReportData feature is implemented using the OCExtraHeader
extension of the OpenContinuePacket. See CU-SeeMe Document Draft-001
for a description of how to use this capability. The RateReportData
structure is added by the client to all OpenContinue Packets.
Definitions:
------------
The type field value of the OCExtraHeader for RateReportData is:
#define kOldRateReportExtraType 2 // Ignored by current clients
#define kRateReportExtraType 3
The format of the RateReportData structure is:
typedef struct {
short minSendKbps;
short maxSendKbps;
short curSendKbps;
short minRecvKbps;
short maxRecvKbps;
short curRecvKbps;
} RateReportData;
Client Sending of RateReportData:
------------------------
A client sets the RateReportData values as follows:
minSendKbps - Value set as MinCap in the Transmission control panel.
maxSendKbps - Value set as MaxCap in the Transmission control panel.
curSendKbps - Value being used by for CurSendCap. CurSendCap is now
being calculated based on PacketLoss.
minRecvKbps - Value set as MinCap in the Reception control panel.
maxRecvKbps - Value set as MaxCap in the Reception control panel.
curRecvKbps - Value set as MaxCap in the Reception control panel. This
seems wrong, but if you're connected to a reflector the
reflector will insert its CurSendCap for you in this field
which tells other clients the max you can really receive
right now. If there is no reflector, you want to indicate
that you're currently capable of receiving up to your max.
The following calculation can be made for local display:
curRecvKbps deltaBytesRecv * 8 bits/byte / deltaTime. Where deltaTime
is the time since the last OpenContinuePacket was generated
unless this is less than 3 seconds, then the previous OC
send time is used. deltaBytesRecv is the number of bytes
of data received since deltaTime was last reset. Note:
Kbps means 1000 bits/sec, not 1024.
Reflector Handling of RateReportData :
---------------------------------------
When the reflector receives OpenContinue Packets it can check
the validity of values in the RateReportData and disallow clients
with inappropriately set values. The values of minRecvKbps and
maxRecvKbps are incorporate into it's outgoing rate adjustment
algorithm for that recipient. Before forwarding the OC packet
along to other clients, it updates the following fields:
curRecvKbps - Reflector's curSendCap for that client.
The other fields are left unchanged.
Client handling of received RateReportData:
-------------------------------------------
When a client receives RateReportData it can use the values to provide
an informative display for the user. It uses the following fields as
follows:
curRecvKbps - The client records this value for each client in the
conference. It periodically goes through its internal
database to find the max curRecvKbps of all clients and
makes sure that its curSendCap is not higher than this
value. The reason is, of course, that there's no point
in sending more data than anyone will be able to receive.
We should check their IWillRecv to make sure they're receiving
our video before considering their receive capability. If
one or more clients is not sending RateReport information
then the curSendCap is not set according to this process.
Quote from Tim Dorcey:
"Rich, this is only true (for Mac clients) when they are not receiving
RateReply packets. This could either be because they are not sending
RateControl packets or because the client/reflector on the other end does
not know how to reply. As soon as one RateReply packet is received on a
connection, the client goes into a more advanced mode of outgoing flow
control, based only on RateControl/RateReply.
So, there are actually 3 modes of outgoing rate control on the (Mac)
client: the original, based on average end-to-end packet loss counts, the
version that you have described here, and the latest version that relies
completely on RateControl/RateReply except for using the RateReport
reception min & max to bound its adjustment algorithm.
In the newest version of rate control, the client uses the
RateReply.maxRecvKbps instead of the maximum of all client
RateReport.curRecvKbps values. This should probably be described in the
RateControl/RateReply RFC instead of here.
The problem with RateReport.curRecvKbps max is that if you only sent the
reflector the most that it was using at any given time, it would have no
way to test the connection and perhaps find out that it could use more.
You could solve that problem by having the clients always send a little
more than the max RateReport.curRecvKbps, but that is a bad hack. Instead,
the reflector should tell you how much data it wants, based on what it
thinks it can send and how much extra it would like to test the connection.
The general architecture that this is leading to is that the RateReport is
mainly informative, to be used for admission control and sharing
information among clients. Since actual flow control occurs on each link,
it should be entirely determined by point-to-point message exchange
(RateControl/RateReply). This means that we should probably add a
minRecvKbps to the RateReply packet, along with the existing maxRecvKbps."