687312352
Quality of Service Parameter List
Thursday, November 18, 2004
Purpose
The QoS parameters indicate in a Underlying Transport (UT) layer neutral fashion what
the user application requires. MTS maps the users application’s requirements onto UT
layer services. It is assumed that the system engineer will assure that the available
services will meet the required services. Through this mechanism user applications can
be reused over different missions and over different hardware without modification.
Precedence
The order of precedence among QoS Parameters is TBD.
Priority Level
Priority is used to determine the order messages are delivered to receiving user
applications.
A global priority range used by all MTS user applications.
This range is mapped by MTS implementation onto the UT layer’s concept of priority.
This isolates User Applications from the priority schemes provided by the different
transport layer mechanisms.
The selection of priority range values used by User Applications shall be determined by
system analysis (e.g. Rate Monotonic Scheduling).
The global range shall be sufficiently large so as not to artificially restrict the range of
priorities used by a particular system.
All messages (from all senders to all recipients) are reordered as necessary such that
higher priority messages are delivered before lower priority messages.
Deadline
A message must be delivered to the receiver no later than the specified absolute time.
Latency
A message must be delivered to the recipient within the specified time delay.
The granularity shall not restrict the users by allowing both large and small delay values.
Jitter
A message must be delivered to the recipient, according the to specified Deadline or
Latency, within the time constraints delimited by the jitter time value.
The granularity shall not restrict the users by allowing both large and small offset values.
Guaranteed Delivery
The message shall be delivered to the recipient via a transport service that provides a
reasonable guarantee of message delivery.
1 of 4
SCF/AGV
687312352
The message is delivered using the current configuration settings of the transport layer
services (e.g. number of re-delivery attempts and/or timeout value).
Delivery Confirmation
A confirmation message is received by the sending user application indicating successful
receipt of a clearly identified previously sent message. The positive confirmation
message is provided by the MTS, and not by Transport Layer Services.
Bandwidth Allocation
The user application needs a bandwidth no less than N bytes per M seconds to deliver a
message.
Issue (Part 1): The problem this parameter is attempting to address is as follows: The
user application desires to send a large message (1024 x 1024 x 16 bit image) to a mass
storage device. The general system bus cannot support this traffic. There is a dedicated
link for the express use of this type of traffic. We want the MTS to use the dedicated bus
to transport this message. Reuse in a system with a general system bus with sufficient
resources would not require the use of a dedicated bus. The user application would be
the same in both scenarios. Therefore, we want a transportable solution and do not want
to use a “Use Dedicated Bus XYZ” parameter in the QoS.
Issue (Part 2): We need to discuss where in the set of primitives this parameter is
specified. Is this parameter set in advance of sending the message? OR Is this parameter
set at the time the message is sent?
Connection-less
By definition, QoS is associated with each message. If the recipient of a message is not
available, the sender receives notification when the message delivery attempt fails.
Connection-Oriented
QoS is associated with the link. The link is active for the duration of the connection. If
the connection is severed (e.g. one member of the connection vanishes) the remaining
member receives a notification indicating the termination of the connection.
Synchronous/Asynchronous
Issue 1: Scheduled/Non-Scheduled delivery. It should not be the responsibility of the
MTS to provide a service that delivers regular messages on a pre-determined timetable.
However, the MTS may be used to deliver messages in this manner.
Issue 2: Blocking/Non-Blocking. Whether the sender blocks or not should not be a QoS
parameter. It is an implementation/primitives issue. This item shall be removed from the
list of QoS parameters.
2 of 4
SCF/AGV
687312352
Buffer Allocation
Reservation of Buffer Space by the sender (at the receiver) is performed to ensure the
message can be stored once delivered.
For example: Zero Copy Protocol Stacks. The ownership of the buffer containing the
message transfers from the receiving driver to the recipient application.
Issue: Should this be one of the QoS parameters? Is this an implementation issue?
DRAFT
QoS Property List
Priority Level
Deadline
Latency
Jitter
Guaranteed Delivery
Delivery Confirmation
Bandwidth Allocation
Connection Ty pe
(connection-less/connection-oriented)
Asy nchronous/Sy nchronous
Buffer Allocation
DRAFT
Parameter Interaction
Priority and Deadline/Latency
Priority designs take into account both deadline and latency considerations of the system.
A specified deadline (or latency) most likely would conflict with the implemented
priority scheme. Systems should be designed so that one or the other (priority or
deadline/latency) governs scheduling of message delivery.
Deadline and Latency
Latency specifies a time offset from the time a message is committed for delivery. A
deadline beyond this offset is a conflict. While a deadline value could be specified that
occurs before the latency time has elapsed, such use would be redundant and should be
avoided. Because of the potential for conflict, system designs should use one or the
other.
3 of 4
SCF/AGV
687312352
Notes:
Management of the size of the receiving messages Queues is a SOIS management issue
and not a QoS parameter.
This approach will lend itself to the adaptation of future technology enhancements (e.g.
wireless technologies).
4 of 4
SCF/AGV