ic is TCP-based (and the rest is UDP) because the dominant type of traffic is from the WWW and Web-based services, including here also video and picture sharing sites, and other mul- timedia sharing websites. TCP congestion control mechanisms assure maximal utiliza- tion of bottleneck (Figure 2.7), SO TCP traffic flow consumes all available bitrate (i.e. bandwidth) which is limited by the bottleneck anywhere on the end-to-end path of the packets. If there are 10 TCP file downloads (e.g. Web based) over a 10 Mbit/s link (as a bottleneck link), then after enough time each of the TCP flows will have up to approx- imately 1/10th of the total available bandwidth (i.e. bitrate). TCP mechanisms do not allow TCP to use 100% of any link bandwidth because CWs in most TCP implementa- tions are never constant - either they rise until a packet loss occurs, or they decrease after losses (e.g. due to fast retransmission and fast recovery, or due to TCP timeout and then slow start phase). TCP mechanisms at the end-hosts are completely independent of the functions of the network nodes (e.g. switches and routers) and hence accidentally may cause congestion. That results in long queues without a control mechanism (under assumed heavy congestion at the given network node). The congestion creates back-to-back packet losses, which may trigger two or more losses in a given TCP CW (for each TCP connection which goes through that congestion bottleneck). This arises from multiple loss behavior of TCP, and may result in TCP timeouts and entering the slow start phase, which results in higher oscillations in the bitrate of a given connection. In an attempt to avoid multiple packet losses from a single TCP connection as much as possible, network nodes (such as routers) implement random discard of packets (from various positions in the buffer queue) when the buffer is filled over a certain upper congestion threshold (e.g. 80% filled buffers). Summarizing Internet congestion, it is mainly due to TCP, which is implemented and controlled by end-u