The Behavior of TCP Over DOCSIS-Based
CATV Networks
Wanjiun Liao, Senior Member, IEEE
Abstract—This paper studies the impact of the data-over-cable
service interface specification (DOCSIS) media-access control (MAC) protocol on the performance of the transmission control protocol (TCP) in hybrid fiber coax (HFC) broadband access networks. We find that the asymmetry ratio expressed in ex-isting work cannot adequately explain the behavior of TCP in DOCSIS-based networks. To better capture the effect of DOCSIS on TCP, we express the asymmetry ratio (denoted by) in another way (denoted by k), considering the time-division multiple-ac-cess-like MAC layer operation of DOCSIS. When > 1, TCP behaves as in a symmetric network, and when 1, the system acts as in an asymmetric network, and the performance of TCP degrades. We find that the number of simultaneous TCP transfers significantly affects the asymmetry ratio. When the number of ac-tive transfers is below two times the maximum number of pending requests in a transmission period, the value of is larger than one, regardless of the value ofk. However, when the number of active transfers becomes very large, the effect of DOCSIS on TCP becomes negligible, and the asymmetry ratio is determined by the bandwidth ratio of the channels times the length ratio of data and acknowledgement packets. Based on, we develop the round-trip delay of sending a data packet for both one-way and two-way transfers, and discuss the buffer requirement at the head end. The accuracy of the analytical model is validated by ns-2 simulations. The analytical result can provide useful guidelines in the design of slot allocation or scheduling mechanisms for any DOCSIS-based broadband access networks, including the emerging IEEE 802.16 WiMAX networks.
Index Terms—Broadband access networks, community antenna
television (CATV), data-over-cable service interface specification (DOCSIS), transmission control protocol (TCP).
I. INTRODUCTION
T
HIS PAPER studies the behavior of the transmission control protocol (TCP) over data-over-cable service in-terface specification (DOCSIS)-based hybrid fiber coax (HFC) networks [1], a popular choice for broadband access to the Internet provided by community antenna television (CATV) operators. Unlike legacy CATV networks built with coaxial cables only, HFC networks consist of both fiber and coaxial cables. Like legacy CATV networks, the HFC network is a tree-and-branch network, as shown in Fig. 1. The tree is rooted at the cable modem termination system (CMTS) at the head end, and is connected by fiber cables to fiber nodes (FNs), from Paper approved by I. Andonovic, the Editor for Optical Networks and Devices of the IEEE Communications Society. Manuscript received March 1, 2004; re-vised September 12, 2005. This work was supported in part by the National Sci-ence Council of Taiwan, under a Center of ExcellSci-ence Grant NSC94-2752-E-002-006-PAE and under Grant NSC94-2218-E-002-059.The author is with the Department of Electrical Engineering and the Graduate Institute of Communication Engineering, National Taiwan University, Taipei 106, Taiwan, R.O.C. (e-mail: [email protected]).
Digital Object Identifier 10.1109/TCOMM.2006.878833
Fig. 1. Tree-and-branch topology of the HFC network.
where coaxial cables are used to connect to cable modems (CMs) at the households. This HFC architecture makes HFC systems more robust, and provides better signal quality and higher channel capacity than legacy CATV networks.
In HFC networks, each branch is comprised of a downstream channel and an upstream channel. The downstream channel is a point-to-multipoint broadcast channel, and the upstream channel is a multipoint-to-point shared channel. The only trans-mitter on the downstream channel is the CMTS at the head end, and all the CMs connected to the channel are receivers. For the upstream channel, all the CMs are transmitters, and the CMTS is the only receiver. To arbitrate random access to the upstream channel, a media-access control (MAC) mechanism is required. The MAC mechanism in HFC may follow the DOCSIS of the Multimedia Cable Network System (MCNS) Partners [1] or IEEE 802.14 [2]. Since DOCSIS is the de facto standard in the cable industry, we will focus on DOCSIS in this paper.
In DOCSIS, the upstream channel is modeled as frames of minislots. Each frame is comprised of contention minislots and data minislots, plus some management minislots, as shown in Fig. 2(a). The detailed minislot allocation of each frame is specified via a control message, called MAP, which is period-ically transmitted by the CMTS on the downstream channel [Fig. 2(b)]. In each MAP, a variable number of information elements (IEs) are specified, each IE describing a range of minislots to be used by a CM in the next frame. The number of IEs, and the corresponding minislots, varies from MAP to MAP. Typically, each MAP contains a Request IE, some Data Grant IEs, a Null IE, and some management information. The Request IE specifies the contention interval of the next frame; each Data Grant IE describes the transmission interval for one CM, and the Null IE terminates the assignment list. Each MAP describes the details of the next frame to be transmitted upstream, and must be received by all CMs before the next frame starts, as in all reservation-based MAC mechanisms.
Each time a CM has a data packet to transmit, it requests the assignment of a Data Grant IE in a later MAP. If the CM is backlogged (i.e., a CM with a nonempty packet queue) and is 0090-6778/$20.00 © 2006 IEEE
Fig. 2. Operation of DOSCIS MAC mechanism. (a) DOCSIS frame. (b) MAP control message.
assigned a Data Grant IE in the newly received MAP, its re-quest is piggybacked on an outgoing packet using the assigned Data Grant IE in the data minislots; otherwise, the CM contends for the use of the upstream channel via contention minislots. Each contention request occupies one minislot. If several CMs compete for one minislot in the contention interval, all the re-quests are corrupted due to collisions. After sending a request, the CM waits for a Data Grant IE or a Data Pending IE in the next MAP. Once either is received, the contention resolution is complete. Each CM can use the Data Grant IE to transmit a data packet if assigned, or keep waiting for a Data Grant IE and send no further request if a Data Pending IE is received. The CM regards the contention request as lost if neither a Data Grant IE nor a Data Pending IE is received. The CM then in-creases the backoff window (i.e., contention window) by a factor of two, as long as the window size is less than the maximum backoff window. The CM randomly selects a value within its new backoff window, pauses until the timer expires, and then re-peats the contention process. This retry process continues until the maximum number of retries is reached, at which time the packet must be discarded.
The design issues for HFC networks have been widely studied for years. An efficient MAC layer scheduling and allocation algorithm for the upstream channel of HFC networks is pro-posed in [3]–[6]. The performance of HFC networks is evalu-ated in [7]–[9]. The flow control mechanism of TCP is tuned in [10]–[13] to improve the performance of TCP over asymmetric networks. The performance of TCP in HFC networks is investi-gated in [14]–[17]. The impact of DOCSIS on the performance of TCP is studied in [18] and [19].
The previous studies [10]–[13] have shown that the per-formance degradation of TCP over asymmetric networks is
due to bandwidth asymmetry of downstream and upstream channels. This paper also investigates the performance degra-dation problem of TCP, but focuses on DOCSIS-based HFC networks, an asymmetric network which employs a MAC mechanism to arbitrate random access among multiple hosts. We discuss the impact of DOCSIS’s MAC mechanism on the performance of TCP, and demonstrate that the result provided by existing work cannot adequately explain the behavior of TCP in such an environment. We then define an asymmetry ratio for DOCSIS systems and analyze the behavior of TCP over DOCSIS based on this ratio. We examine both one-way and two-way TCP transfers in the network, and analyze the throughput and delay performance of the system. The accu-racy of the model is validated by ns-2 simulations. The simu-lation results support our analytical results. To the best of our knowledge, this is the first paper providing a thorough theo-retical study on the performance of TCP over DOCSIS-based networks. The analytical result can provide useful guidelines in the design of scheduling mechanisms for DOCSIS-based systems [14]. The proposed analytical model can also be used to evaluate and compare the performance of resource management mechanisms designed for any DOCSIS-based broadband access networks, including the emerging IEEE 802.16 WiMAX networks.
The rest of the paper is organized as follows. Section II de-scribes the performance problem of TCP over DOCSIS-based HFC networks and defines an asymmetry ratio for DOCSIS systems. Section III analyzes the behavior of one-way TCP transfers over the MAC layer of DOCSIS. Section IV ana-lyzes two-way TCP transfers over the DOCSIS MAC layer. Section V shows simulation results to verify the analysis. Finally, the concluding remarks are given in Section VI.
Fig. 3. Illustration of DOCSIS. The requests piggybacked on data IEs are sent by CMs; a MAP message is sent by the CMTSD seconds before the next frame starts.T denotes the delay between sending two consecutive packets from the upstream buffer of each CM.
II. PROBLEMSTATEMENT
In HFC networks, one CMTS controls multiple branches. Each branch is composed of one downstream channel and one upstream channel, and is typically connected to 200–500 CMs in the neighborhood. Since each branch works identically but independently, without loss of generality, we consider only one branch in the analysis. This analysis is based on TCP Reno, plus the delayed acknowledgement (ACK) mechanism, for conges-tion control.
A. Notation and Assumptions
Some terms are defined to facilitate explanation in the paper. 1) The delivery offset of the MAP (denoted by ) is the one-way propagation delay between the CMTS and CMs plus some extra delay, as shown in Fig. 3. This amount of time is spent for the CMTS to inform all CMs of the slot allocation details for the next frame. Thus, each MAP should be sent seconds before the next frame starts. 2) Upstream user service time (denoted by ) is the delay between sending two consecutive data packets from the upstream buffer of one CM, as shown in Fig. 3.
3) Access delay (denoted by ) is defined as the time be-tween when a packet is received by a CM and when the CM starts sending this packet out to the channel.
The notations used in the analysis are summarized as follows. Capacity of the downstream channel, in b/s. Capacity of the upstream channel, in b/s. Data packet length, in bits.
ACK packet length, in bits.
Buffer size (i.e., backlog) at a CM, in terms of number of packets.
One-way propagation delay between the CMTS and CMs, in seconds.
Number of CMs performing TCP transfers in the downstream direction.
Number of CMs performing TCP transfers in the upstream direction.
One minislot time, in seconds.
Total number of minislots granted in a MAP for a frame.
Number of contention minislots described in a MAP.
Number of minislots for one ACK packet. Number of minislots for one TCP data packet. Access delay, in seconds.
Upstream user service time, in seconds. Delivery offset of a MAP, in seconds.
Maximum number of pending requests received
during a .
We make the following assumptions.
1) We consider TCP traffic only in the analysis. The result can serve as the lower bound of the performance when user datagram protocol (UDP) and TCP traffic coexists on the channel.
2) The propagation delay between the CMTS and all CMs are assumed the same.
3) In DOCSIS, multiple outstanding MAPs are allowed. Here we restrict the number of outstanding MAPs to one, so as to simplify the analysis. Nevertheless, the analytical approach is applicable to the case with multiple MAPs outstanding. 4) The number of contention minislots in each DOCSIS
frame, i.e., , is a constant.
5) The contention minislots in each frame is assumed larger than the delivery offset of the MAP, i.e.,
.
B. Effect of Bandwidth Asymmetry on Performance of TCP
Asymmetric networks, such as HFC and xDSL, are networks with different channel bandwidths in the downstream and up-stream directions. The main effect of bandwidth asymmetry on the performance of TCP is that the ACK clocking may be dis-rupted [10]–[13]. To better understand the behavior of TCP in asymmetric networks, an asymmetry ratio [10] is defined by
forward channel bandwidth reverse channel bandwidth
ACK packet length
The physical meaning of this ratio is explained as follows. TCP behaves normally when is less than or equal to one. When this ratio exceeds one, the network is asymmetric. Operating TCP over an asymmetric network makes ACK packets arrive on the bottleneck link in the reverse direction at a rate faster than the bottleneck link can support, and leads to two consequences. First, the time spacing between consecutive ACKs received by the sender is larger than that in the symmetric case. As a result, the sender clocks out data at a slower rate, and slows down the growth of the congestion window. This, in turn, degrades the throughput in the downstream direction. Second, the buffer to the reverse bottleneck link is rapidly filled up with ACK packets. A full buffer may cause serious ACK drops. This may lead to a bursty sender, because one ACK may acknowledge several TCP data packets in an unpredictable way. In addition, fewer ACK packets received may slow down the growth of the sender’s con-gestion window, because TCP increases its concon-gestion window by counting the number of ACKs received.
C. Asymmetry Ratio for DOCSIS Systems
To examine the adequacy of the expression in (1) for de-scribing the behavior of TCP over DOCSIS-based HFC net-works, we estimate the performance of TCP using the param-eters listed in Table I. The bandwidths of the downstream and upstream channels are set to 26.97 and 2.56 Mb/s, respectively. Considering the delayed ACK policy of TCP Reno (i.e., sending one ACK packet to acknowledge the receipt of data packets), the expression of is modified as
Using the packet lengths of ACK B and Data B, and , we obtain
Since , this network is supposed to be symmetric for TCP, i.e., TCP should behave normally.
Fig. 4. Throughput versus number of TCP transfers.
Fig. 5. Backlog at the CM versus number of TCP transfers.
We then verify the behavior of TCP in such a network by simulation using ns-2 [18], again based on the parameters listed in Table I. We observe the influence of different number of downloading CMs (i.e., ) on the aggregate downstream throughput and the backlog in the upstream buffer (which buffers ACK packets) at the CM. Fig. 4 plots the aggregate downstream throughput of the network, varying from 1 to 50, and Fig. 5 shows the respective buffer size (i.e., backlog).
Interestingly, we find that when is small (e.g., less than 13 in this example), the network behaves like an asymmetric net-work, i.e., low downstream throughput and full upstream ACK queues. However, as becomes large (e.g., exceeds 13 in this example), TCP starts behaving normally. This implies that the network experiences bandwidth asymmetry (i.e., the asymmetry ratio is greater than one) when is small, and the performance degrades in this region. However, according to the estimation based on in (1), the network should op-erate symmetrically. Thus, we learn that while in (1) captures well the behavior of TCP on point-to-point asymmetric links, it cannot adequately explain the behavior of TCP operating over DOCSIS-based HFC networks, an asymmetric network which needs a MAC mechanism to arbitrate random access among end hosts. To better capture the abnormal behavior of TCP over DOCSIS-based HFC networks, we need to consider the min-islot reservation-based random access in the upstream direction of DOCSIS systems.
We then revise the asymmetry ratio in (1) as in (2) for DOCSIS networks, considering the MAC layer operation of DOCSIS.
(2) This new ratio is obtained as follows. Considering the upstream channel in HFC networks as a time-division mul-tiple-access (TDMA)-like channel, in (1) is replaced with , where is the duration that a CM should wait for its scheduled time. For downstream transmis-sions, in (1) is shared by all simultaneous TCP
transfers, and should be replaced by .
We also consider the delayed ACK policy. Thus, we multiply
by to obtain .
In the next two sections, the impact of the DOCSIS MAC mechanism on the performance of TCP will be studied with re-spect to the round-trip delay (RTT) of each TCP transfer. This RTT, in turn, determines the throughput of each TCP connec-tion in DOCSIS networks.
III. ONE-WAYTCP TRANSFERS
We first examine one-way TCP transfers, i.e., all CMs down-load TCP traffic on the downstream channel. Thus, all data packets go on the downstream channel, and all ACK packets go on the upstream channel.
A. Effect of DOCSIS MAC on Bandwidth Asymmetry
In DOCSIS, the MAP for the next frame should be received by all CMs before the frame starts. This may cause some re-quests, especially piggybacked ones, in the current frame to ar-rive and be processed at the CMTS after the MAP for the next frame has been sent. The late requests will be pending and be-come backlogs for the second frame. These pending requests plus new requests which arrive at the CMTS during the next frame will be waiting to be granted in the next MAP. Each MAP can describe at most 2048 minislots. Compared with the MAP limitation of 2048 minislots, the ACK packet length is relatively small. To simplify the analysis, we assume that the minislot limitation of each MAP will not be exceeded when the CMTS grants all the waiting requests. In fact, even if the lim-itation is exceeded, the analytical approach is still applicable, because the global ordering of data grants placed in frames re-mains intact. Recall that the contention minislot interval is as-sumed larger than the delivery offset of each MAP. Thus, the pending requests will be granted in the next MAP, not in later MAPs. Since the packet length of each ACK is fixed, the max-imum number of pending requests, (i.e., those arriving at the CMTS during a ), in terms of number of minislots, can be expressed by
The value of can be calculated in two mutually exclusive, collectively exhaustive cases.
Case 1:
When , no piggybacked requests are
granted in the next MAP. On average, each CM receives one data grant in every other frame, i.e., there are requests granted every two frames. Thus, can be expressed by
(3)
where .
Case 2:
If , some CMs may obtain their data
grants immediately in the next frame. When piggybacked re-quests arrive at the CMTS before the next MAP has been sent, these requests will be scheduled after those pending requests arriving in the current frame. These “lucky” piggybacked re-quests are scheduled behind the pending rere-quests in the next frame. Those requests placed in the last data grants of the next frame become the pending requests of the second frame. As such, all CMs take turns as the “lucky” ones in each frame, and the average data grants each CM can obtain in every other frame is more than one. Thus, can be expressed by
(4) Substituting (3) and (4) into (2), we can obtain the asymmetry ratio as follows:
1)
(5) 2)
(6) Note that since only ACK packets are transmitted on the upstream channel, all upstream packets have the same length. As a consequence, the number of minislots for each data grant (i.e., ) is fixed, and the number of pending requests (i.e., ) is also a fixed value. In addition, we fix the number of contention minislots (i.e., ). Given the down-stream and updown-stream channel capacities and TCP packet length, the asymmetry ratio varies only with the number of CMs transferring simultaneously (i.e., ). Furthermore, from (5) and (6), decreases as increases. This implies that as the number of simultaneous transfer increases, the network asymmetry decreases, matching the observation we made in Figs. 2 and 3. From (6), when becomes very large,
will be approximated by .
Substituting into this
approximation, we obtain
B. Effect of DOCSIS MAC on TCP RTT
We now analyze the RTT of sending one TCP packet in DOCSIS systems. To send an ACK packet, the CM needs to send a request first and wait for a data grant allocated by the CMTS. The average round-trip time is then given by
RTT (8)
Access delay for a packet is defined as the time between when the packet is received by the CM from the upper layer and when the CM starts sending it out. The packet may experience a queueing delay if the buffer at the CM is nonempty. Each time the CM wants to send an ACK packet, it will issue a request. Then, it will wait for the MAP that contains the data grant spec-ifying the period of time it is allowed to send. This needs two times more than the propagation delay between the CMTS and the CM (i.e., one propagation delay for the request, one propaga-tion delay for the MAP, plus the processing delay at the CMTS). Later, at the scheduled time, it will send the head-of-line packet from the buffer.
The asymmetry ratio greatly affects the value of . If , the upstream ACK buffer will always stay full. All requests experience long queuing delay and are sent piggybacked. If
, requests will often find an empty queue, and will be sent via contention. In the following, we calculate in these two cases.
Case 1: Asymmetry Ratio : When is larger than one, the upstream buffer will build up rapidly with ACK packets and stay full constantly. Due to the piggyback mechanism, the order of data grants placed in the consecutive frames remains intact until at least one CM has no more packets to send. The distri-bution of the upstream user service time for each packet will almost always remain unchanged, and each packet in the up-stream buffer experiences a delay of . Thus, the access delay can be expressed by
(9) where is the upstream buffer size (i.e., backlog) at the CM, in terms of the number of ACK packets.
1Here we mean (1) with the consideration of delayed ACK, i.e.,
k = (C )=(C ) 2 (L )=(L ) 2 (1)=(d).
Thus, the average access delay on the upstream channel can be approximately given by two frame times, i.e.,
(10) The total number of minislots in a frame is determined as follows. ACK packets use only a portion of bandwidth on
the upstream channel, . The remaining
bandwidth is used by the contention minislots. The average number of minislots used by ACK packets is then given by . Thus, on average, the total number of minislots in a frame is expressed by
(11) Substituting (11) in (10) and then in (8), we obtain the TCP RTT in the symmetric case.
To reflect the impact of these two cases of on RTT, the expression in (8) can be revised as
RTT RTT RTT (12)
where RTT is the RTT calculated based on RTT is based on , and is a weighting factor with
The interpretation of this setting will be described later in the performance evaluation section.
IV. TWO-WAYTCP TRANSFERS
In this section, we study two-way TCP transfers over DOCSIS-based HFC networks. With two-way transfers, some clients download TCP traffic (i.e., do TCP transfers in the downstream direction), and some upload TCP traffic (i.e., transfer TCP traffic in the upstream direction). Thus, both data and ACK packets can go in either direction.
A. Effect of DOCSIS MAC on Bandwidth Asymmetry
Since the network has asymmetric bandwidth and different operations for both channels, downloading CMs experience net-work asymmetry differently from uploading CMs. In what fol-lows, we will discuss the asymmetry ratios for clients doing TCP transfers in these two directions.
1) Downstream TCP Transfers: With two-way TCP
trans-fers, both data and ACK packets can be transmitted on the up-stream channel. These two kinds of packets are very different in size. ACK packets are fixed and small, and TCP data packets are variable and large. Typically, the data packet is ten times larger than the ACK packet. Thus, the data packet transmission time may be larger than the delivery offset of a MAP . When a frame ends with a data grant for a long data packet, it is very likely that no pending requests will arrive at the CMTS in the frame. However, in practice, data grants may be ordered in a frame rather randomly. Consequently, it is hard to accurately determine the number of pending requests in each frame. We can only conclude that if there are pending requests, they are usually from ACK packets.
Moreover, both data and ACK packets can be transmitted in the downstream direction. Only a portion of the downstream ca-pacity is used to transmit data packets. Considering the “delayed ACK” policy, the asymmetry ratio of downstream TCP transfers can be expressed by
(13) The first term in (13) [i.e.,
] is close to one, because 1) the ACK packet length is relatively small and 2) the “delayed ACK” policy is used to reduce the number of ACK packets to be sent. Thus, transmitting ACK packets in the downstream direction has a very minor impact on , due to only a small portion of the channel capacity being used for ACK packets. The MAP lim-itation of 2048 minislots, however, may easily be exceeded in the two-way transfer case. Fortunately, the MAP limitation has a very minor impact on , thanks to the global ordering of data grants specified by MAPs remaining intact. The only difference is that the data grants unable to fit in one MAP should be put in the next MAP. To save space, we assume this limitation is not exceeded, although the analytical approach is still applicable to handle the case when it is exceeded.
Based on the analysis in Section III-A [i.e., (5) and (6)], is highly dependent on the relationship between and
. In addition, the backlog in the upstream buffer is usually nonzero in the two-way transfer case. Due to the uncertain number of pending requests, we can only determine the upper and lower bounds of , instead of the deterministic value, as in the one-way case. Using the same approach as in Section III-A, we can derive the two bounds of for downstream transfers in two cases.
Case 1:
First, we determine the asymmetry ratio for the case of , regardless of the number of uploading CMs. The worst case of downloading CMs occurs when all data grants for ACK packets are placed in the end of a frame. In this case, the piggybacked requests of downloading CMs are
all pending. Thus, the worst-case of downloading CMs is given by
(14) where
and
The best-case of downstream TCP transfers occurs when the data grant of a TCP data packet is put in the end of a frame, and the data packet length is long enough to satisfy the
condi-tion of . In this case, all piggybacked
requests can obtain their data grants in the next MAP. Thus, the best-case is given by
(15) Substituting (14) and (15) in (13), we can obtain the two bounds of accordingly.
Case 2:
We determine for the case of ,
regard-less of the number of uploading CMs. The worst-case of downstream TCP transfers occurs when more than data grants for ACK packets are put in the end of a frame. Thus, the worst-case of downloading CMs is
(16) As in Case 1, the best-case occurs when the data grant of a long data packet is put in the end of a frame, and the packet size is long enough to satisfy the condition of
. Thus, the best-case is given by
(17) Substituting (16) and (17) in (13), the two bounds of can be obtained accordingly.
Data grants placed in a frame may be rather random. Sup-pose that no pending requests are caused by the MAP limitation. Once a long data grant (i.e., satisfying ) is placed in the end of a frame, all requests which arrive in the frame will be able to obtain their data grants in the next MAP. Thus, we conclude that while the worst case may happen, the network tends to operate in the best case in the steady state. We will demonstrate such an effect in the simulation section.
When the numbers of downloading and uploading CMs are equal and very large, the lower bound of can be approximated by
where is the upstream user service time of the uploading CM.
Multiplying in (19) with in (13) yields a constant of . When the asymmetry ratio of the downloading CM increases, the asymmetry ratio of the upstream CM is decreased. Due to the nature of bandwidth asymmetry in HFC networks, downstream TCP transfers usually have much larger asymmetry ratios.
B. Effect of Bandwidth Asymmetry on TCP RTT
The relationship between the TCP RTT and the asymmetry ratio for two-way transfers is the same as the one-way case [see (8)–(11)], except that the downloading CMs mostly operate as in asymmetric networks. The average RTT of sending a packet in the two-way case is given by RTT , where
for downstream traffic for upstream traffic. (20) The long RTT experienced by downloading CMs in the two-way case is due to long TCP packets going upstream. Long RTT, in turn, makes the TCP congestion window grow very slowly. In other words, the longer the RTT, the lower the downstream throughput. Thus, the two-way transfer case has lower downstream throughput, as compared with the one-way transfer.
V. PERFORMANCEEVALUATION
In this section, we provide numerical examples and simula-tion results using ns-2 to verify the analytical results presented in the previous sections. The parameter settings in this section are listed in Table I: the upstream and downstream channel ca-pacities are 26.97 and 2.56 Mb/s, respectively; the data and ACK packets’ lengths are 1024 and 64 B, respectively, and the de-layed ACK factor is set to 2 in the simulation; the upstream buffer can hold 20 packets; MAP limits are 2048 minislots and 240 IEs, and the number of contention minislots is set to 50.
A. Numerical Examples
1) One Way TCP Transfer: We first examine the analysis
results for one-way TCP transfers based on Table I. Fig. 6 plots as a function of . When is less than 13, is larger than one; otherwise, is less than or equal to one. This implies TCP has worse performance when is small. In the extreme case, when there is only one TCP transfer, reaches its maximum value and the TCP transfer results in the worst
Fig. 7. TCP RTT versus the number of simultaneous transfers based on dif-ferent settings onw in (12).
performance. Fig. 7 shows the relationship between the TCP RTT and the number of simultaneous transfers. The solid curve is plotted based on RTT in (8), and the dashed curve is from RTT in (12). It is observed that the asymmetry ratio has significant impact on TCP RTT. When , the RTT is on the order of 100 ms, and when , the RTT is on the order of 10 ms. The large RTT for is due to the long waiting time in the upstream buffer at CMs. The linear growth of the curve as is due to the increasing total number of minislots granted by the MAP. The curve stays flat as , invariant to the value of
.
We see that the delays of the solid curve are strictly classified into two categories, i.e., an increasing curve (as ) and a flat curve (as ), due to the result of the setting when , and when . In other words, there is a sharp drop in the curve at (i.e., ). In reality, the behavior of TCP should be similar on either side of the point of (e.g., 1.000001 and 0.999999). This phenomenon can also be explained by Fig. 6. When Fig. 6 is rotated counterclock-wise by 90 , the curve of the asymmetry ratio demonstrates an exponential-like growth. This implies that the RTT value should gradually decrease, rather than increase, when approaches one and . With the exponential setting, the RTT curve decreases smoothly as approaches one, better matching our expectation.
2) Two-Way TCP Transfer: We fix the total number of
simul-taneous transfers at 30. Let out of 30 clients transfer TCP in the upstream direction, and the rest transfer downstream. The other parameters are based on Table I.
The asymmetry ratio and the TCP RTT of downloading CMs are plotted in Figs. 8 and 9, respectively. Fig. 8 shows that of downloading CMs increases sharply as the number of simultaneous uploading CMs increases. is too high to tolerate
Fig. 8. Bounds of asymmetry ratio in two-way transfers. These bounds cor-respond to the best and the worst case of minislot allocation for packets in each DOCSIS frame.
Fig. 9. Bounds of TCP RTT in two-way transfers based on the bounds of.
Fig. 10. Access delay for one-way transfers.
when the number of simultaneous uploading CMs is beyond 20, i.e., two-thirds of clients are uploading. Interestingly, exceeds one so long as the number of simultaneous transfers is larger than one. This means even with just a few clients uploading, all downloading clients in the network suffer from bandwidth asymmetry. Fig. 9 shows that the TCP RTT of downloading CMs grows linearly as the number of simultaneous uploading CMs increases. The large RTT is due to a very large , which is much larger than one, and increases exponentially as the number of uploading CMs increases. Compared with one-way transfers (see Fig. 7), Fig. 9 has a much longer delay. This is because long packets (TCP packets) are transferred on the bottleneck channel, causing long waiting times for short packets (ACK packets).
B. Analysis vs. Simulation
In this section, the analytical results are compared with the simulation results. Figs. 10 and 11 show the access delays of downloading users for one-way and two-way transfers, respec-tively. The solid curves are from the simulation, and the dashed curves are from the analysis (U is for the upper bound, and L is
Fig. 11. Access delay for two-way transfers.
for the lower bound). We can see that in the one-way case, the two curves stay very close; in the two-way case, the simulation curve is very close to the lower bound of the analytical curve, matching our argument in Section IV-A.
VI. CONCLUSION
In this paper, we have studied the impact of DOCSIS MAC layer operation on the performance of TCP over HFC networks. We learned that the asymmetry ratio expressed in [10] cannot adequately explain the behavior of TCP in DOCSIS-based HFC networks. To better capture the effect of DOCSIS, we express the asymmetry ratio in another way, denoted by , considering the TDMA-like MAC layer operation of DOCSIS. When , TCP behaves as in a symmetric network; when the system acts as in an asymmetric network, and the performance of TCP degrades. We find that the number of simultaneous transfers sig-nificantly affects the asymmetry ratio. If the number of active CMs is below two times the maximum number of pending re-quests in a transmission period, the value of is larger than one, regardless of the value of . However, as the number of active CMs becomes very large, the effect of DOCSIS on TCP becomes negligible, and the asymmetry ratio is determined by the bandwidth ratio of channels times the length ratio of data and ACK packets.
In our analysis, both one-way and two-way transfers are con-sidered. With two-way transfers, the downloading CMs mostly experience network asymmetry, but operate in the lower bound of in the steady state. Based on , the RTT of sending a data packet is developed for both one-way and two-way transfers, and the buffer requirement at the CMTS is discussed. We have also conducted simulations to verify the analytical results. The results show a good match between the simulation and the analysis. To the best of our knowledge, this is the first paper providing a theoretical study on the performance of TCP over DOCSIS-based networks. The analytical result can provide useful guidelines in the design of slot allocation or scheduling mechanisms for DOCSIS-based systems. More importantly, the proposed analytical model can be used to evaluate the performance of resource management mechanisms designed for any DOCSIS-based broadband access networks, including the emerging IEEE 802.16 WiMAX networks.
REFERENCES
[1] CableLabs, Data-Over-Cable Service Interface Specifications—Radio
Frequency Interface Specification, SP-RFIv1.1-106-001215, MCNS
Consortium, 2000.
of IP oriented HFC access protocols,” in Proc. Broadband Commun., 2000, pp. 133–138.
[9] M. T. Ali, R. Grover, G. Stamatelos, and D. D. Falconer, “Performance evaluation of candidate MAC protocols for LMCS/LMDS networks,”
IEEE J. Sel. Areas Commun., vol. 18, no. 7, pp. 1261–1270, Jul. 2000.
[10] H. Balakrishnan, V. N. Padmanabhan, and R. H. Katz, “The effects of asymmetry on TCP performance,” Mobile Netw. Appl. 4, pp. p219–p241, 1999.
[11] Y.-D. Li and W. Liao, “Improving TCP performance over asymmetric networks,” in Proc. IEEE ICC, Helsinki, Finland, Jun. 2001, pp. 1824–1828.
[12] S. Varma, “Performance and buffering requirements of TCP applica-tions in asymmetric networks,” in Proc. IEEE INFOCOM, New York, NY, 1999, pp. 1548–1555.
[13] W. Liao and H.-J. Ju, “Adaptive slot allocation in DOCSIS-based CATV networks,” IEEE Trans. Multimedia, vol. 6, no. 6, pp. 479–488, Jun. 2004.
[14] T. V. Lakshman, U. Madhow, and B. Suter, “Window-based error recovery and flow control with a slow acknowledgement channel: A study of TCP/IP performance,” in Proc. IEEE INFOCOM, 1997, pp. 1199–1209.
[15] R. Cohen and S. Ramanathan, “TCP for high performance in hybrid fiber coaxial broad-band access networks,” IEEE/ACM Trans. Netw., vol. 6, no. 1, pp. 15–29, Feb. 1998.
M.S. degrees from National Chiao Tung University, Hsinchu, Taiwan, R.O.C., in 1990 and 1992, respec-tively, and the Ph.D. degree in electrical engineering from the University of Southern California, Los An-geles, in 1997.
She joined the Department of Electrical Engi-neering, National Taiwan University (NTU), Taipei, Taiwan, as an Assistant Professor in 1997. Since August 2005, she has been a Full Professor. Her research interests include wireless networks, multi-media networks, and broadband access networks.
Dr. Liao is currently an Associate Editor of the IEEE TRANSACTIONS ON
WIRELESSCOMMUNICATIONSand the IEEE TRANSACTIONS ONMULTIMEDIA. She was a tutorial Co-Chair of IEEE Infocomm 2004, and the TPC Vice-Chair of IEEE Globecom 2005 (the Autonomous Network Symposium). She has re-ceived many research awards. Two papers she co-authored with her students received the Best Student Paper Award of the First IEEE International Confer-ences on Multimedia and Expo (ICME) in 2000, and the Best Paper Award of the First International Conference on Communication, Circuits and Systems in 2002. She was a recipient of the K. T. Li Young Research Award given by the ACM Taipei chapter in 2003 for her research achievement. She was elected as one of Ten Distinguished Young Women in Taiwan in 2000, and was listed in
Who’s Who (New Providence, NJ: Marquis) in 2001–2005, and the Contempo-rary Who’s Who in 2003.
