TCP Rate Implicit Control (TRIC) Nicolas Rouhana University Saint-Joseph – Lebanon
[email protected] Abstract Current congestion control mechanisms in today’s Internet rely on end-to-end TCP congestion avoidance algorithms that back off sources when congestion occurs, detected by packet loss or explicit congestion notification signals. But one of the major setbacks of such mechanisms is making sure that all sources respond correctly in applying congestion avoidance measures during periods of high congestion; non-compliant sources can aggravate the network congestion state and yield to unfairness, worsening the state of the network. In this paper, we propose a network -centric solution for congestion control – called TRIC (TCP Rate Implicit Control), that shapes the behavior of TCP from the edge of the network, using TCP’s window manipulation and ACK pacing, based on backward explicit congestion notification in ACK packets going back to the source, generated by routers experiencing incipient congestion in the forward path. We also present simulation results that show how TRIC helps improve the throughput of TCP.
1. Introduction Congestion management has always been a major concern at the IETF [1], and there is consensus that continued use of end-to-end congestion control by besteffort traffic is critical for maintaining the stability of the Internet. Today’s Internet success has relied extensively on end-to-end TCP’s congestion management mechanisms [2], which were the keys that prevented its “meltdown”. Although TCP is an end-to-end protocol, there is a limit to how much control can be accomplished from the edges of the network [3], and some mechanisms are needed in the routers to complement the endpoint congestion avoidance mechanisms. Explicit Congestion Notification (ECN) [4], associated with RED (Random Early Detection) [5], is a proposition that improves TCP throughput by having intermediate routers detect incipient congestion and explicitly inform the TCP source to throttle its data rate before any packet loss occurred. However,
Eric Horlait University Pierre et Marie Curie – France
[email protected] ECN uses “forward” feedback-based congestion control systems that do not scale well with respect to network bandwidth and delay, and the larger the end-to-end delay in a network, the longer until the end-point can determine that the network has become congested [6]. Furthermore, deployment of ECN in the Internet relies on modifications in both hosts TCP stack and routers software. While modifications in routers (which count in tens or hundreds) have a more rapid introduction to the Internet, changes at host ends (which count in hundreds of millions) constitute a lengthy and timely process, and widespread deployment of ECN is not considered likely in the near future. We propose in this paper a network-centric scheme for congestion control called TRIC (TCP Rate Implicit Control) that does not require any modifications to the end-hosts, reduces the control delay that feedback congestion control systems exhibit, and improves TCP’s throughput. TRIC extends RED and ECN concepts by employing “backward” congestion notification generated by TRIC core routers in returning ACKs to the TCP source. Ingress TRIC routers respond to these ECN-ACKs by modifying the content of the window field of packets going to the source, hence controlling TCP’s rate. The next section motivates our proposition in this area. Section 3 gives a functional description of TRIC, and section 4 describes the internal architecture of the nodes as implemented in the Network Simulator [7] and shows preliminary simulation results. We present enhancements to TRIC in section 5 and finally conclude in section 6.
2. Motivation The popularity of the Internet has caused a proliferation in the number of TCP implementations. Some of these may fail to implement the TCP congestion avoidance mechanisms correctly because of poor implementation [8]. Others may deliberately have congestion avoidance algorithms that are more aggressive in their use of bandwidth than other TCP implementations; this would allow a vendor to claim to have a “faster TCP”. The logical consequence would be a spiral of increasingly aggressive TCP implementations, leading back to the point where there is effectively no congestion avoidance and
Sender
Receiver
cwnd = 15 Data, ECT=1 Data, ECT=1
. . .
S2’s goodput decreases in favor of an increase of S1’s goodput.
S1 S2
S1 & S2 ECN-compliant 1,220 976 kbps packets 630 504 kbps packets
S1 not ECN-compliant S2 ECN-compliant 1,310 1,048 packets kbps 560 packets 448 kbps
Table 1. Resulting goodputs of S1 and S2 This is clear by looking at the evolution of the congestion windows in S1 and S2 are also reproduced respectively in figures 3 and 4. When S1 is not complying with ECN, cwnd of S2 gets halved more often, yielding in less throughput at the source, while cwnd of S1 increases linearly, despite the reception of ECN bits. 60 - line: ECN compliant flow + line: non-ECN compliant flow
50
Congestion window
the Internet is chronically congested. Worse, a “malicious” user can disable congestion control of his TCP, and hence may receive more bandwidth than other TCPs that use congestion control. If we consider end-to-end ECN in TCP [4], the effectiveness in improving overall network throughput will be apparent only after ECN has been widely adopted and that all the TCPs comply and cooperate to the new standard. Figure 1 illustrates how a misbehaving ECN endhost advertises its ECN capability (by setting the ECN Capable Transport ECT bit to 1 in outgoing packets), but chooses to disregard returning ECN-echo bits set by the receiver in the ACKs, and continues to inflate its congestion window, a behavior that would potentially yield to congestion and packet drops. Normally, a sender reaction to the indication of congestion in the network (when it receives an ACK packet that has the ECN-Echo flag set) should be equivalent to when there is a congestion loss in NON-ECN-capable TCP, i.e. the sender halves the congestion window cwnd and reduces the slow start threshold ssthresh.
40
30
20
CE=1 10
ACK + ECN-echo cwnd = 16
0 0
1
2
3
congestion
4
5 Time (sec)
6
7
8
9
10
Figure 3. Evolution of congestion window in S1 25 -
Figure 1. Congestion with non-compliant ECN sources
S1
10Mbps 2ms
10Mbps 4ms
R1 S2
10Mbps 3ms
1.5Mbps 20ms
S3
R2 10Mbps 5ms
S4
Figure 2. Simulation network If we consider a user point of view, table 1 clearly shows unfairness between S1 and S2 in the second case,
20
Congestion window
In the following example, we show an aspect of unfairness amongst two competing TCP flows, both setting the ECT bit in outgoing IP packets, but only one end-system actually reacting to ECN-Echo bits. The network configuration shown in figure 2 uses two TCP sources S1 and S2 connected to two sinks S3 and S4. Two types of simulations are run; in the first, both S1 and S2 are ECN-compliant sources; and in the second, S1 does not react to ECN-echo bits. Source S2 is activated 2.5 seconds after S1.
line: 2 ECN compliant flows
+ line: 1 ECN compliant flow
15
10
5
0 3
4
5
6
7
8
9
10
Time (sec)
Figure 4. Evolution of congestion window in S2 From a network point of view, figure 5 shows the effect on the average queue length in router R1, which has a much higher occupancy when S1 disregards ECN notifications.
14 1 non ECN-compliant flow All ECN-compliant flows
Average queue size (pkts)
12
Unmark ECT
Mark ECT
10
Sender
RED
Edge TRIC router
Core TRIC router
Unmark CE W=C/2
Mark CE
Edge TRIC router
Receiver
8
6
4
W 2
0 0
1
2
3
4
5
6
7
8
9
10
Figure 6. Backward ECN applied in TRIC
Time (sec)
Figure 5. Average queue length The queue has a higher occupancy, leaving less space to absorb bursts of traffic. As a result, more control is needed in order to make all the TCP hosts comply with congestion management standards, because misbehaving TCPs could seriously jeopardize the congestion avoidance scheme. The next section introduces our TRIC mechanisms, which is a network-based control of the TCP senders that protects the network against the above behavior, by allowing the network to control the entering TCP traffic.
3. TRIC mechanisms Our TRIC proposal for congestion management builds on RED and ECN mechanisms, by providing a reaction mechanism to congestion similar to ECN [4] (i.e., halving congestion window cwnd of the source TCP), but instead of having core nodes mark congestion notifications on outgoing packets towards the destination when congestion is experienced, core TRIC nodes use the ACK packets traveling towards the source for backward congestion notifications, presenting a more rapid way for feedback control. A TRIC router experiencing congestion performs RED, but the router marks in that case an outgoing ACK to the source with a Congestion Experienced (CE) bit flag – if the ECT bit is set in the forward packet; otherwise, the router discards the selected packet. This is illustrated in figure 6: the ingress TRIC node sets the ECT bit in the IP header of data packets for that flow, to indicate that this flow participates in TRIC; otherwise this bit is set to 0. This would ensure protection of TRIC flows against potential dropping inside the network. The ECT bit is set on all packets other than pure ACKs. When a subsequent TRIC core router has decided from its active queue management mechanism to mark a packet, it sets the CE bit in the IP header of an ACK from the backward path belonging to the same connection.
In order to limit the TCP source rate, the basic idea in TRIC is to manipulate, at the edge of the network, the content of the window field (W) in the ACK packets going to the source. For this purpose, the ingress node implements a sub-set of a chosen TCP standard, e.g. Tahoe [2], Reno [11], etc. No retransmission or packet reordering TCP functions are needed at the ingress. The ingress node maintains state information about individual TCP connections, giving it the possibility to track the packet flow of the TCP connection, and maintains an internal variable C that holds the correct value of the congestion window that we would want the source to maintain. The ingress node intercepts returning ACK packets, modifies the content of the window field W in the header of the ACK packet by fixing it to the value of C, and then sends the packet to the source. This ensures that the source will be conforming to the congestion window scheme adopted at the ingress, and allows the network to be protected against a TCP source that “inflates” its cwnd improperly, and the network provider can “dictate way end-to-end TCPs should react. Below is part of the resulting algorithm applied at the ingress for each TCP connection: for each returning ACK(seq_no, W, ecn) if (ecn) ssthresh
