Changes from draft-ietf-rmt-bb-tfmcc-01.txt:

* rephrased Section 2.2:

Before specifying the sender and receiver functionality, we describe
the congestion control information contained in packets sent by the
sender and feedback packets from the receivers.  Information from the
sender can either be sent in separate congestion control messages or
piggybacked onto data packets.  If separate congestion control
messages are sent at time intervals larger than the time interval
between data packets (e.g., once per feedback round), it is necessary
to be able to include timestamp information destined for more than one
receiver to allow a sufficient number of receivers to measure their
RTT.

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.

* Section 2.2.1, renamed to "Sender Packets" and added a the text below
  to "receiver ID and timestamp" paragraph

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.

* Section 3.2, changed reduction of the max. RTT:

... the maximum RTT is reduced to R_max = MAX(R_max * 0.9, R_peak)
where \fCR_peak\fR is the peak receiver RTT measured during the
feedback round.

* Section 3.3, changed no_feedback policy:

If the TFMCC sender receives no reports from the CLR for 4 RTTs, the
sending rate is cut in half unless the CLR was selected less than 10
RTTs ago. In addition, if the sender receives no reports from the CLR
for at least 10 RTTs, it assumes that the CLR crashed or left the
group.

* Section 3.4, added:

To allow receivers to suppress their feedback, the sender's
suppression rate needs to be updated whenever feedback is received.
This suppression rate has to be communicated to the receivers in a
timely manner, either by including it in the data packet header or, if
separate congestion control messages are used, by sending a message
with the suppression rate whenever the rate changes significantly
(i.e., when it is reduced to less than \fC(1-g)\fR times the previous
suppression rate).

* Section 3.4, fixed typo meesage -> message

* Section 3.5, rephrased:

Receivers measure their RTT by sending a timestamp with a receiver
report, which is echoed by the sender.  If congestion control
information is piggybacked onto data packets, usually only one
receiver ID and timestamp can be included.  If multiple feedback
messages from different receivers arrive at the sender during the time
interval between two data packets, the sender has to decide which
receiver to allow to measure RTT.  The same applies if separate
congestion control messages allow to echo multiple receiver timestamps
simultaneously but the number of receivers that gave feedback since
the last congestion control message exceeds the list size.

and removed the sentence

The receiver ID and the adjusted timestamp of the receiver with the
highest priority are then included in the next data packet.

* Section 4.1, fixed typo in title -> "Receiver Initialization"

* Section 4.3.2, added sender-based RTT measurement option

Optionally, sender-based instead of receiver-based RTT measurements
may be used.  The sender already determines the RTT to a receiver from
the receiver's echo of the sender's own timestamp for the calculation
of the maximum RTT.  For sender-based RTT measurements, this RTT
measurement needs to be communicated to the receiver.  Instead of
including an echo of the receiver's timestamp, the sender includes the
receiver's RTT in the next data packet, using the prioritization rules
described in Section 3.5.

To simplify sender operation, smoothing of RTT samples as described
above should still be done at the receiver.

* Section 4.3.3, added one-way delay adjustment with sender-based RTT measurement

The same one-way delay adjustments should be applied to the RTT
supplied by the sender when using sender-based RTT measurements.

fixed typo Inbetween -> In between

* Section 4.5, added: (i.e., 6 * R_max)

* Section 4.5, fixed typo cancelled -> canceled (4x)

* Section 5.6, fixed typo ususally -> usually

* Section 5.6, fixed typo Eqation -> Equation