RFC-793 Section 3.7, page 42 (original) (raw)

Connected: An Internet Encyclopedia
4.2.2.17 Probing Zero Windows: RFC-793 Section 3.7, page 42

Up: Connected: An Internet Encyclopedia
Up: Requests For Comments
Up: RFC 1122
Up: 4. TRANSPORT PROTOCOLS
Up: 4.2 TRANSMISSION CONTROL PROTOCOL -- TCP
Up: 4.2.2 PROTOCOL WALK-THROUGH

Prev: 4.2.2.16 Managing the Window: RFC-793 Section 3.7, page 41
Next: 4.2.2.18 Passive OPEN Calls: RFC-793 Section 3.8

4.2.2.17 Probing Zero Windows: RFC-793 Section 3.7, page 42

Probing of zero (offered) windows MUST be supported.

A TCP MAY keep its offered receive window closed indefinitely. As long as the receiving TCP continues to send acknowledgments in response to the probe segments, the sending TCP MUST allow the connection to stay open.

DISCUSSION:

It is extremely important to remember that ACK (acknowledgment) segments that contain no data are not reliably transmitted by TCP. If zero window probing is not supported, a connection may hang forever when an ACK segment that re-opens the window is lost.

The delay in opening a zero window generally occurs when the receiving application stops taking data from its TCP. For example, consider a printer daemon application, stopped because the printer ran out of paper.

The transmitting host SHOULD send the first zero-window probe when a zero window has existed for the retransmission timeout period (see Section 4.2.2.15), and SHOULD increase exponentially the interval between successive probes.

DISCUSSION:

This procedure minimizes delay if the zero-window condition is due to a lost ACK segment containing a window-opening update. Exponential backoff is recommended, possibly with some maximum interval not specified here. This procedure is similar to that of the retransmission algorithm, and it may be possible to combine the two procedures in the implementation.

Next: 4.2.2.18 Passive OPEN Calls: RFC-793 Section 3.8

Connected: An Internet Encyclopedia
4.2.2.17 Probing Zero Windows: RFC-793 Section 3.7, page 42