[e2e] tcp connection timeout

[Joe Touch]

Vadim Antonov wrote:
...
>> If there are no costs for listening, I see no problem here.
> 
> There always costs.  They may be small (like keeping a TCB), they may be
> large (like keeping 20Mb of state in RAM), they may be intolerable - but
> there are always some, and you do not have any idea of the costs imposed
> on the remote end.

Please explain the 20MB case.

AFAICT, that only happens when the receiver window is 20MB, AND:

	a) the received data has a hole in it, notably at least
	at the beginning, and 20MB of other stuff backed up waiting
	for retransmission

		in that case, TCP *WILL* timeout due to a number
		of failed ACK retransmissions

	b) the received data does NOT have a hole in it,
	but the application has not yet retrieved the data

		in this case, if TCP were to 'timeout',
		the application would be interrupted
		unnecessarily

Based on the above, *IF* you have 20MB associated with a connection, TCP
should not be timing-out on that connection.

I.e., the only case where it *might* be appropriate to timeout due to
idleness is the case where the receive buffer is empty. It seems
feasible to have TCP release those buffers in that case, at which point
the only space an idle TCP connection should hold is the TCB, which
isn't that large.

If a system cannot hold a large number of TCBs, then the application
should be cleaning them up themselves. Or a background OS process can go
around doing this. But this isn't TCP's job.

Joe