Subject: RFC 4410 - errata and issues

From: Alfred Hönes <[email-masked]>
Date: Mon, 14 Aug 2006 18:33:24 +0200 (MESZ)

Hello,
in the recently published RFC 4410 (Selectively Reliable Multicast)
authored by you, I found a couple of issues that perhaps should be
addressed by an RFC Errata Note and/or in a future update to the memo.

I use change bars ('|' in column 1) and tag lines to mark issues
/ changes.  Proposed (changed) text is re-adjusted to conform with
RFC formatting rules.

(1)  [contradiction in specification]

The last paragraph of Section 2, on page 6 of RFC 4410, says:

   SRMP is intended for general use under applications that need its
                             vvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvv
|  services and may exist in parallel instances on the same host.  The
   UDP port is therefore established ad hoc from available application
   ports; accordingly, it would not be appropriate to have a well-known
   port for SRMP.

Contrary to that, the first paragraph of Section 4.7, on page 15,
says:
   vvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvv
|  Each host will have a single instance of SRMP supporting all of its
   applications.  Thus, the sender's source rate is the sum of the rates
   of all the clients of the same multicast group.

What's true ?   What's been intended ???

(2)  [simple erratum: inconsistent spelling]

At the bottom of page 7, Section 3.2 says:

   Receiver_Timestamp:
|     16 bits   Echo of the Receiver_Time_Stamp field (in milliseconds)
                of the receiver feedback message.  If the sender has
                time delay between receiving the feedback and echoing
                the timestamp, it MUST adjust the Receiver_Timestamp
                value to compensate.

To adjust with the diagram on top of page 7 and the remainder of the
text, 'Receiver_Time_Stamp' should be spelled out 'Receiver_Timestamp'
here as well.
Thus, the RFC should say:

   Receiver_Timestamp:
|     16 bits   Echo of the Receiver_Timestamp field (in milliseconds)
                of the receiver feedback message.  If the sender has
                time delay between receiving the feedback and echoing
                the timestamp, it MUST adjust the Receiver_Timestamp
                value to compensate.

(3)  [inconsistent message layout - danger of interoperability problems]

The diagram of the Bundle Header Format (Section 3.2, on page 7),

      0              8              16             24             32
      +--------------+--------------+--------------+--------------+
      |Version| Type |fb_nr | flag  |        bundle_SN            |
      +--------------+--------------+--------------+--------------+
      |                       Sender_ID                           |
      +--------------+--------------+--------------+--------------+
      |                       Receiver_ID                         |
      +--------------+--------------+--------------+--------------+
      |       Sender_Timestamp      |    Receiver_Timestamp       |
      +--------------+--------------+--------------+--------------+
      |            ...                                            |

and the diagram of the Feedback Message Format (Section 3.3, on page 9),

      0              8              16             24             32
      +--------------+--------------+--------------+--------------+
      |Version| Type | fb_nr| flag  |             X_r             |
      +--------------+--------------+--------------+--------------+
      |       Sender_Timestamp      |    Receiver_Timestamp       |
      +--------------+--------------+--------------+--------------+
      |                       Sender_ID                           |
      +--------------+--------------+--------------+--------------+
      |                      Receiver_ID                          |
      +--------------+--------------+--------------+--------------+

show a surprising inconsistency in the order of the (otherwise
comparable) words {Sender_ID, Receiver_ID, S/R_Timestamps} .
I suspect that this might give rise to implementation faults,
leading to interoperability problems.
It better would have been avoided from the beginning by using
the same order of the fields.

BTW: It strikes that in Section 3.2, the sequence of the field
explanations does not agree with the order in the diagram (as is
the case throughout the remainder of the RFC); instead, the
explanations of just those four fields is given in the order
of the diagram and explanation sequence in Section 3.3.
Therefore, the reader could be lead to the conjecture that the
diagram in Section 3.2 is in error and in fact should be aligned
with the diagram in Section 3.3.

(4)  [simple erratum: word twister]

In Section 3.6, near the top of page 12, the RFC says:

   Length:
      16 bits  Length of the payload data in octets (does not the
               include header).

It should say:

   Length:
|     16 bits  Length of the payload data in octets (does not include
|              the header).

(5)  [simple errata: inconsistent terminology]

Contrary to the remainder of the RFC text, Section 3.7 uses the
field name "Sender Address".  To avoid the unfortunate embedded
space character, and to align this section with the remainder
of the RFC, the term "Sender_ID" should be used.
Therefore:

a) the diagram on page 12,

      0              8              16             24             32
      +--------------+--------------+--------------+--------------+
      |Version| Type |111 |  00000  |          reserved           |
      +--------------+--------------+--------------+--------------+
      |                            DSN                            |
      +--------------+--------------+--------------+--------------+
|     |                      Sender Address                       |
      +--------------+--------------+--------------+--------------+

should be corrected to say:

      0              8              16             24             32
      +--------------+--------------+--------------+--------------+
      |Version| Type |111 |  00000  |          reserved           |
      +--------------+--------------+--------------+--------------+
      |                            DSN                            |
      +--------------+--------------+--------------+--------------+
|     |                         Sender_ID                         |
      +--------------+--------------+--------------+--------------+

b) the explanation (at the bottom of page 12),

|  Sender_ID:
|     The IP address of the sender of the message being NACKed.

should be corrected to say:

|  Sender_ID:
|     The ID of the sender of the message being NACKed.

See also item (6) below for the full rationale.

(6)  [incomplete specification - IPv4-centric]

In Section 4.2, the second paragraph on page 14 says:

   Also, the bundle length MUST NOT exceed LENGTH_MAX.  If adding a new
   SRMP message will produce a greater length, the SRMP daemon MUST
   initialize a new bundle for the new SRMP messages, and the current
|  bundle should be transmitted immediately.  The recommended value for
|  LENGTH_MAX is 1454 bytes (Ethernet MTU minus IP and UDP header
|  lengths).

Similarly, the first paragraph of Section 4.6, on page 15, says:

   TFMCC is designed for traffic with a fixed message size.  The maximum
|  bundle size (including header) for SRMP is set to a configurable
|  maximum, typically 1454 bytes (Ethernet MTU minus IP and UDP header
|  lengths).  The bundle size will be used in a TCP throughput equation,
   to get a desired source rate.  However, in SRMP, the message size is
   variable because:

Without mention, the marked phrases are strictly IPv4-centric;
they do not apply to the case of IPv6.

The latter scenario is not excluded in the text, and the phrase,
"IPv4 addresses may be used." in the description of all Sender_ID
and Receiver_ID fields supports the suspicion that IPv6 in fact
was intended to be supported.

Please supply improved wording for both text fragments.

(7)  [simple erratum: grammar (singular/plural mismatch)]

The first paragraph of Section 5, on page 17, says:

   SRMP operates in three distinct transmission modes in order to
   deliver varying levels of reliability: Mode 0 for multicast data that
|  does not require reliable transmission, Mode 1 for data that must be
   received reliably by all members of a multicast group, and Mode 2 for
   data that must be received reliably by a single dynamically
   determined member of a multicast group.

It should say:

   SRMP operates in three distinct transmission modes in order to
   deliver varying levels of reliability: Mode 0 for multicast data that
|  do not require reliable transmission, Mode 1 for data that must be
   received reliably by all members of a multicast group, and Mode 2 for
   data that must be received reliably by a single dynamically
   determined member of a multicast group.

Rationale: "data" *is" plural.

Please comment.

I propose that you resolve the open issues and submit an
Author's Errata Note to the RFC Editor, making freely use
of the material presented above.

Best regards,
  Alfred Hönes.

-- 

+------------------------+--------------------------------------------+
| TR-Sys Alfred Hoenes   |  Alfred Hoenes   Dipl.-Math., Dipl.-Phys.  |
| Gerlinger Strasse 12   |  Phone: (+49)7156/9635-0, Fax: -18         |
| D-71254  Ditzingen     |  E-Mail:  [email-masked]                     |
+------------------------+--------------------------------------------+