TCP-Friendly Multicast Congestion Control (TFMCC): Protocol Specification
Note: This ballot was opened for revision 07 and is now closed.
Magnus Westerlund Yes
(Jari Arkko) No Objection
(Ross Callon) No Objection
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.
(Lisa Dusseault) No Objection
(Lars Eggert) No Objection
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  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.
(Ted Hardie) No Objection
(Russ Housley) No Objection
(Cullen Jennings) No Objection
(David Kessens) No Objection
(Dan Romascanu) No Objection
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