P57/1 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 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. Keywords— DOCSIS, TCP performance, performance analysis, broadband access 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. ..CMTSCM-1..DOCSIS 1.1/2.0Cable NetworkCorporateintranetPOPBroadband Service Provider‘n’ homes or organizations sharing a channelPublicInternetResidentialnetworkEnterprisenetworkResidentialnetworkCMTSCMTSCMTSCM-1CM-1CM-1 Figure 1. DOCSIS cable access environment Figure 2. Example upstream MAP allocation Contention Slots Data Slots Maintenance slotsP57/2 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. For best effort traffic, it is likely that bandwidth will be requested during contention transmission opportunities that are specified by the MAP. Once a 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. 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