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

[Ballot comment]
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.

[Ballot comment]
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

[Ballot comment]
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.

1.a Personally reviewed by Lorenzo Vicisano, who believes that the
    document is ready for IESG review and is shepherding it.

1.b We believe that the document has received adequate WG review and
    external scientific review (conference publication).

1.c No special-review concerns

1.d No

1.e It represent the consensus of the active WG members

1.f No.

1.e Checked against ID Nits. Notes:

    - The document does not explicitly split Normative and
      informative references, but explicitly states which references
      are informative.
    - The IPR sections are left to be added to the RFC editor

1.h The reference are not split. All ID reference are normative,
    except the first (NORM), that is specified to be informative.

Technical Summary (straight from the introduction)
==================================================

This document specifies TCP-Friendly Multicast Congestion Control
(TFMCC). TFMCC is a source-based, single-rate congestion control
scheme that builds upon the unicast TCP-Friendly Rate Control
mechanism (TFRC) (*). TFMCC is stable and responsive under a wide
range of network conditions and scales to receiver sets on the order
of several thousand receivers.  To support scalability, as much
congestion control functionality as possible is located at the
receivers.  Each receiver continuously determines a desired receive
rate that is TCP-friendly for the path from the sender to this
receiver.  Selected receivers then report the rate to the sender in
feedback packets.

TFMCC is a building block as defined in RFC 3048.  Instead of
specifying a complete protocol, this document simply specifies a
congestion control mechanism that could be used in a transport
protocol such as RTP, in an application incorporating end-to-end
congestion control at the application level. This document does not
discuss packet formats, reliability, or implementation-related issues.

TFMCC is designed to be reasonably fair when competing for bandwidth
with TCP flows.  A multicast flow is ``reasonably fair'' if its
sending rate is generally within a factor of two of the sending rate
of a TCP flow from the sender to the slowest receiver of the multicast
group under the same network conditions.

In general, TFMCC has a low variation of throughput, which makes it
suitable for applications such as streaming media where a relatively
smooth sending rate is of importance.  The penalty of having smooth
throughput while competing fairly for bandwidth is a reduced
responsiveness to changes in available bandwidth.  Thus TFMCC should
be used when the application has a requirement for smooth throughput,
in particular, avoiding halving of the sending rate in response to a
single packet drop.  For applications that simply need to multicast as
much data as possible in as short a time as possible, PGMCC (**) may be
more suitable.

WG Chair Note:

(*) TFRC is the unicast counterpart of TFMCC, published as RFC 3448
(**) PGMCC is another Congestion-control BB that RMT is planning to
    publish.

WG Summary
==========

The WG planned to publish TFMCC as an experimental document first, an
request its publication as a Standard-track document later, for the
reason Stated above:

Statement of Intent

  This memo contains part of the definitions necessary to fully
  specify a Reliable Multicast Transport protocol in accordance with RFC
  2357.  As per RFC 2357, the use of any reliable multicast protocol in
  the Internet requires an adequate congestion control scheme.  This
  document specifies an experimental congestion control scheme.  While
  waiting for initial deployment and experience to show this scheme to
  be effective and scalable, the IETF publishes this scheme in the
  "Experimental" category.

  It is the intent of the Reliable Multicast Transport (RMT) Working
  Group to re-submit the specification as an IETF Proposed Standard as
  soon as the scheme is deemed adequate.

The WG requests that the above note be added at the end of
the document "Introduction", as done for other similar WG
publications.

No abnormal situation were encountered by the WG regarding this
document.

Protocol Quality
================

The algorithm described in this protocol is based on its Unicast
counterpart (TFMCC) published as IETF RFC 3448. It was extensively
tested through simulations by the authors and by others (Mark Pullen
and associates, see RMT WG archives), that provided feedback based on
their independent simulations. The feedback has been addressed by the
authors.

We know of at least one successful implementation of TFMCC by Brian
Adamson, who incorporated it in its implementation of the RMT "NORM"
protocol and who also provide feedback to the authors.