MPI/RT Wish List

Kelvin Nilsen (kelvin@newmonics.com)
Mon, 09 Dec 1996 22:41:01 -0600

At the MPI/RT meeting last week, I expressed several preferences regarding
"improvements" to the MPI/RT standard. In general, Arkady suggested that
such requests should be brought to the attention of the larger group by way
of this mail list.

Here they are:

1. In order to provide good performance for a reasonable price, I believe
it is important to allow applications to make use of network resources
that cannot always be guaranteed. (Yes, I understand that certain
critical activities need guaranteed quality of service, but there are
many examples of real-time applications for which variable quality of
service is perfectly reasonable.) Here are some of the ways in which
I would like to specify the service quality of a channel:

a) At minimum, transmit Xm messages of Ym bytes each in each period of
N msec. On average, transmit Xa messages of Ya bytes each in each
period of N msec.

b) In each period of N msec, transmit Xm messages of Ym bytes each
with probability .99 of having such messages delivered (on time).
If the message can't be delivered on time, throw it away.

c) In each period of N msec, allow me to transmit, on average, Xm
non-time-constrained messages with probability .95 that all Xm
messages will be delivered. (If the messages being corrupted in
transit, additional network resources will be required to correct
the problem. One out of every twenty periods on average, something
less than the full Xm messages will be delivered.)

d) This channel will be idle 99% of the time. However, once out of
every 100 (on average) periods, this channel will have a message
that must be transmitted with very high priority. (Note that
idle channels can be combined with average/minimum service quality
channels to support good average-case performance and guaranteed
minimal functionality to handle "emergencies.")

Note that I'm not asking for the system to allow messages to be delivered
late.

2. Once a channel has been allocated, I'd like to be able to "manage" how
the channel is used. For example:

a) Individual messages might be prioritized as they are queued for
transmission. The low-level network driver will transmit queued
messages in prioritized order.

b) At the receiver node, the receiving task may prioritize its
processing of messages that are queued for reception. This
prioritization can be implemented as a combination of sender
priorities and guard conditions.

c) A sender might queue a time-constrained message with a parameter
that states the message's deadline for arrival at its destination.
If the message cannot be delivered prior to the specified deadline,
the system should not deliver the message at all. As an
optimization, the sending node should discard the message without
even attempting to transmit it as soon as it discovers that there
is insufficient time remaining to meet the message's deadline.

--
Kelvin Nilsen, President                   voice: 515-296-0897
NewMonics Inc.                               fax: 515-296-9910
2501 N. Loop Dr., Suite 614A          http://www.newmonics.com
Ames, IA  50010                       email: kdn@newmonics.com