[e2e] How many TCP flows fit in the Internet?
detlef.bosau at web.de
Sun Mar 31 04:10:24 PDT 2013
I got some criticism on my post yesterday, so I think I should elaborate
at least on one point.
However, a general remark in the beginning. I have a strong focus on TCP
here. Of course, TCP is neither the only protocol in the world nor the
only one that may cause grief in some circumstances. The distinguishing
property of TCP is responsiveness. TCP reacts upon packet loss, which is
seen as load indicator, by reducing the load offered to the network. In
TCP, responsiveness is (mainly) achieved by protocol means while for
other protocols, e.g. voice streaming, responsiveness is often left to
the application. It makes hence sense to have a look at TCP and
understand how congestion, buffer bloat etc. can be handled and take
this as a model for other protocols.
Back to the point.
Am 30.03.2013 15:29, schrieb Detlef Bosau:
> Among all strategies of congestion control, in VJCC I miss the real
> establishment of the two by far most obvious.:
> In case of congestion
> 1. reduce the rate of existing flows. (In VJCC and actually existing
> TCP Implementations we hardly can reduce a flow's rate beyond
> 1MSS/CWND. Exept perhaps by employing a pacing scheme, however I'm not
> quite clear yet about possible consequences.)
Yesterday, I was told TCP can well reduce it's rate beyond 1 MSS/CWND.
Now, to my understanding this is not possible with the pure sliding
window mechanism itself. A TCP socket must not send anything else than a
"complete TCP frame", with our without payload. It cannot send, say,
"two bytes only". So a congestion window of, say, 3 bytes or less
wouldn't make any sense.
Of course, the GOODPUT (and that's what I was pointed to yesterday) can
be arbitrarily low: In case of a packet being not acknowledged in time a
sending socket does it's usual time out handling, including a timer backoff
RTO *= 2;
So, when a switch along the path cannot forward a packet due to
insufficient queue capacity, the packet remains unacknowledged and is
hence retransmitted. So, while the switch delivers the net from the
"overload" imposed by this packet (the packet is dropped) the sender
will repeat this packet over and over, until a user defined time out is
exceeded or the packet is eventually acknowledged.
This reduces GOODPUT.
it causes additional network load, i.e. by retransmissions.
So, we have the classical choice between Skylla and Charybdis here.
Either we drop packets - and cause retransmissions, or we add buffer
space to the switch and allow for buffer bloat. In the first case, the
perceived goodput is reduced by timer back off, in the second case the
rate CWND/RTT is reduced by increasing the RTT by increasing the
queueing latency. Neither of these is a reasonable reduction of
THROUGHPUT which deliveres the network from load.
As I said above, I don't discuss ping or voice streams or online games
here, resource sharing, load control and congestion control in non
responsive protocols is left to the application.
70565 Stuttgart Tel.: +49 711 5208031
mobile: +49 172 6819937
detlef.bosau at web.de http://www.detlef-bosau.de
More information about the end2end-interest