The Interaction Between the DOCSIS 1.1/2.0 MAC Protocol and TCP
Total Page：16
File Type：pdf, Size：1020Kb
The Interaction Between the DOCSIS 1.1/2.0 MAC Protocol and TCP Application Performance Jim Martin [email protected] Department of Computer Science Clemson University Keywords— DOCSIS, TCP performance, performance analysis, broadband access Abstract The deployment of data-over-cable broadband Internet access continues to unfold throughout the world. While there are competing technologies, the Data over Cable (DOCSIS) 1.1/2.0 effort is emerging as the single standard. There has been little research exploring the impact that the DOCSIS 1.1/2.0 MAC and physical layers has on the performance of Internet applications. We have developed a model of DOCSIS using the ‘ns’ simulation package. In this paper we present the results of a performance analysis that we have conducted using the model. The contribution of our work is twofold. First, we provide insight into the interaction between the DOCSIS MAC protocol and web traffic. Our analysis suggests that DOCSIS does not efficiently support downstream web browsing. Second, we show how a DOCSIS system is vulnerable to a denial of service attack by a hacker who exploits the interaction between the DOCSIS MAC layer and TCP. We show that downstream rate control is not sufficient to avoid the vulnerability. Introduction The DOCSIS Radio Frequency Interface specification defines the Media Access Control (MAC) layer as well as the physical communications layer [1] that is used to provide high speed data communication over a cable HFC infrastructure. DOCSIS 1.1, the current standard, provides a set of ATM-like services with equivalent quality of service mechanisms. The next generation DOCSIS standard (version 2.0) enhances the physical layer communication methods with higher upstream date rates and improved performance tolerance to bursts of noise. More importantly, DOCSIS 2.0 can provide symmetric data communications. Figure 1 illustrates a simplified DOCSIS environment. A Cable Modem Termination System (CMTS) interfaces with hundreds or possibly thousands of Cable Modem’s (CMs). The Cable Operator allocates a portion of the RF spectrum for data usage and assigns a channel to a set of CMs. A downstream RF channel of 6 Mhz (8Mhz in Europe) is shared by all CMs in a one-to-many bus configuration (i.e., the CMTS is the only sender). DOCSIS 1.1 supports a maximum downstream data rate of roughly 30.34Mbps. Upstream channels of 3.2Mhz offer maximum data rates up to 10.3.Mbps that is shared by all CMs using a TDMA based system. DOCSIS 2.0 increases upstream capacity to 30 Mbps through more advanced modulation techniques and by increasing the RF channel allocation to 6.4 Mhz. Residential network Public CM-1 Internet Residential CM-1 network DOCSIS 1.1/2.0 CM-1 CMTS Cable Network . CMTS CM-1 Enterprise POP Broadband Service Provider network ‘n’ homes or CMTS organizations Contention Slots Data Slots Maintenance slots sharing a channel . Corporate CMTS intranet Figure 1. DOCSIS cable access environment Figure 2. Example upstream MAP allocation 1 The CMTS makes upstream CM bandwidth allocations based on CM requests and QoS policy requirements. The upstream channel is divided into ‘mini-slots’ which, depending on system configuration, normally contain between 8 to 32 bytes of data. Figure 2 illustrates a possible MAP allocation that includes allocated slots for contention requests, user data and management data. A critical component of DOCSIS is the upstream bandwidth allocation algorithm. The DOCSIS specification purposely does not specify these algorithms so that vendors are able to develop their own solutions. DOSCIS does require CMs to support the following set of scheduling services: • Unsolicited Grant Service (UGS) • Real-Time Polling Service (rtPS) • Unsolicited Grant Service with Activity Detection (UGS-AD) • Non-Real-Time Polling Service (nrtPS) • Best Effort Service (BE) All DOCSIS scheduling algorithms will share a set of basic system parameters. These include the amount of time in the future that the scheduler considers when making allocation decisions (we refer to this parameter as the MAP_TIME), the frequency at which MAPs are issued, the frequency of contention slot offerings and the range of collision backoff times. The complex interactions between DOCSIS operating parameters and the subsequent impact on system and application performance is not well understood. We have developed a model of the Data over Cable (DOCSIS) 1.1/2.0 MAC and physical layers using the ‘ns’ simulation package [2]. In previous work, we reported on the impact of several DOCSIS operating parameters on TCP/IP performance [3]. In this paper we extend those results by looking in greater detail at the impact that the MAC layer has on TCP performance when using the DOCSIS best effort service. We show that the interaction between DOCSIS and TCP exposes a denial of service vulnerability. By taking advantage of the inefficiency surrounding upstream transmissions, a hacker can severely impact network performance. This paper is organized as follows. The next section presents the operation and features of our DOCSIS model. We explain our experimental methodology and then discuss the results. We end the paper with a discussion of related work, present conclusions and identify future work. Summary of the Model All CMs receive periodic MAP messages from the CMTS over the downstream channel that identify future scheduling opportunities over the next MAP time. When the CM has data to send, and if it has been provisioned with a periodic grant (i.e., the UGS service), the CM can send at its next data grant opportunity. For best effort traffic, it is likely that bandwidth will be requested during contention transmission opportunities specified by the MAP. DOCSIS allows the CM to combine multiple IP packets into a single DOCSIS frame by issuing a concatenated request. If a CM receives a grant for a smaller number of mini-slots than were requested (even for a concatenated request), the CM must fragment the data to fit into the assigned slots over several frames. To minimize the frequency of contention-based bandwidth requests, a CM can piggyback a request for bandwidth on an upstream data frame. To help us evaluate the benefits of these features, we have configuration parameters that enable or disable fragmentation, piggybacked requests and that limit the maximum number of packets that can be included in a concatenated MAC frame. Each time the CMTS generates a MAP, the upstream bandwidth scheduling algorithm examines all existing requests for bandwidth and implements an earliest deadline first scheduling policy. All UGS service requests are scheduled and whatever bandwidth remains is shared by best effort requests based on a first-come-first-served discipline. A UGS request that fails to meet a deadline is considered a provisioning problem. During periods of high load, the CMTS maintains a queue of pending upstream bandwidth requests. Once a new request for bandwidth arrives from a CM, the CMTS responds with a data grant pending indication. This informs the CM that the contention-based request succeeded and to expect a data grant at some point in the future. The CONTENTION_SLOTS parameter determines the number of contention slots allocated in each MAP. The scheduler has a configured MAP time (i.e., a MAP_TIME parameter) which is the amount of time covered in a MAP message. The MAP_FREQUENCY parameter specifies how often the CMTS sends a MAP message. 2 Usually these two parameters are set between 1 – 10 milliseconds. The scheduling algorithm supports dynamic MAP times through the use of a MAP_LOOKAHEAD parameter which specifies the maximum MAP time the scheduler can ‘lookahead’. If this parameter is 0, MAP messages are limited to MAP_TIME amount of time in the future. If set to 255 the scheduler may allocate up to 255 slots in the future. For the experiments described in this paper, the MAP_LOOKAHEAD was set to 255 and there were 80 slots in each MAP. Roughly 100 slots were required to transmit a frame containing a 1500 byte IP packet and 200 slots were required to send a concatenated frame containing two 1500 byte IP packets. Methodology Test server 1 S-1 WRT probe S-2 CM-1 Test client 1 . CM-2 . 45Mbps, 18ms 45Mbps, .5ms . prop delay prop delay . 4.71mbps upstream, 28.9Mbps CMTS Node Node . downstream . Test client 2 . TCP Analysis Connection . 100Mbps links . CM-n …………….. S-n (1-3ms delay) . Test server 2 10Mbps links (1-5ms delay) Figure 3. Simulation network Our analysis used the simulation network shown in Figure 3. The DOCSIS parameters were based on the optimal configuration parameters that we found in [3]. The results we report in this paper were based on two sets of experiments, both using realistic traffic models consisting of a combination of web, P2P and streaming traffic. The network and web traffic models were based on the “flexbell” model defined in [4]. In addition to downstream web traffic, we configure 5% of the CMs to generate downstream low speed UDP streaming traffic (i.e., a 56Kbps audio stream), 2% of the CMs to generate downstream high speed UDP streaming traffic (i.e., a 300Kbps video stream) and 5% of the CMs to generate downstream P2P traffic. The P2P model (based on [5]) incorporates an exponential on/off TCP traffic generator that periodically downloads on average 4Mbytes of data with an average idle time of 5 seconds between each download. The simulation model parameters are shown in Figure 4. In the first experiment, referred to as the web congestion study, we varied two parameters, the MAP_TIME and the number of CMs. For a given MAP_TIME setting, we varied the number of CMs from 100 to 5001. We do this for six MAP_TIME settings ranging from .001 to .01 seconds.