Кратко

  • В CCID 2 отсутствие новых данных в течение заданного интервала — лишь одно условие покоя. Отправитель также должен подтвердить векторы, охватывающие все принятые данные.
  • Подтверждение отчёта позволяет получателю освободить старое состояние обратной связи. Оно не заставляет DCCP повторно передавать потерянные данные приложения.
  • Потеря второго подтверждения продлевает хранение, поэтому третье надёжное подтверждение не требуется. У CCID 3 другая организация состояния, и та же обязанность на него не переносится.

Вторая половина условия

В разделе 6.2.1 RFC 4341 время ожидания T выбирается как большее из 0,2 секунды и двух времён оборота пакета. Но истечение T без новых данных само по себе не доказывает покой направления.

Получатель должен также знать, что отправитель подтвердил Ack Vectors, охватывающие все полученные пакеты данных. Таймер проверяет отсутствие нового движения, а подтверждения — состояние уже накопленной истории. Это разные сведения, и одно не заменяет другое.

Даже число 0,2 секунды нельзя превратить в универсальный порог. Если RTT неизвестно, используется его значение по умолчанию 0,2 секунды; тогда два RTT составляют 0,4 секунды. Упрощение до «после 200 миллисекунд соединение молчит» теряет и расчёт, и второе условие.

Зачем такая аккуратность протоколу, который не гарантирует доставку данных? Потому что незавершённая обязанность относится не к самим данным, а к сведениям об их приёме.

Устаревшее содержимое не обязательно нужно возвращать

RFC 4336, опубликованный в марте 2006 года, описывал приложения, которым требовалась перегрузочная дисциплина без обязательного восстановления каждого потерянного фрагмента. Звук, пришедший после момента воспроизведения, может уже не пригодиться. Старые координаты в игре могут уступать по ценности текущим.

Приложение хотело выбирать содержимое следующей дейтаграммы, когда сеть позволит её отправить. Ограничение скорости и выбор полезной информации решают разные задачи. DCCP не повторяет потерянные данные приложения, хотя приложение может добавить собственную избирательную надёжность.

При этом отправителю необходимы сведения о потерях и отметках перегрузки. В CCID 2 они передаются надёжно. Можно отказаться от восстановления старого содержимого и всё же быть обязанным сообщить, что происходило с потоком на пути к получателю.

Таким образом, ненадёжная передача данных не означает отсутствие надёжных служебных обязанностей. История приёма нужна, чтобы управлять последующей отправкой, а не чтобы собрать заново всё прошлое содержимое.

Номер есть и у самой квитанции

RFC 4340 присваивает очередной номер каждому пакету DCCP, включая чистое подтверждение без данных приложения. Последовательность считает пакеты, а не байты. Благодаря этому можно обнаружить потерю подтверждений и указать, какой именно отчёт дошёл.

Поле Acknowledgement Number сообщает наибольший полученный номер. Оно не обещает, что все меньшие номера тоже получены. Для описания промежутков существуют отдельные опции. Читать это поле как кумулятивную границу байтов TCP было бы ошибкой.

Ack Vector начинает описание с указанного номера и движется к более старым пакетам. Два бита байта задают состояние, шесть — длину серии одинаковых состояний. Нулевой код длины означает один пакет, значение 63 — 64 пакета. Состояния различают приём, приём с отметкой ECN, резерв и отсутствие пакета к моменту наблюдения.

Длинная однородная история может занимать немного места. Но сжатый отчёт не становится от этого завершённым. Пока получатель не знает о доставке своих сведений отправителю, у него остаётся причина хранить и повторять их.

Есть и обратная сторона общей нумерации. Пропуск номеров может содержать только управляющие пакеты. При включённой соответствующей функции NDP Count сообщает длину непосредственно предшествующей серии пакетов без данных и помогает разобраться с таким пропуском. Это не универсальный счётчик утраченных байтов приложения.

Что именно считается полученным

Для состояния приёма достаточно, чтобы DCCP обработал опции пакета и мог его подтвердить. Данные ещё не обязательно переданы приложению. Если они отброшены в его приёмном буфере, пакет всё равно сообщается с подходящим состоянием приёма; дополнительная опция Data Dropped позволяет описать произошедшее точнее.

Так перегрузка приложения не превращается задним числом в утверждение, что сеть вообще не доставила пакет. Разделение нужно не ради осторожной формулировки, а ради правильного входного сигнала для управления передачей.

Номер пакета, сетевой приём, служебная обработка и работа приложения — разные границы. Обратная связь полезна, пока не приписывает себе доказательную силу за пределами той границы, которую действительно наблюдает.

Когда обратное направление больше не помогает

Пока обе стороны передают данные, подтверждения отчётов обычно входят в обычный обмен. Но если B прекращает отправку данных приложения, продолжая принимать поток от A, эта удобная симметрия исчезает.

B всё ещё посылает Ack Vectors. A может продолжать передавать DCCP-Data, не сообщая B, какие отчёты дошли. Само продолжение отправки не доказывает получение конкретного сообщения обратной связи.

Поэтому RFC 4341 требует от активного отправителя время от времени подтверждать подтверждения получателя. Можно заменить один из DCCP-Data на DCCP-DataAck. Рекомендованная частота — как минимум раз за окно перегрузки, а не отдельный новый пакет немедленно после каждого подтверждения.

Когда обе стороны перестают отправлять данные, отправитель может ждать сколь угодно долго. Это не разрешение активному потоку игнорировать правила своего профиля. Просто существование новых данных меняет значение задержки в освобождении истории.

У направлений могут быть разные CCID. Профиль направления B–A задаёт, когда B считается затихшим; профиль A–B определяет, как A после этого подтверждает отчёты B. Одного общего признака «соединение простаивает» для такой логики недостаточно.

Память освобождается не по возрасту

Получатель различает сведения, доставку которых отправитель уже подтвердил, сведения, о доставке которых ещё нет уверенности, и ещё не отправленные сведения. Последние две группы образуют окно подтверждения. Оно растёт с новыми приёмами и сокращается с подтверждениями прежних отчётов.

Без такого сокращения CCID 2 мог бы повторять историю от самого начала соединения. Подтверждение отчёта завершает часть обязанности сообщать прошлое. Оно не восстанавливает потерянную дейтаграмму приложения: такой обязанности DCCP на себя не брал.

Второе подтверждение не обязано доставляться надёжно. При его потере получатель просто хранит и повторяет состояние дольше. Неопределённость сдвигает освобождение в более поздний момент, а не провоцирует преждевременное удаление. Поэтому надёжная третья ступень не нужна.

У этого решения остаётся цена: память, размер будущих отчётов, нагрузка на обратный путь. Но цена выражается в продлении существующего состояния, а не в бесконечной последовательности новых обязательств доставки.

Поздний пакет меняет допустимую границу

В ненормативном примере приложения A.3 к RFC 4340 запись связывает номер отправленного подтверждения с той частью истории, которую оно представляло. Ответ отправителя позволяет освободить соответствующие старые сведения.

Однако пакет может прийти после отчёта о его отсутствии. Если затем приходит подтверждение старого отчёта, отправитель ещё знает только об отсутствии. Новое знание о прибытии не было ему передано.

Нельзя уничтожать его лишь потому, что старый отчёт подтверждён. Пример показывает, как ограничить границу освобождения, чтобы новая информация сохранилась до передачи. Он не предписывает всем реализациям одинаковый буфер, но раскрывает, от чего должна зависеть очистка: от подтверждённого знания другой стороны, а не только от номера или возраста записи.

Перестановка самих отчётов создаёт близкую проблему. Более поздний по времени прихода отчёт может содержать более старое представление о пропуске. Правила объединения состояний не позволяют такому сообщению произвольно отменять уже известный приём.

У другого профиля иная цена памяти

RFC 4342 определяет CCID 3 на основе TFRC. Этот вариант стремится к более плавной скорости и медленнее реагирует на изменение доступной полосы — такова описанная в документе плата за сглаживание. Базовая спецификация отмечает, что его состояние подтверждений обычно ограничено, поэтому тот же механизм подтверждения подтверждений не нужен. Это не отсутствие памяти или обратной связи.

Проверенные исправления RFC 4342 уточняют, что скорость приёма относится к последнему RTT, а не ко всему времени после предыдущего отчёта. В предусмотренном случае интервала без данных отправитель может проигнорировать вторую опцию Receive Rate, но тогда не должен заново запускать таймер отсутствия обратной связи. Прибытие управляющего пакета не обязательно означает поступление полезного нового измерения.

Исправления RFC 4340 устраняют, в частности, ошибочный пример с якобы недопустимым нулевым Ack Ratio и редакционные неточности приложения. В 2018 году RFC 8311 исключил обсуждение ECN Nonce из трёх профилей DCCP. Исторический текст 2006 года нельзя без оговорок выдавать за актуальную инструкцию.

RFC 6773 в 2012 году добавил инкапсуляцию в UDP для определённых ограничений промежуточных устройств. Она не сделала передачу данных надёжной. Реестр IANA фиксирует идентификаторы, но не измеряет распространённость протокола.

Эти источники не дают сегодняшней доли использования, универсального выигрыша скорости или истории конкретного продукта. Они позволяют увидеть более узкий результат: ненадёжный поток может нуждаться в надёжной истории, а закончить её хранение иногда можно только совместным действием двух сторон. Таймеру недостаточно тишины, потому что прошлое ещё могло остаться недосказанным.