Платой за более стабильную пропускную способность по сравнению с TCP в условиях конкуренции за полосу является более медленная реакция TFRC на изменение доступной полосы пропускания. Таким образом, TFRC следует использовать лишь в тех случаях, когда приложениям требуется стабильная пропускная способность и, в частности, предотвращение двукратного снижения скорости передачи, принятого в TCP в ответ на отбрасывание одного пакета. Для приложений, которым просто нужно передать данные за возможно кратчайшее время, рекомендуется использовать TCP или, в тех случаях, когда надежность не требуется, механизм контроля насыщения AIMD с параметрами, близкими к тем, которые применяются в TCP.
Механизм TFRC разработан для приложений, которые используют пакеты фиксированного размера и меняют скорость передачи таких пакетов в ответ на возникновение перегрузок (насыщения). TFRC может также использоваться, возможно с менее оптимальной производительностью, в приложениях, не использующих фиксированный размер сегмента и меняющих его в соответствии с потребностями приложения (например, видео-приложения).
Для некоторых приложений (например, звуковых) требуется обеспечение фиксированного интервала времени между передачей последовательных пакетов и варьирование размера сегментов (вместо изменения скорости передачи пакетов) в ответ на возникновение перегрузки. Механизм контроля насыщения, предложенный в этом документе, для таких приложений не подходит, однако эту задачу решает механизм TFRC-PS, являющийся вариантом TFRC для приложений с фиксированной частотой передачи и изменением размера пакетов при возникновении насыщения. Спецификация TFRC-PS содержится в [RFC4828].
Механизм TFRC основан на работе принимающей стороны с расчетом параметров контроля насыщения (частоты фактов потери пакетов) на стороне получателя, а не отправителя. Такой способ хорош для приложений, в которых отправителем является большой сервер, обслуживающий множество одновременных соединений, а получатели имеют достаточно памяти и процессорных ресурсов для выполнения требуемых расчетов. Кроме того, реализованный на приемной стороне механизм лучше подходит для контроля насыщения в системах с групповой адресацией. Однако возможна реализация TFRC на серверной стороне, как в профиле CCID-3 протокола DCCP [RFC4342].
Этот документ отменяет действие RFC 3448. В транспортном протоколе DCCP [RFC4340] профили CCID-3 [RFC4342] и CCID-4 [CCID-4] задают использование TFRC в соответствии с RFC 3448. Разработчикам CCID-3 и CCID-4 следует использовать этот документ взамен RFC 3448 для спецификации TFRC.
Нормативная часть спецификации TFRC приведена в главах 3 - 6. В главе 7 рассматриваются реализации механизма на серверах, в главе 8 — вопросы реализации механизма, а в главе 9 рассмотрены отличия от RFC 3448.