Summary

  • DCCP's CCID 2 reliably conveys reception information without retransmitting lost application data. Acknowledging a feedback packet lets the receiver retire old reporting state, not recover an old payload.
  • Bidirectional data normally carries the necessary acknowledgements. When one application stops sending, the remaining active sender must occasionally acknowledge pure feedback; quiescence involves both elapsed time and accounted-for reception history.
  • Losing the second acknowledgement prolongs retention rather than requiring a third acknowledgement. CCID 3 generally has bounded acknowledgement state and does not need the same arrangement.

A different packet for the next transmission

Consider the transition described in RFC 4340. A and B have been sending data in both directions. B then stops sending application data but continues receiving A's packets and reporting their arrival.

If A keeps sending only DCCP-Data, B lacks explicit confirmation that its reports reached A. The fact that more data arrives does not identify which report the sender has seen. With CCID 2, B uses Ack Vectors to convey reception history reliably. It needs a way to stop repeating history that A already knows.

A can therefore send a DCCP-DataAck instead of a DCCP-Data from time to time. The acknowledgement number identifies a packet from B, allowing B to connect that confirmation to information it previously sent. An ordinary forward transmission helps close a reverse reporting obligation.

This is not an instruction to send a separate control packet after every acknowledgement. Nor is it a concealed mechanism for restoring lost application data. The object being retired is the receiver's feedback history.

Reliability was a choice about an object

The March 2006 DCCP documents addressed applications that wanted congestion control without compulsory recovery of every old datagram. The problem statement in RFC 4336 discusses media whose playback moment has passed and game positions superseded by newer information.

For such an application, the next opportunity to transmit may be better spent on something current. Congestion control still determines when sending is permissible. The application wants to decide what information deserves that opportunity.

DCCP does not retransmit lost application data. An application may add selective reliability of its own, but the transport does not automatically turn an old missing payload into a debt that must be repaid before later content becomes useful.

The sender nevertheless needs evidence of loss and congestion marking. Under CCID 2, Ack Vectors reliably communicate reception information. Discarding the obligation to recover old content does not discard the obligation to learn about the path's losses and marks.

The distinction is the foundation of the acknowledgement-of-acknowledgement mechanism. Reliability belongs to a particular information exchange, not necessarily to every object carried through the connection.

The feedback had an address of its own

DCCP increments its sequence number for every packet, including a pure acknowledgement. These numbers count packets, not bytes. The feedback channel is consequently visible in the same numbering scheme: acknowledgement loss can produce a gap, and a received acknowledgement can itself be named.

The Acknowledgement Number field reports the greatest sequence number received. It is not TCP's next expected byte, and it does not declare every earlier packet received. Options supply information about the intervening history.

Ack Vector describes that history backwards from the acknowledgement number. Each byte contains two state bits and six run-length bits. The states distinguish Received, Received ECN Marked, a reserved value and Not Yet Received. A run length of zero covers one packet; 63 covers 64.

Compression can make a long stretch of identical observations inexpensive to describe. It does not establish that the observations have reached the sender. A compact history may still represent an open reporting obligation.

Numbering every packet also means that a sequence gap need not represent missing application content. With the appropriate feature enabled, NDP Count reports the immediately preceding run of non-data packets and helps interpret a loss burst. It does not provide a general count of lost payload bytes or a complete classification of every mixed burst.

Even Received has a bounded meaning. DCCP has processed the packet's options, making it acknowledgeable; the application need not have received its data. Data dropped in an application receive buffer still has the appropriate received state. The separate Data Dropped option can convey that additional fact. Otherwise an application-side problem could be misrepresented as a packet that never arrived across the network.

How a history acquired an exit

RFC 4340 distinguishes reception information whose delivery the receiver knows has been acknowledged from information it has reported without that knowledge, and information not yet reported. The latter two groups make up the Acknowledgement Window. New arrivals extend it; acknowledgements of previous reports move its older boundary forward.

Without this exit, a CCID 2 receiver might repeatedly report history reaching back to the connection's beginning. Sending a report once is not enough to discharge a reliable reporting duty over a lossy path.

The CCID 2 profile, RFC 4341, makes the active sender's responsibility explicit. It must occasionally acknowledge the receiver's acknowledgements and should do so at least once per congestion window. When both applications fall silent, the sender may wait arbitrarily long.

That qualification matters. A quiet application on one side does not mean that the other side's active stream has no feedback housekeeping to perform. Conversely, two quiet applications need not manufacture a perpetual conversation simply to announce their silence.

Ordinary bidirectional traffic often conceals the work by providing packets on which to carry it. The transition to unidirectional data exposes the dependency. The mechanism is about a change in opportunities to settle state, not a universal demand for more acknowledgements.

The second acknowledgement could be lost

Reliable feedback appears to invite an infinite sequence. If a report needs an acknowledgement, does the acknowledgement need another one?

DCCP stops the recursion by assigning a different consequence to the loss of the second-level message. The receiver simply holds and repeats its old state longer. It does not mistakenly learn that it may erase information still unknown to the sender.

The acknowledgement of the acknowledgement therefore need not be reliable itself. There is no requirement for an acknowledgement of an acknowledgement of an acknowledgement.

This is not a claim that repeated loss is harmless. Retention consumes state; repetition consumes capacity; delayed feedback affects control. The design puts that uncertainty into an extended existing cost instead of turning it into a new absolute delivery obligation.

The distinction also identifies the memory being freed. It belongs to the receiver's reporting machinery. No lost application datagram is resurrected, and no promise about application consumption is created by releasing that history.

Quiet required more than a clock

CCID 2's quiescence test uses the greater of 0.2 seconds and two round-trip times. But the elapsed interval is only part of the condition. The sender must also have acknowledged receiver Ack Vectors covering all the data packets received.

A period without new data does not by itself close the account of past data. If the RTT is unknown, the specified default RTT is 0.2 seconds, making the two-RTT term 0.4 seconds. Calling this a fixed 200-millisecond idle timer loses both the arithmetic and the additional condition.

The directions can use different congestion-control profiles. The B-to-A CCID defines when B has become quiescent; the A-to-B CCID defines how A handles acknowledgements of acknowledgements after that transition. A single undifferentiated connection-idle label cannot express the whole decision.

An old confirmation must not erase new news

The non-normative implementation example in RFC 4340's Appendix A.3 associates a sent acknowledgement's sequence number with the reception history it represented. When that acknowledgement is itself acknowledged, the receiver can retire corresponding old records.

Now suppose a packet arrives after a report said it was missing. The sender may acknowledge that old report before receiving the new arrival information. Clearing everything associated with the old report could erase a fact the sender has not yet learned.

The appendix illustrates limiting the retirement boundary to protect that new information. It does not require every implementation to use its precise buffer structure. Its lesson is about the relationship between a report and the knowledge it actually carried.

Reordered reports need similar care. A later-arriving report may describe an earlier absence. The specification gives rules for combining states rather than allowing an old missing indication to overwrite known receipt indiscriminately. Arrival order is not automatically information order.

Another profile had a different memory problem

RFC 4342 defines CCID 3 using TCP-Friendly Rate Control. Smoother changes in sending rate come with slower response to changes in available capacity. The base DCCP specification says its acknowledgement state is generally bounded, so the same acknowledgement-of-acknowledgement requirement is unnecessary. That does not make CCID 3 stateless or free of feedback obligations.

Its Verified errata sharpen another distinction between receiving a control packet and obtaining useful new information. Receive Rate refers to the last RTT, not the entire interval since the previous feedback packet. In the specified case where no data was sent in the relevant interval, a sender may ignore a second Receive Rate option, but must not then reset the nofeedback timer.

The RFC 4340 errata also matter when reading the original text. They correct, among other things, an example that wrongly made zero Ack Ratio invalid and editorial details in the appendix. In 2018, RFC 8311 removed ECN Nonce discussion from three DCCP congestion-control profiles. Historical descriptions of the 2006 design should not turn its unamended nonce prose into present operating advice.

The 2012 UDP encapsulation specification, RFC 6773, addressed compatibility with some middleboxes that supported UDP but not native DCCP. It did not add reliable delivery of application data. The IANA parameter registry identifies the profiles and their assignments; it does not measure deployment.

These sources establish neither a current market share nor a universal performance gain. They establish a narrower piece of transport history: an unreliable data service could depend on reliable reception knowledge, and that knowledge needed an explicit way to stop occupying the receiver's future.