Transport layer reneging

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. Today's reliable transport protocols (TCP, SCTP) are designed to tolerate data reneging. I argue that this design assumption is wrong based on our hypothesis that reneging rarely if ever occurs in practice. This dissertation provides the literature's first comprehensive analysis of reneging. We investigate (1) the instances, (2) causes and (3) effects of reneging in today's Internet. For (1), this dissertation proposes a model to detect reneging instances. The model builds upon the way an SCTP data sender detects reneging. A state of the data receiver's receive buffer is constructed at an intermediate router and updated as new acks are observed. When an inconsistency occurs between the state of the receive buffer and a new ack, reneging is detected. We implemented the proposed model as a tool called RenegDetect v1. While verifying RenegDetect v1 with real TCP flows, we discovered that some TCP implementations were generating SACKs incompletely under some circumstances giving a false impression that reneging was happening. Our discovery led us to a side investigation to precisely identify five misbehaving TCP stacks observed in the Internet (CAIDA) traces. For that, we designed a methodology and verified RFC2018-conformant SACK generation on 29 TCP stacks for a wide range of OSes. We found at least one misbehaving TCP stack for the five misbehaviors observed during the verification of RenegDetect v1 and concluded that while simple in concept, SACK handling is complex to implement. To identify reneging instances more accurately and distinguish them from SACK generation misbehaviors, we updated RenegDetect v1 to v2 to better analyze the flow of data, in particular, to analyze data retransmissions which are a more definitive indication that reneging happened. To report the frequency of reneging in trace data, traces from three domains were analyzed: Internet backbone, a wireless network, and an enterprise network. Contrary to our initial expectation that reneging is an extremely rare event, trace analysis demonstrated that reneging does happen. We analyzed 202,877 TCP flows using SACKs from the three domains. In the flows, we confirmed 104 reneging instances (0.05%). With 95% statistical confidence, we report that the true average rate of reneging is in the interval [0.041%, 0.059%], roughly 1 flow in 2000. The causes of reneging (2) were identified by analyzing TCP stacks of popular operating systems with reneging support. Our investigation revealed that five popular operating systems (FreeBSD, Linux (Android), Apple's Mac OS X, Oracle's Solaris and Microsoft's Windows Vista+) can renege. Initially, reneging was expected to happen on operating systems that go low on main memory to help the operating system to resume normal operation. Surprisingly, we discovered that reneging also is used as a protection mechanism against Denial of Service (DoS) attacks (Solaris and Windows Vista/7). We concluded that reneging is a common mechanism implemented in many of today's popular operating systems. To investigate the consequences of reneging (3), a tool, CauseReneg, to cause a remote host to renege was designed, and used to force FreeBSD, Solaris, and Windows Vista victims to renege. CauseReneg achieves its goal by exhausting a victim's resources by sending out-of-order data using multiple TCP connections. For an operating system (e.g., FreeBSD) starving for memory, we demonstrated that reneging alone cannot help the system to resume normal operation. Therefore, we recommend that reneging support should be turned off for systems using reneging as a mechanism to reclaim memory to resume normal operation. For operating systems using reneging to protect against DoS attacks, reneging appears to be a useful mechanism. We argue that a better approach would be toRESET a connection under attack instead of reneging since terminating the connection would release all of the resources held. For example, in FreeBSD, reneging would reclaim at most 64 Kbytes (the default receive buffer size) per connection while terminating a connection would release ∼3MB of memory. By RESETing a connection, the victim's system resources are better utilized. (Abstract shortened by UMI.)