[evla-sw-discuss] MIB Data Port Spec revisions

[Bill Sahr]

Concerning the email of 10/28/2003 in which 4 changes
were proposed for the MIB Data Port Spec.

All four changes have been accepted.  The changes and
some of the consequences are given below.


1. It has been proposed that we encode DDRs in XML
    rather than the proprietary format that is now a
    part of the spec.

There were no comments received either for or against this
change.  Given the past emails exchanges on this topic,
the lack of comments is taken to mean that the majority
of the EVLA software group supports this change, and that
the remainder have no severe objections.

Acceptance of this change will require a complete rewrite
of the MIB Data Port Spec.  Since the MIB software team
is developing the XML schema describing the XML encoded
DDR, the rewrite of the MIB Data Port Spec will become
a part of their charge.

The move to XML encoding raises the issue of the need
to transmit DDRs that cannot be accommodated within
the MTU (maximum transmission unit) of an ethernet network.
(According to Stevens, the Ethernet MTU is 1500 bytes  I
will not get into a discussion, in this note of the path
MTU).  Many of us were of the opinion that fragmentation
is not handled by UDP, and the answer to this issue would
be to transmit XML fragments, each with enough header info
to constitute a standalone bit of XML.  Spurred by the
assertion from Rich Moeser that he had received UDP packets
from the CMP that exceeded the MTU and that he had not
needed to do fragment reassembly I consulted several
references.  Happily, both the 1st and 2nd editions of
Stevens, _UNIX Network Programming_ and an O'Reilly book
entitled _Internet Core Protocols_ (by Eric A. Hall) are
unequivocal and unambiguous in asserting that neither TCP
nor UDP need concern themselves with fragmentation,
and that fragmentation is handled at the IP layer.
The O'Reilly book does add the warning that some UDP
stacks require that applications have large enough
buffers to accept the entire datagram or it will be
discarded.  The 2nd edition of Stevens adds the further
caution that some implementations of UDP do not return
the ENOBUFS error if there is insufficient space in the
datalink output queue for the datagram or its fragments
and the message is silently discarded without being
transmitted.  Additionally, and a separate issue, is
the fact that the SO_SNDBUF socket option can be used
to change the upper limit on the maximum sized UDP
datagram that can be written to the socket.  If this
limit is violated, the EMSGSIZE error is returned.

2. A revision to the DDR format has been proposed.
    For the revised format:
    - the Attention and Length fields have been dropped
      (separate ports will be used instead of an Attention
       bit, and the Length field is seen as unnecessary)
    - the Antenna ID will be a STRING
    - the Device ID will be a STRING

Barry proposed a possible alternative but it does not
work well if we move to XML encoding.


3. An alert record type will be added to the MIB Data
    Port Spec.  The format of the alert message is simply
    a minor variant on the DDR format - the ARRAY of
    monitor points is replaced by a STRING containing
    the text of the alert.  All other DDR fields will
    be present.

This proposal has also been accepted with a modification
to the format of an alert message.  The planned implementation
is that the DDR will contain a field stating whether or not an
alert has been asserted for the monitor point in question,
and that an alert message is simply the XML encoded DDR with an
alert asserted.   A DDR with the alert asserted will be sent as
soon as the alert condition is detected, and a DDR with the alert
not asserted will be sent as soon as the alert condition is cleared.
DDRs sent between these two transitions will 1) be sent at the
current rate in effect for that monitor point, and 2) always
indicate that an alert has been asserted, which implies that
client software must always examine the DDR for asserted alerts.


4. A revision has been proposed to the MONITORPOINT
    record that consists of changing the monitor point
    ID from a SHORT (two byte integer) to a STRING.

Accepted without debate.  Compatible with XML encoding.