Receiver capacity differs from path capacity
A TCP receive window advertises a range of acceptable sequence numbers. The sender accounts for outstanding data and window position before sending more, while application consumption affects subsequent buffer availability.
Congestion control responds to load on a shared network path using applicable loss, delay or explicit-marking feedback. Both constraints can apply at once: a large receive window does not justify unlimited sending, and congestion tuning cannot make an application consume its buffers.
References: [1]
A zero window differs from a failed connection
A receiver can advertise zero space for ordinary new data without declaring the connection dead. TCP zero-window probes allow a sender to discover a later reopening even if an update was lost.
Window scaling negotiates interpretation parameters during connection establishment so larger windows can be represented. It neither creates memory nor removes probing and resource obligations; a larger numeric range is not extra physical capacity.
Limits can apply per stream and per connection
QUIC limits stream data both individually and across a connection, raising credit through MAX_STREAM_DATA and MAX_DATA. A sender must obey both levels rather than bypass connection capacity through many individually compliant streams.
These advertise cumulative boundaries such as byte offsets, not additive grants each time an identical frame arrives. Flow-control limits also differ from the permitted number of concurrent streams; permission to open a stream is not unlimited data credit.
References: [3]