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."