Misbehaviors in SACK Generation

Transcription

1 Misbehaviors in SACK Generation Nasif Ekiz, Abuthahir Habeeb Rahman, Paul D. Amer Computer and Information Sciences Department University of Delaware Newark, Delaware {nekiz, abu, Abstract While analyzing CAIDA Internet traces of TCP traffic to detect instances of data reneging, we frequently observed four misbehaviors in the generation of SACKs. These misbehaviors could result in the data sender mistakenly thinking data reneging occurred. Further testing detected two additional SACK generation misbehaviors which in the worst case could result in a data sender receiving a SACK for data that was never received. This paper reports the results of testing a wide range of operating systems using TBIT to document which ones misbehave in each of the six ways. One can conclude that the handling of SACKs while simple in concept is complex to implement. Keywords- SACK; Selective Acknowledgement; TCP; TBIT I. INTRODUCTION The Selective Acknowledgment (SACK) mechanism, RFC 2018 [1], an extension to Transmission Control Protocol s (TCP) [2] ACK mechanism, allows a data receiver to explicitly acknowledge arrived out-of-order data to the data sender. When using SACKs, a TCP data sender need not retransmit SACKed data during the loss recovery period. Previous research [3, 4, 5] showed that SACK improves TCP throughput when there are multiple losses within the same window. The success of a SACK-based loss recovery algorithm [6] is proportional to the SACK information received from the data receiver. In this paper, we investigate RFC 2018 conformant SACK generation. Deployment of the SACK option in TCP s is an increasing trend. In 2001, 41% of the web servers tested were SACK-enabled [7]. In 2005, SACK-enabled web servers increased to 68% [8]. All of the operating systems tested in this study open SACK-enabled TCP s by default. Today s reliable transport protocols such as TCP and Stream Control Transmission Protocol (SCTP) [9] are designed to tolerate data receiver reneging (simply, data reneging) (Section 8 RFC 2018). Data reneging occurs when a data receiver SACKs data, and later discards that data from its receiver buffer prior to delivering it to the receiving application (or receiving socket buffer). In related research, we argue that reliable transport protocols should not be designed to tolerate data reneging, largely because we believe data reneging does not occur (or rarely occurs) in practice [10]. While conducting a study to investigate this belief, we analyzed TCP SACK information within Internet traces provided by the Cooperative Association for Internet Data Analysis (CAIDA) [11]. At first it seemed that data reneging was happening frequently. On closer inspection however, it turned out that the generation of SACKs in many TCP s was incorrect according to RFC Sometimes SACK information that should have been sent was not. Sometimes the wrong SACK information was sent. These misbehaviors wrongly gave the impression that data reneging was occurring. This observation led us to verifying SACK generation behavior of TCP data receivers for a wide range of operating systems. In this paper, our goal is to develop a methodology for verifying SACK behavior, and apply the methodology to report misbehaving TCP stacks. We first present in Section II four misbehaviors observed in the Internet traces. These misbehaviors can reduce the effectiveness of SACKs. To discover which implementations are misbehaving, we defined four test extensions to the TCP Behavior Inference Tool (TBIT) [12], a tool that detects TCP endpoint behaviors. The experimental setup using TBIT is described in Section III, and we present the results of the tests in Section IV. Section V introduces two additional SACK related misbehaviors observed during our TBIT testing. These misbehaviors are more serious. In the worst case, one misbehavior results in a data sender receiving a SACK for data that was never received, thus questioning the data transfer reliability of the. Finally Section VI identifies several methodologies used to infer TCP behavior, and Section VII concludes our work. II. TESTING SACK BEHAVIOR We present four TBIT tests designed to reproduce the four misbehaviors of TCP SACK generation observed during our data reneging investigation. We describe the observed SACK misbehaviors and present the corresponding TBIT tests in detail. The four observed SACK generation misbehaviors described as:

2 1. Fewer than maximum number of reported SACK blocks 2. Receiving data between Cum ACK and first SACK block 3. Receiving data between two previously reported SACK blocks 4. Failure to report SACKs during bidirectional data flow A. Fewer than maximum number of reported SACK blocks Misbehavior 1: RFC 2018 Section 3 specifies that the data receiver SHOULD include as many distinct SACK blocks possible in the SACK option, and that the 40 bytes available for TCP options can specify a maximum of four SACK blocks. For some TCP flows, we observed that at most two or sometimes three SACK blocks were reported by a data receiver even when additional space existed in the TCP header to append additional SACK blocks. SACK blocks at the data receiver are known to be more than two (say A l -A r, B l -B r, and C l -C r ) but only two SACK blocks are reported (A l -A r and B l -B r ). When the cumulative ACK advances beyond A r, SACK block A l -A r, is correctly no longer reported, and SACK block C l -C r is reported along with block B l -B r. This misbehavior implies that the data receiver reports at most two SACK blocks. Our first TBIT test, A, checks misbehavior 1. We extended existing TBIT test SackRcvr [12] to determine the maximum number of reported SACK blocks. The modified test operates with minimum number of TCP segments. For first three tests explained in this section, each TCP data segment generated by TBIT carries 1 byte of data for simplicity. The sequence number of data is given in parenthesis. The TBIT test, depicted in the Fig. 1, operates as follows: Test A 1. TBIT establishes a to the TCP Implementation Under Test (IUT) with SACK-Permitted option and Initial Sequence Number (ISN) TBIT skips sending 2 nd data packet (402) to create a gap at the TCP IUT, and sends 3 rd data packet (403) 7. TBIT skips sending 4 th data packet (404) to create a second gap at the TCP IUT, and sends 5 th data packet (405) 9. TBIT skips sending 6 th data packet (406) to create a third gap at the TCP IUT, and sends 7 th data packet (407) 10. TCP IUT acknowledges out-of-order data with SACK 11. TBIT skips sending 8 th data packet (408) to create a fourth gap at the TCP IUT, and sends 9 th data packet (409) 12. TCP IUT acknowledges out-of-order data with SACK 13. TBIT send three reset (RST) segments to abort the The last SACK from the TCP IUT reflects an implementation s support for maximum number of SACK blocks reported. Figure 1. Fewer than maximum number of reported SACK blocks A conformant SACK implementation s last SACK should be as the last SACK, highlighted in the rectangle, of Fig. 1. A misbehaving SACK implementation would lack either block B (Misbehavior 1a) or both blocks A and B (Misbehavior 1b). B. Receiving data between Cum ACK and first SACK block Misbehavior 2: RFC 2018 specifies that: If sent at all, SACK options SHOULD be included in all ACKs which do not ACK the highest sequence number in the data receiver's queue. So, a SACK block should be included when the cumulative ACK is increased and there is still out-of-order data in the receive buffer. For some TCP flows having at least two SACK blocks, we observed the following behavior. Once the data between the cumulative ACK and the first SACK block was received, the data receiver increased the cumulative ACK, but misbehaved and did not acknowledge any SACK blocks. (The acknowledgement with no SACK blocks implies an instance of data reneging.) Test B, described below and pictured in Fig. 2, checks this possible misbehavior. The second SACK block should remain present when the cumulative ACK is increased beyond the first SACK block but is less than the second SACK block. Test B 5. TBIT skips sending 2 nd and 3 rd data packets (402 and 403) to create a gap at the TCP IUT (the gap between Cum ACK and first SACK block), and sends 4 th data packet (404) 7. TBIT skips sending 5 th data packet (405) to create a second gap at the TCP IUT, and sends 6 th data packet (406) 9. TBIT sends 3 rd data packet (403) 10. TCP IUT acknowledges out-of-order data with SACK 11. TBIT sends 2 nd data packet (402) to fill the gap between Cum ACK and first SACK 12. TCP IUT acknowledges in order data with SACK

3 13. TBIT sends three reset (RST) segments to abort the Figure 3. Receiving data between two previously reported SACK blocks Figure 2. Receiving data between Cum ACK and first SACK block A conformant SACK implementation should report SACK block ( ) as shown in the last SACK in Fig. 2. A misbehaving SACK implementation would omit reporting the SACK block which could be interpreted as data reneging since the previously SACKed data are not reported anymore. C. Receiving data between two previously reported SACK blocks Misbehavior 3: We observed that some TCP flows report SACK information incompletely once the missing data between two SACK blocks (say A l -A r and B l -B r ) are received. The next SACK should report a single SACK block combining the first SACK block (A l -A r ), the missing data in between, and the second SACK block (B l -B r ). Instead some implementations generate a SACK covering only the first SACK block and the missing data, i.e., (A l -B l ) skipping the second SACK block. The SACK implies that the second SACK block is reneged. Test C, described below and pictured in Fig. 3, tests this misbehavior 3. The data receiver should report one SACK block covering the two SACK blocks and the data in between. Test C 5. TBIT skips sending 2 nd data packet (402) to create a gap at the TCP IUT, and sends 3 rd data packet (403) 7. TBIT skips sending 4 th data packet (404) to create a second gap at the TCP IUT, and sends 5 th data packet (405) 9. TBIT sends 4 th data packet (404) to fill the missing data between the first and the second SACK blocks 10. TCP IUT acknowledges out-of-order data with SACK 11. TBIT sends three reset (RST) segments to abort the A proper SACK implementation is expected to report the out-of-order data ( ) in the last SACK as highlighted in the Fig. 3. A misbehaving SACK implementation would report the SACK block partially ( ). D. Failure to report SACKs during bidirectional data flow Misbehavior 4: This odd behavior happens when the data flow is bidirectional. In some TCP flows, SACK information is not conveyed when the TCP segment carries data. If a TCP host is sending data continuously (e.g., an HTTP server), only one SACK is sent when out-of-order data are received, and SACK information is not piggybacked with the following data segments. This behavior can cause less efficient SACK-based loss recovery since SACKs are sent only one time for each outof-order data arrival. Test D verifies the proper SACK generation in this situation (misbehavior 4). As stated in Section IIB, a conformant data receiver should include SACK information with all ACKs. If ACKs are piggybacked while sending data, SACKs also should be included in the TCP segment. We added a new TBIT test for misbehavior 4. To have bidirectional data flow and out-of-order data simultaneously, we used HTTP/1.1 GET requests [13]. HTTP/1.1 permits a persistent between TBIT and a TCP IUT. TBIT requests the file index.pdf (11650 bytes) which is large enough to have a data transfer requiring several round trips so that SACK information can be observed in the data segments. Test D 3. TBIT sends 1 st data packet ( : GET /index.pdf HTTP/1.1 request) in order 4. TCP IUT acknowledges the in order data with ACK (450) 5. TCP IUT starts sending segments of index.pdf 6. TBIT skips sending 2 nd data packet (450) to create a gap at the TCP IUT, sends 3 rd data packet (451) 7. TBIT acknowledges data segments of the TCP IUT 9. TCP IUT continues sending segments of index.pdf with SACK 10. Once index.pdf is retrieved, TBIT sends three reset (RST) segments to abort the persistent

4 versions of OpenBSD report at most three SACK blocks (Misbehavior 1a). Windows 2000, XP and Server 2003 report at most two SACK blocks (Misbehavior 1b). Figure 4. Failure to report SACKs during bidirectional data flow A conformant SACK implementation appends SACK information in data segments as shown in Fig. 4. A misbehaving implementation would not. III. EXPERIMENTAL DESIGN The TBIT tests described in Section II were performed over a local area network where the loss rate was controlled (no loss is introduced). Tests were performed between two machines, A and B, as shown in Fig. 5. The round trip time was on average 10ms, and no other background traffic was present. TBIT 1.0 [12] was extended on FreeBSD 7.1 (machine A) with four TBIT tests detailed in the previous section. Support to view SACK information of incoming TCP packets was also added for the debug output mode. Packet dump utilities such as tcpdump [14] or wireshark [15] could not be run simultaneously with TBIT because of file access rights conflict with TBIT. The added support ensured that all the packets sent by TCP IUT were received by TBIT. The verified IUTs were the standard TCP stacks of various operating systems. We installed twenty five operating systems, reported in Section IV, using the Oracle s VirtualBox virtualization software [16] on machine B. We ran the tests for Mac OS X on different machines. For each operating system, we installed an Apache HTTP Server [17] on machine B since TBIT is originally designed to infer TCP behavior of a web server. The TCP packets transmitted between TBIT and each TCP IUT are captured at machine B due to the above restriction. For this purpose, we also installed wireshark on each Windows operating systems, and tcpdump on each UNIX or UNIX-like operating system IUT. IV. RESULTS We verified the operating systems in Table I. Each TBIT test was repeated three times on different dates. In every case, all three test outputs were consistent. Packet captures of tests can be downloaded [18]. For test A, fewer than maximum number of reported SACK blocks, the early versions of FreeBSD, 5.3 and 5.4, and all Figure 5. Experimental design If the return path carrying SACKs were lossless, a TCP data receiver reporting at most two or three SACK blocks would not cause a problem. A data sender would always infer the proper state of the receive buffer for efficient SACK-based loss recovery described in RFC 3517 [6]. When more than four SACK blocks exist at a data receiver, and SACK segments are lost, the chance of a data sender getting less accurate state of the receive buffer increases as SACK implementations number of blocks reported is decreased. This misbehavior then can lead to less efficient SACK-based loss recovery, and therefore decreased throughput (longer transfer times) when multiple TCP segments are lost from the same window. TABLE I. Operating System RESULTS FOR TBIT TESTS Test A B C D FreeBSD 5.3, 5.4 1a FreeBSD 6.0, 7.3, Linux (Debian 3) Linux (Red Hat 8) Linux (Fedora 1) Linux (Ubuntu 5.10) Linux (Ubuntu 6.06) Linux (Debian 4) Linux (Ubuntu 9.10) Mac OS X 10.5, OpenBSD 4.2, 4.5, 4.6, 4.7 1a OpenSolaris , Solaris Windows 2000, XP, Server b Windows Vista, Server 2008,

5 We report, for the test B, that Microsoft s Windows 2000, XP and Server 2003, are misbehaving. SACK information is not reported, where it should be, after the cumulative ACK is increased beyond the first SACK block. The least harmful misbehavior, misbehavior 3, is observed with Microsoft s Windows 2000, XP and Server SACK information is partially reported when the data between two previously reported SACK blocks are received. In conclusion, SACK based loss recovery would be less efficient for only the non-reported out-of-order data. The last misbehavior, misbehavior 4, is observed with all the versions of Microsoft s Windows operating systems. When the TCP traffic is bidirectional, SACKs are not carried within the opposite direction TCP data segments. Out-of-order data are SACKed only when they arrive. If a SACK is lost on the return path, subsequent data packets with no SACKs will trigger a fast retransmission which can cause the data sender to spuriously retransmit. The success of the SACK-based loss recovery algorithm is proportional to the SACK information received from the data receiver. More SACK information results in a more accurate data sender. Misbehavior 4 leads to a less efficient SACK-based loss recovery. The traffic pattern described in misbehavior 4 is a typical web browsing scenario. TBIT represents a user s web browser where HTTP 1.1 GET requests are pipelined, and the TCP IUT represents an HTTP 1.1 web server. Since the scenario represents typical Internet traffic, we believe that the SACK generation misbehavior of the Windows systems should be fixed. V. ADDITIONAL MISBEHAVIORS During the course of verifying SACK generation behavior using TBIT, we discovered two additional misbehaviors. A. SACK problem in Solaris TCP stack When verifying Solaris/OpenSolaris, we ran the previously discussed TBIT tests successively. TBIT tests A, B, C and D were run consecutively on different port numbers. We observed that SACK information of a prior, say from Test A, would appear in the SYN-ACK packet of a new, say from Test B! To further investigate the misbehaving SACK behavior in Solaris, we developed TBIT test E as shown in the Fig. 6, this test using the same initial sequence numbers for consecutive s: Test E on the ephemeral port Eph 1 on port TBIT skips sending 2 nd data packet (402) to create a gap at the TCP IUT, and sends 3 rd data packet (403) 7. TBIT sends three reset (RST) segments to abort the 8. After X minutes, TBIT establishes a to the TCP IUT with on the ephemeral port Eph 2 9. TCP IUT replies with SACK-Permitted option on port 80 including a SACK block of the previous In the second, TCP IUT sends an acknowledgement with SACK block which is from the first. The machine running TBIT assumes data with sequence number 403 is SACKed but the TCP IUT never received the data. According to RFC 2018, eventually the sender will timeout on data 403, turn off all of the SACKed bits and retransmit the data, thus getting back to the correct behavior. However for a brief period of time, the data sender and receiver are in an inconsistent state. We ran the Test E multiple times on Solaris 10 and OpenSolaris with different time intervals X = {1, 5, 15} minutes. We frequently observed the reappearance of SACK blocks from a prior in later s. When the initial sequence number spaces of two consecutive s overlap, the observed misbehavior could cause a SACK-based loss recovery based on incorrect SACK information. That would be cause a decrease in throughput since the data reported (will be recovered by a timeout) to be in the receive buffer is actually not there. One time, we ran all the four TBIT tests explained in Section II continuously and noticed a scenario where a SACK block of the first in Test A appeared in the SYN- ACK packet of the third established in Test C. One time, all four TBIT tests were executed and then repeated 45 minutes later. Even after 45 minutes, we observed an instance where the SACK block of Test D from the first set appeared in the SYN-ACK packet of Test D in the second set. We could not repeat this misbehavior with any regularity. Having a sender think data is acknowledged when in fact the data has not been received results in an inconsistent (i.e., unreliable) state. Figure 6. SACK related misbehavior in Solaris TCP

6 B. SACK related problem in Linux TCP stack A second SACK-related misbehavior is observed during Test D on OpenSolaris and Linux systems (except Linux (Ubuntu 9.10)). We explain the misbehavior using Fig. 7 that shows a smaller portion of the test D in detail. 3. TBIT sends 1 st data packet ( : GET /index.pdf HTTP/1.1 request) in order 4. TCP IUT acknowledges the in order data with ACK (450) 5. TCP IUT sends the 1 st data segment of index.pdf 6. TCP IUT sends the 2 nd data segment of index.pdf 7. When 1 st data segment from TCP IUT is received, TBIT skips sending 2 nd data packet (450) to create a gap at the TCP IUT, and sends 3 rd data packet (451) 8. TBIT acknowledges the 1 st data segment of the TCP IUT 9. TCP IUT acknowledges out-of-order data (451) with a SACK 10. When the acknowledgement for 1 st data packet of TCP IUT is received, TCP IUT s congestion window (cwnd) is increased and enables sending two new data packets. TCP IUT sends two data packets: 3 rd packet (1448 bytes) and 4 th packet (12 bytes) 11. TBIT acknowledges the 2 nd data segment of the TCP IUT 12. When the acknowledgement for 2 nd data packet of TCP IUT is received, TCP IUT s congestion window enables sending two more data packets. TCP IUT sends two data packets: 5 th packet (1448 bytes) and 6 th packet (12 bytes) Figure 7. SACK related misbehavior in Linux TCP TCP implementations of Linux and OpenSolaris misbehave when a data receiver has its own data to send along with its SACK information. When an acknowledgement is received from TBIT, the TCP IUT s cwnd is increased to send two new data segments. The TCP IUT sends two data segments each with 1448 and 12 bytes of data. Both data segments from TCP IUT also include a SACK block (12 bytes). A proper SACK implementation is expected to send two data segments each with 1448 bytes of data and 12 bytes of SACK information. In the observed misbehavior, the second data segment carries only 12 bytes of data thus decreasing throughput. The misbehavior is observed continuously when there is out-of-order data in the receive buffer of the TPC IUT. Throughput is decreased almost by half for the time period out-of-order data exists in the receive buffer. We believe that the misbehavior is caused by appending SACK information (12 bytes). With no SACKs, each data segment carries 1460 bytes of data. When a SACK option is appended, 1460 bytes of data are split to two data segments each with 1448 and 12 bytes of data. Note that the second segment carries bytes equal to bytes required for a SACK block. To investigate the misbehavior further, we extended test D to create two, three and four blocks of out-of-order data at the TCP IUT. In these cases, the TCP IUT sends two data segments with (1440, 20), (1432, 28), (1424, 36) bytes, respectively. Note that the second data segment always carries bytes equal to bytes needed for SACK blocks appended. The throughput is again roughly halved for time period there are out-of-order data in the TCP IUT s receive buffer. The scenario presented is a typical web browsing scenario and the observed misbehavior reduces the overall throughput. We consider the misbehavior is critical and needs to be fixed. VI. RELATED WORK Two methodologies are mainly used to infer the TCP behavior: passive and active measurements. In passive measurements, collected trace files are analyzed offline to infer a specific protocol behavior. Paxson [19] presents tcpanaly, a tool which automatically analyses the correctness of TCP implementations by inspecting traces collected for bulk data transfers. The study s main interest is on congestion window evolution and proper ACK generation. With tcpanaly, non-conformant TCP stacks are identified and reported to the stack implementors. In [7], the authors describe the active measurement tool TBIT and its architecture. TBIT is used to infer the TCP behavior of remote web servers. A number of TBIT tests are provided by authors including testing a remote web server s support for SACK and testing if SACKs are correctly used by the web server to send proper segments during the SACKbased loss recovery. Ladha [20] is another active measurement in which the authors measure the deployment status of recent TCP enhancements using the TBIT at the time. The authors add three new TBIT tests for TCP extensions: limited transmit, appropriate byte counting (ABC), and early retransmit. In addition to the new test cases added, the SACK and initial congestion window tests of [7] are rerun to evaluate the deployment status of the extensions. In [8], the authors investigate the correctness of modern TCP implementations through active measurements. The active measurements are performed with TBIT. The work compares the correct use of SACK information by web servers. In 2005, correct use is increased to 90% as opposed to 2001 s 42% [7]. A new test is introduced to test if the web servers correctly generate SACK blocks, and ~91% of the web servers tested generate correct SACK blocks. Our research combines both methodologies. We use TBIT to create synthetic TCP traffic to validate the proper SACK

7 generation of TCP stacks. In addition, we capture TCP segments using a packet capture utility such as tcpdump or wireshark for offline SACK generation analysis. One approach that we could employ was to use a TCP stack instead of TBIT along with the dummynet [21] traffic shaper to drop specific packets to mimic the observed traffic patterns of observed misbehaviors. The traffic between TCP IUT and TCP stack could be captured with tcpdump/wireshark for later analysis. One problem with this approach is as follows. Since a TCP stack is used to test the proper SACK generation of a TCP IUT, the initial sequence number space of each would change with each test. In that case, analysis of SACK generation would be more complex. With TBIT, the sequence number space is controllable. Another approach would be to run TBIT tests on remote web servers and infer the operating system of web servers with a tool such as Network Mapper (NMAP) [22]. This approach has also several disadvantages. First, TBIT is not robust against packet loss and reordering. The tests need to be terminated once one of the two events is detected. Second, detecting the exact operating system of a remote web server is not always possible. NMAP did not return operating systems guesses for all remote web servers when we used the tool on ALEXA s [23] top twenty sites. Third, some of the remote web servers could employ TCP options such as timestamps which would cause having different results for the same operating system. Instead, we test SACK generation on standard TCP stacks of the reported operating systems with default settings. VII. CONCLUSION In this paper, we verify the conformant SACK generation on TCP stacks for a wide range of operating systems based on observed misbehaviors regarding to SACK generation in our data reneging investigations. We identified the characteristics of the four observed misbehaviors and designed with four new TBIT tests to uncover these misbehaviors. We verified the SACK generation on various number of FreeBSD, OpenBSD, Mac OS X, Linux, Solaris and Windows TCP stacks. For the four misbehaviors observed in the trace files, we found at least one misbehaving TCP stack. We report various versions of OpenBSD and Windows operating systems to have misbehaving SACK generation implementations. In general, the misbehaving SACK implementations can cause a less efficient SACK-based loss recovery which yields to decreased throughput (longer transfer times). During the TBIT tests, we identified two additional SACKrelated misbehaviors. The first misbehavior is serious and can cause a TCP to be inconsistent that is the data sender receives a SACK for data that was never received. Solaris and OpenSolaris systems misbehave in this manner. The second misbehavior decreases the throughput by sending less than expected data while using SACKs. Most Linux systems show this misbehavior. In this paper, we show that plenty of operating systems do not implement SACKs correctly which is simple in concept. We report the misbehaving stacks and provide capture files of the TBIT tests to the stack implementors. We hope that our work will help the TCP stack implementors to fix the incorrect implementations. ACKNOWLEDGMENTS The authors would like to thank Jonathan Leighton, Aasheesh Kolli and Ersin Ozkan for the valuable discussions and comments while developing this paper. REFERENCES [1] M. Mathis, J. Mahdavi, S. Floyd, A. Romanow, TCP Selective Acknowledgment Options, RFC 2018, October [2] J. Postel, Transmission Control Protocol, RFC 793, September [3] K. Fall, S. Floyd, Simulation-based comparisons of Tahoe, Reno, and SACK TCP, ACM Computer Communication Review, vol. 26, no. 3, July 1996, pp [4] R. Bruyeron, B. Hemon, L. Zhang, Experimentations with TCP selective acknowledgement, ACM Computer Communication Review, vol. 28, no. 2, April 1998, pp [5] M. Allman, C. Hayes, H. Kruse, S. Ostermann, "TCP performance over satellite links", Proceedings of the Fifth International Conference on Telecommunications Systems, March, [6] E. Blanton, M. Allman, K. Fall, L. Wang, A Conservative Selective Acknowledgment (SACK)-based Loss Recovery Algorithm for TCP, RFC 3517, April [7] J. Padhye, S. Floyd, On inferring TCP behavior, ACM SIGCOMM, August 2001, pp [8] A. Medina, M. Allman, S. Floyd, Measuring the evolution of transport protocols in the internet, ACM SIGCOMM Computer Communication Review, April [9] R. Stewart, Stream Control Transmission Protocol, RFC 4960, September [10] N. Ekiz, Transport layer reneging, PhD Dissertation, CISC Dept., Univ of Delaware (in progress). [11] CAIDA Internet Data Passive Data Sources, [12] The TCP Behavior Inference Tool, [13] R. Fielding, J. Gettys, J. Mogul, H. Frystyk, L. Masinter, P. Leach, T. Berners-Lee, Hypertext Transfer Protocol -- HTTP/1.1, RFC 2616, June [14] Tcpdump, [15] Wireshark, [16] VirtualBox, [17] Apache HTTP Server, [18] Packet captures of the TBIT tests, [19] V. Paxson, Automated packet trace analysis of TCP implementations, ACM SIGCOMM, September 1997 [20] S. Ladha, P. D. Amer, A. J. Caro, J. R. Iyengar, On the prevalence and evaluation of recent TCP enhancements, IEEE Globecom, November 2004 [21] L. Rizzo, "Dummynet: A simple approach to the evaluation of network protocols," ACM Computer Comm Review, 27(1):31-41, Jan [22] Network Mapper, [23] Global Top 500 Web Sites,