In this paper, we describe a new method, called RWTM (Receive Window Tuning Method) that shapes HTTP adaptive streams. It employs the flow control in the gateway to improve the quality of experience (QoE) of users. Our use case is when two HTTP Adaptive streaming clients are competing for bandwidth in the same home network. Results show that our proposed method considerably improves the QoE; it improves the video stability, the fidelity to optimal video quality level selection and the convergence speed to the optimal video quality level. Keywords— Traffic Shaping; Quality of Experience; HTTP Adaptive Streaming; TCP flow control; Bandwidth Management I. MOTIVATION HTTP Adaptive Streaming (HAS) is a streaming video technique based on downloading video segments of short duration (two seconds in general), called chunks, from a HAS server to a HAS client. Each chunk is encoded at multiple quality levels, also called encoding bit rates, or profiles. After filling its playback buffer with chunks, the player in the HAS client will request for chunk periodically in the steady-state phase. The Steady-State phase includes periods of activity (ON periods [1] or Active periods [2]) followed by periods of inactivity (OFF periods [1] or Idle periods [2]). The player estimates the available bandwidth during the ON period to select the video quality level for the next chunk. The Quality of Experience (QoE) of HTTP adaptive stream depends mainly on three criteria: 1-Video quality level stability; because the frequent change of video quality level bothers the user; 2-Fidelity to optimal quality level selection; the user prefers watching the highest feasible quality level that the available bandwidth allows. This quality level is called optimal quality level; 3-Convergence speed: The user prefers to achieve watching the optimal quality level as soon as possible. The delay that the player takes to reach the optimal quality level is called convergence speed [3]. Our use case is when two HAS clients are competing for bandwidth in the same home network and they request chunks from the same HAS server. In this case, the two main causes of QoE degradation are congestion events and competition between HAS streams. In fact, congestion events-which occurs frequently in the home gateway [5]-reduces the bitrate of packets sent to the HAS clients which degrades the QoE. In addition, when two players compete, they may do false estimation of available bandwidth; for example, if the ON period of the first player coincides with the OFF period of the second player, the first player will overestimate its available bandwidth. As a consequence, it will not select the optimal quality level for the next chunk, hence the degradation of QoE. The objective of our study is to improve the three criteria of QoE cited above when HAS clients are competing for bandwidth. The remainder of this paper is organized as follows. In Section II we present our method, called the " Receive Window Tuning Method " (RWTM). Section III presents the results of our experimentations. In Section IV we conclude the paper and give future directions for our work. II. RECEIVE WINDOW TUNING METHOD Our proposed method " Receive Window Tuning Method " , RWTM, is based on TCP flow control. In fact, TCP uses this flow control mechanism in order to prevent a sender from sending more packets than the receiver capacity. In each TCP segment the receiver specifies the maximum amount of data to be buffered. This specification is sent to the sender in the receiver's advertised window field, rwnd. The sender can not exceed the amount W=min(rwnd, cwnd) of bytes, called the sender's send window, when sending packets. Where cwnd is the congestion window size. As a consequence, if rwnd becomes constant and cwnd exceeds it, the send window will still be constant and equal to rwnd. Therefore, the theoretical sending rate will be always limited by the maximum bitrate rwnd/RTT, which can be considered as the shaping rate. Where RTT is the round-trip time between the client and the server. The idea is to modify the value of rwnd to have a sending rate limited by rwnd/RTT. For instance, in Linux, it is possible to set the parameter net.ipv4.tcp_rmem in the client side. However, this sets the maximum socket buffer size for all TCP connections on the client [4], without regard to the specific needs or constraints of each connection. Instead, it is possible to modify the header of each Acknowledgment packet (ACK) sent from the HAS client to the HAS server at the gateway. Another advantage of using the gateway is that the gateway is the device that has information about incoming traffic of all clients of the same home network. So, it has the capability to manage the bandwidth of the home network. Moreover, the shaping rate, rwnd/RTT, requires RTT estimation. This estimation is possible in the gateway by using a passive estimation of RTT described in [7]. It uses only acknowledgments (ACKs) sent from clients to the server. We use this estimation only one time for each requested chunk.