Summary

  • RFC 3155 treated an end-to-end TCP loss signal as ambiguous. Duplicate acknowledgements, a sequence hole or a timeout could justify a safe congestion response, but none proved whether congestion, transmission error, reordering or acknowledgement loss caused the event.
  • Fast Retransmit/Fast Recovery, SACK, D-SACK and NewReno could shorten or refine repair without suspending congestion control. They described what arrived and how to recover; they did not label the physical cause of what did not arrive.
  • The durable evidence chain runs from path and link observations through sender inference, window change, retransmission, receiver reassembly and application outcome. A recovered byte stream is not automatically a performance benefit.

One absence had several possible authors

TCP did not watch a radio symbol, a queue and an application transaction at once. Its sender watched acknowledgement progress. When the next expected sequence number failed to advance, the sender could see a symptom: a hole existed somewhere in the ordered byte stream. The network did not normally attach a reliable explanation.

That uncertainty had helped keep the Internet stable. Congestion control assumed that packet loss usually meant congested buffers and reduced the sending rate. In the environment for which the rule had matured, that was a productive approximation. By 2001, however, terrestrial wireless, satellite and other imperfect links were making uncorrected transmission errors a more visible part of some end-to-end paths.

A corrupted packet could disappear before TCP received it. A link-layer retry could delay or reorder it. An acknowledgement could be lost on the return path. A routing change could reorder later segments around it. A congested queue could discard it. Several of these events could produce duplicate acknowledgements or silence at the sender.

RFC 3155 did not claim to solve classification. It said the endpoint heuristics studied at the time had not reliably separated congestion losses from corruption losses. That negative result is the article's central historical fact. TCP had an observation and needed a response before it had a cause.

The safe mistake protected more than one flow

Treating corruption as congestion can be wasteful. A sender reduces its congestion window even though the path might have spare capacity. It then spends time increasing cautiously while the unreliable link, not a queue, remains the actual source of loss.

Treating congestion as harmless corruption is more dangerous. Congestion affects other traffic sharing the path. A sender that declines to slow down can deepen the queue, create more loss and help drive a region toward congestion collapse. RFC 3155 therefore kept the asymmetry explicit: without trustworthy feedback, avoiding congestion must take precedence over repairing a transmission error as quickly as possible.

The policy was not “every loss is congestion” as a statement of physical truth. It was “respond safely when the cause is unknown.” The first belongs to reality; the second to control. Confusing them makes a conservative algorithm look like a diagnostic instrument.

This distinction also limits retrospective claims. A congestion-window reduction proves the sender followed an inference rule. It does not prove a queue overflowed. A radio error counter rising near the same time is useful evidence, but it still has to be joined to direction, flow, sequence range and clock. A single counter cannot inherit the whole path.

The Reno equation was a boundary test, not an oracle

RFC 3155 included an approximate TCP Reno response function. It related sending rate to segment size, end-to-end round-trip time, retransmission timeout and steady-state packet loss probability. The calculation offered a practical question: at the observed loss rate, would the predicted TCP rate already exceed the link speed, or would loss response hold the connection below available capacity?

The inputs impose discipline. RTT is end to end, not merely the delay across the suspect link. The retransmission timeout has its own behavior; the RFC offered Max(1.0, 4*RTT) only as a simplifying substitution. Loss can be bursty, so an average across a long interval may hide the clustered events that cause several segments in one window to vanish.

If the predicted rate exceeds the physical link rate, improving TCP's loss recovery cannot make the link transmit faster than itself. If the prediction falls below link capacity and investigation finds significant transmission errors, endpoint improvements may help use more of what is available.

The model did not identify which packet a queue dropped or which bit a channel corrupted. Nor did it promise the modeled rate. It was a screening calculation whose result still depended on measured inputs, assumptions and the running sender.

Three duplicate acknowledgements bought time, not certainty

When a receiver obtains data beyond a missing sequence range, it immediately repeats the acknowledgement for the next byte it still expects. Three duplicate acknowledgements let a sender infer that a segment was probably lost while later traffic continued to arrive. Fast Retransmit then sends the missing segment without waiting for the full retransmission timer.

Fast Recovery preserves more momentum than a timeout. The sender halves its congestion window and continues through congestion avoidance rather than returning to the one-segment beginning of Slow Start. The duplicate acknowledgements show that some packets are still crossing the path. They support a less severe recovery action.

But they do not say what happened to the missing segment. IP may reorder packets. A link layer may retry a frame and deliver it late. A route may change. The receiver's repeated next-expected number is evidence about sequence arrival, not a sensor at the loss location.

The window can nevertheless enter what RFC 3155 called a downward spiral. If another loss occurs before additive increase restores the previous window, another halving acts on an already smaller value. Repeated events can hold the connection below path capacity for long periods. When the window stays below four segments, the sender may not emit enough following data to elicit three duplicate acknowledgements at all.

Not every small window indicts an error-prone link. Short HTTP transfers repeatedly closed trained connections and opened new ones in Slow Start. Application connection policy could therefore resemble a link problem in a window graph. Path evidence and application behavior had to be read together.

SACK described the holes without naming their maker

Ordinary cumulative acknowledgements state the next contiguous byte expected. They do not efficiently describe several separated ranges already held by the receiver. Selective Acknowledgement lets the receiver report those blocks, allowing the sender to repair multiple missing segments without discovering each new hole only after the previous one is filled.

RFC 3155 recommended SACK together with the duplicate-SACK extension in RFC 2883. D-SACK added evidence about duplicate data and was useful around reordering, acknowledgement loss, packet replication and early retransmission. On long-delay paths or in bursts that remove several segments from a large window, this richer receipt could save round trips and avoid unnecessary work.

The information remained about arrival. A SACK scoreboard could show that bytes before and after a range were present. It could guide retransmission. It could not state whether a congested router, a noisy channel or another mechanism removed the missing segment.

Where SACK could not be enabled at both endpoints, NewReno could handle partial acknowledgements and multiple losses more effectively than the older recovery behavior. Limited Transmit, then standards-track work for further evaluation, could send additional data so a small window had a better chance of producing the duplicate acknowledgements required for Fast Retransmit.

Each mechanism changed the recovery surface. None licensed a sender to ignore congestion safety. Faster repair was not causal knowledge.

A small MTU could slow training without curing error

Error-prone link layers often used small MTUs. Because TCP grew its congestion window in units of segments, smaller segments could slow the rate at which the window opened. But reducing the link MTU did not by itself make transmission reliable.

Path MTU Discovery helped avoid fragmentation and let endpoints use the largest packet the path supported. It could improve the pace of window growth compared with unnecessarily small packets, yet several round trips might still be needed before the window approached the path's delay-bandwidth product.

This was a different mechanism from RFC 3150's shared-link occupancy question. RFC 3150 asked how long one packet monopolized a slow link and delayed others. RFC 3155 asked how residual errors and ambiguous loss feedback held a TCP sender below usable path capacity. One concerned a packet's turn duration; the other concerned the sender's response to missing progress.

Combining them into “smaller packets are better on bad links” would erase both documents' conditions. Packet size changes serialization, header share, fragmentation exposure, segments per window and error probability in different ways. A recommendation needs the relevant receipt, not a slogan.

The endpoint path preserved encryption and inherited blindness

RFC 3155 deliberately focused on mechanisms that did not require a TCP-aware device in the middle. That preserved end-to-end operation and allowed the recommendations to continue through end-to-end IPsec. It also constrained what the endpoints could know about events between them.

Performance Enhancing Proxies could sit near a boundary where network characteristics changed and use local knowledge. RFC 3155 also repeated their costs: a third failure point, broken fate sharing, weaker end-to-end diagnostics, conflict with IPsec, state transfer during mobility, dependence on symmetric routing, scalability burdens and possible loss of QoS transparency. Not every proxy carried every defect, but the trade was serious.

The contrast was not endpoint purity versus evil intermediaries. It was a control boundary. An intermediary might gain local visibility by owning state and participating in the transport. Endpoints retained fate sharing and encrypted compatibility but could not see every local cause. RFC 3135 owns the fuller proxy history; RFC 3155 used that boundary to explain the limits of its recommendation.

ECN named congestion; it did not name transmission error

Explicit Congestion Notification was moving congestion feedback beyond inference from loss. A marked packet could tell an ECN-aware sender that congestion existed before a router discarded the packet. That improved the congestion signal when the path supported it.

RFC 3155 warned against reversing the meaning. ECN could not be used as explicit transmission-error notification. An unmarked loss was not therefore proven corruption. A missing or damaged packet might never deliver the header that would carry a mark; a damaged header could also make it difficult to identify the endpoint that should receive an error report.

The RFC regarded explicit transmission-error notification as useful future work, perhaps easier near a first-hop performance proxy. It did not define that mechanism. The distinction matters because a new signal should not be invented by interpreting the absence of another signal.

Recommendations and research questions occupied different columns

RFC 3155's immediate recommendations were conservative. Keep Slow Start and Congestion Avoidance. Implement Fast Retransmit and Fast Recovery. Use SACK and its duplicate-report extension. Where both endpoints could not use SACK, use NewReno to improve multiple-loss recovery.

Other ideas remained candidates. Delaying duplicate acknowledgements might prevent TCP retransmission while link-layer recovery was still working, but the document could not prescribe a safe delay for arbitrary topologies. Sender pacing and acknowledgement-rate control might reduce bursts. Appropriate Byte Counting could tie window growth more closely to bytes delivered, yet lost acknowledgements could make the resulting transmission burstier. Limited Transmit deserved evaluation.

Applications also shaped the result. Persistent HTTP connections could preserve a trained congestion window. Sharing congestion information across connections, as RFC 2140 and the Congestion Manager explored, could avoid treating every new transfer as an entirely ignorant path encounter.

Listing an idea under further work was not deployment evidence. A later standard was not proof that a 2001 endpoint implemented it. A TCP option offered by both endpoints was not proof that the running sender used it correctly during the event under study.

Recovery ended one receipt chain and began another

TCP promises an ordered byte stream. When a segment is missing, the receiver may hold later bytes but cannot deliver through the gap. A retransmission that fills the hole lets reassembly advance. That is a concrete success at the transport layer.

It does not retroactively name the loss cause. It also does not prove that the user obtained a timely result. A transaction can complete after its deadline, an interactive action can recover after the user abandons it, and a large transfer can finish while spending most of its life below available capacity.

The durable audit therefore retains the chain. It records path and application context; RTT, RTO, segment size, window and ACK behavior; sequence holes and timeouts; queue and ECN evidence; link errors, retries and reordering; the sender's chosen recovery; congestion-window evolution; SACK or D-SACK state; receiver reassembly; and the application's observed completion and timing.

RFC 3155's lasting lesson is not that TCP was wrong to slow down. It is that a safe control decision can be correct even when its diagnosis is incomplete. The sender saw loss. It acted for the shared Internet. Evidence still had to discover who caused the absence and whether the repair mattered.

Sources