TCP-Friendly Multicast Congestion Control (TFMCC): Protocol Specification
draft-ietf-rmt-bb-tfmcc-07

I am concerned by the total lack of information related to manageability in such a document. This document is a building block definition according to RFC 3048, which stipulates:

'Most building blocks should also have a management API, through which it communicates to SNMP and/or other management protocols.'

However no information is provided in the document about the existence or need or lack of need for such a management API. 

I would expect to find in this document a management considerations section including: 

- management data model ( for configuration, status, performance monitoring, faults, etc.)
- will there be any notifications associated with the congestion control mechanism?
- what type of management operations are allowed (read-write? read-only, asynchronous notifications?)
- recommended management protocols (SNMP? other?)
- liveness detection and monitoring
- impact on network operations

Section 1.1., para. 1:

In this document, the key words "MUST", "MUST NOT", "REQUIRED", "SHALL",
"SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and
"OPTIONAL" are to be interpreted as described in BCP 14, RFC 2119 [2]
and indicate requirement levels for compliant TFMCC implementations.

        Cites RFC2119 but does not use the terms at all.

Section 2., para. 9:

The dynamics of TFMCC are sensitive to how the measurements are
performed and applied and what feedback suppression mechanism is chosen.
We recommend specific mechanisms below to perform and apply these
measurements.  Other mechanisms are possible, but it is important to
understand how the interactions between mechanisms affect the dynamics
of TFMCC.

        The transmission dynamics also depend on the dynamics of
        group membership. Imagine a group with high-bandwidth connections
        to the source, where a single low-bandwidth sink repeatedly enters
        and leaves the group. (Yeah, scenario is a bit constructed, I
        admit.)

Section 2.2., para. 2:

As TFMCC will be used along with a transport protocol, we do not specify
packet formats, since these depend on the details of the transport
protocol used.  The recommended representation of the header fields is
given below.  Alternatively, if the computational overhead of a floating
point representation is prohibitive, fixed point arithmetic can be used
at the expense of larger packet headers.

        It seems important to point out that for a specific instance
        of TFMCC use, sender and receivers need to agree on ONE specific
        encoding for the fields/pieces of information below.


Section 20, para. 0:

o A timestamp ts_i indicating when the packet is sent.  The resolution
  of the timestamp should typically be milliseconds and the timestamp
  should be an unsigned integer value no less than 16 bits wide.

        Nit: Proposed encoding can only represent values of ~65
        seconds, which is less than the MSL. Is that an issue?

o A receiver ID r and a copy of the timestamp tr_r' = tr_r of that
  receiver's last report, which allows the receiver to measure its RTT.
  If there is a delay ts_d between receiving the report from receiver r
  and sending the data packet, then tr_r' = tr_r + ts_d is included in
  the packet instead.  The receiver ID is described in the next section.
  The resolution of the timestamp echo should be milliseconds and the
  timestamp should be an unsigned integer value no less than 16 bits
  wide.  If separate instead of piggybacked congestion control messages
  are used, the packet needs to contain a list of receiver IDs with
  corresponding timestamps to allow a sufficient number of receivers to
  simultaneously measure their RTT.  For the default values used for the
  feedback process this corresponds to a list size on the order of 10 to
  20 entries.

        Nit: See previous comment.
        Also, the "10 to 20 entries" seem to impose some upper bound on
        receiver sets that can reasonably be supported. Some thoughts on
        this may be good.

Section 2.2.2., para. 2:

o A unique receiver ID r.  In most cases the receiver ID will be
   supplied by the transport protocol, but it may simply be the IP
   address of the receiver.

        IP addresses as IDs are NOT guaranteed to be unique when NATs
        are in the path (RFC1918 addresses). Also, what about multiple
        sessions to the same receiver?

Section 4.2., para. 1:

A receiver that sends feedback but wishes to leave the TFMCC session
within the next feedback round may indicate the pending leave by setting
the receiver_leave flag in its report.  If the leaving receiver is the
CLR, the receiver_leave flag should be set for all the reports within
the feedback round before the leave takes effect.

        Could this somehow be used as an attack vector? What if an
        attacker always sets receiver_leave but never leaves? (Just
        wondering.)

Section 6., para. 4:

It is possible that a receiver sends feedback claiming it has a very low
calculated rate.  This will reduce the rate of the multicast session and
might render it useless but obviously cannot hurt the network itself.

        Well, it can't hurt the network, but it destroys the service
        provided by the session. This is more serious for a multicast session
        than for a unicast session, because an attacker can interfere with
        service delivered to others. Some thoughts on how this can be
        mitigated may be good.

Lars has noted section 6, paragraph 4: 

    It is possible that a receiver sends feedback claiming it has a very 
    low calculated rate.  This will reduce the rate of the multicast 
    session and might render it useless but obviously cannot hurt the 
    network itself.

Rendering the multicast session useless seems like an issue. It 
seems to me that for any application for which there is a minimum
bandwidth that is needed for performance to be "acceptable", then 
there should be some level that if a receiver can't keep up with it,
it will withdraw from the multicast group. On the other hand, this 
is the sort of thing that would come up in an experiment, and thus
publishing this as "experimental" seems okay to me.