Network Working Group Mingwei Xu Internet Draft Chunmei Xia Intended status: Informational Tsinghua University Expires: September 14, 2013 March 14, 2013 RRCP A Receiver-Driven and Router-Feedback Congestion Control Protocol for ICN draft-xu-rrcp-01.txt Status of this Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html This Internet-Draft will expire on September 14, 2013. Xu, et al Expires September 14,2013 [Page 1] Internet-Draft draft-xu-rrcp-01 March 2013 Copyright Notice Copyright (c) 2013 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Abstract Network requirements have evolved from data communications between two hosts to large-scale information access through networks. The current Internet employs an address-centric network communication model, which is efficient for communications between hosts, but not efficient for communications between a host and a network. Given this fact, Information-centric Networking (ICN) has become a hot spot to meet the new requirement. In ICN there exists a congestion problem which hasn't been well solved. We provide a new congestion control protocol, RRCP, since the congestion control protocols in IP networks are not suitable for ICN transport. RRCP, with XCP and ICN transport characteristics, advances a receiver-driven and router- feedback mechanism. RRCP can stay efficient, fair and stable via the validation of simulation. Table of Contents 1. Introduction ................................................ 3 2. ICN Transport ............................................... 7 3. The Problem TCP Used In ICN ..................................8 4. RRCP Design ................................................. 9 4.1. RRCP Framework ......................................... 9 4.2. The Congestion Header .................................. 10 4.3. The RRCP Sender ........................................ 10 4.4. The RRCP Receiver ...................................... 11 4.5. The RRCP Router ........................................ 11 4.5.1. The Efficiency Controller(EC) ..................... 11 4.5.2. The Fairness Controller(FC) ....................... 12 4.6. Timeout Mechanism ...................................... 13 Xu, et al Expires September 14,2013 [Page 2] Internet-Draft draft-xu-rrcp-01 March 2013 5. Security Considerations ..................................... 13 6. IANA Considerations ........................................ 13 7. Conclusions ................................................ 13 8. References ................................................. 14 9. Acknowledgments ............................................ 15 1. Introduction Network requirements are evolved from data communications between two hosts to accessing a large amount of information through networks, which gives a new challenge to the current address-centric network architecture. Under the requirements based on accessing a large amount of information, the users show concern for the contents, not for the hosts' addresses. The current address-centric network has no high efficiency and produces a lot of redundant datum due to not suitable for the requirement. Given this fact, Information- Centric networking (ICN) becomes the hot spot to meet the new requirements. Currently, some ICN schemes are advanced, such as CCN[1], NetInf[2,3], DONA[4]. These schemes give a preliminary research on the framework, but don't discuss some details such as the routing optimization algorithm, troubleshooting algorithm and congestion control protocol. This draft mainly discusses the congestion control protocol. As we all know, the congestion in IP is composed of two parts. One is the terminal congestion. Because the sending rate is higher than the receiving rate, the receiver can't handle the input packages in time. This leads to package losses. The other is the network congestion. When the handling rate of router is lower than the sending rate, this will make the input queue in router overflow so that the package drops and RTT becomes longer. ICN still exists the congestion. The congestion in ICN is slightly different from it in IP. Because ICN is pull based transport where when the receiver sends a request, the sender responds a data, the terminal congestion doesn't appear in ICN. ICN routes the packages based on the information name. When the forwarding rate of router is lower than the input rate of the packages, the input queue will overflow after a long time. This obviously leads to the input packages' losses and the network congestion. For example, Fig.1 shows a topology. Because the Router2 which has three input and one output only deals with one input package each time , the other two input packages is put into the input queue. Every time the Router2 stores two packages into the input queue, after a long time, the input queue will overflow. At this time, the Router2 can't receive the new input package and only drops them so that the network congestion appears. In Fig.1, the link between Router1 and Router2 is a bottleneck. It is a location of congestion. Xu, et al Expires September 14,2013 [Page 3] Internet-Draft draft-xu-rrcp-01 March 2013 +---+ +---+ | |----------- ----------| | +---+ | | +---+ Receiver1 | | Sender1 +---+ +---+ +---+ +---+ | |---------| |--------| |--------| | +---+ +---+ +---+ +---+ Receiver2 Router1 Router2 Sender2 +---+ | | +---+ | |----------- ----------| | +---+ +---+ Receiver3 Sender3 Figure 1 an example of congestion in ICN We must provide the appropriate congestion control protocol for ICN. There are many congestion control protocols in IP network such as TCP Tahoe[5], TCP Reno[6], TCP NewReno[7], TCP Sack[8], TCP Vegas[9], XCP[10]. The first five protocols is based on TCP, whileas XCP is a feedback protocol. ICN transport is different from IP transport, in ICN the transport is pull based and end-to-network modes, therefore, all congestion control protocols in IP networks can't directly be applied to ICN. At present, the congestion control mechanism in ICN is already discussed, such as ConTug[11], RDITP[12]. These schemes advance different congestion control mechanisms for different ICN schemes. ConTug based on TCP provides a receiver-driven congestion control mechanism. Due to the apparent unpredictability of cache sources, ConTug raises a multi-window mechanism which allocates multiple windows according to the information source. Since ICN uses pull based transport model where the senders transmit the packages passively, ConTug suggests the receiver-driven transport mechanism. Based on a identified segment source, ConTug defines a split window which implements TCP protocol, The general window is a sum of all split windows. RDITP also provides a receiver-driven congestion control mechanism which is similar with TCP. The two schemes based on TCP and the ICN transport features don't decouple utilization control from fairness control. This leads to each other's influence so that efficiency and fairness can't achieve the best. The two schemes start handling the unpredictable cache sources after a rtt. The reaction rate is slow. When adding a window for the source, the source may disappear. The lagging handle leads to error. In addition, given a cache source, ConTug will create a new window, Xu, et al Expires September 14,2013 [Page 4] Internet-Draft draft-xu-rrcp-01 March 2013 this increases the complexity of the system. The slow start in the two schemes has a low utilization for the high bandwidth-delay network which will be common in ICN core. If a package is lost during slow start, the two schemes drop into AIMD which has worse utilization than slow start. For example, given a transport where link bandwidth is 10Gb/s, RTT is 200ms and the payload is 1460B, and assuming no loss during the transport, the link utilization in slow start is 8.5%. This value isn't very good. Moreover, the window's oscillation between initial value and the maximum value leads to bad stability. This draft advances a congestion control protocol RRCP which is suitable for ICN. RRCP based on XCP and ICN's transport characteristics remains high efficiency, fairness and stability. Due to ICN's pull based transport, RRCP still uses receiver-driven pattern. In the intermediate routers ICN has cache which is a unpredictable information source whose contents change continuously according to the policy. We design a router-feedback mechanism for the unpredictable cache sources. The feedback value and location are set according to the cache, spare bandwidth, queue and flow. ICN supports the multi-source concurrent distribution for a request. In RRCP, we needn't create a new window for each channel, because we adopt the feedback mechanism. We need only create a new window for each Interest package. In RRCP, the routers deploy fairness controller and efficiency controller which compute the feedback. RRCP allocates the aggregate bandwidth according to the content's popularity, if the popularity of the content required is high, the flows of the content is allocated the more bandwidth. We decouple utilization control from fairness control. This allows a more flexible and analytically tractable protocol design. The feedback is put into the new defined congestion header instead of the router. This ensures stateless in the intermediate router and shows good scalability. In RRCP, we adopt the feedback mechanism because the feedback mechanism accurately reflects the real change of the network. When there is the unpredictable cache in the channel, the Data package is returned directly from the router with the cache source. The routers receiving the Data package compute the new feedback and put the feedback into the congestion header of the Data package. The feedback is a totalized value of feedbacks of all routers along the path. If the path is changed, the feedback will change. So the feedback can show not only the change of the flows, but also the change of the channel. Accordingly, an uncertain cache source brings about the change of the channel, while the change of the channel will bring about the change of the feedback. The feedback Xu, et al Expires September 14,2013 [Page 5] Internet-Draft draft-xu-rrcp-01 March 2013 mechanism can quickly reflect the channel's change so that it is suitable for ICN with the unpredictable cache source. Comparing with ConTug, RRCP: a) has a faster handling rate. When a new cache source returns the data, RRCP directly gets a feedback from new channel. There is no delay in handling the change. ConTug needs a RTT to handle the change. b) has greater flexibility. Since the unpredictable cache source the transport channels often switch. ConTug uses the new window to control the transport of the new channel. This method is stupid and complicated. RRCP straightly uses the new feedback to change the congestion window. This makes the window to control the transport of the new channel. Accordingly, RRCP may use a window to control the transports of multiple channels. c) isn't easy to drop. The feedback is an accumulated value which is a minimum bottleneck value of all routers along the path. RRCP adjusts the window according to the feedback. The new window will control the input flow lower than the bottleneck of the path. Accordingly, RRCP isn't easy to drop. d) has good utilization, fairness and stability. The feedback is computed by the efficiency controller and the fairness controller. The efficiency controller ensures the maximum link utilization, whereas the fairness controller ensures the proportional fairness. The two controllers ensure that RRCP has good utilization and fairness. The feedback is a real value, it can't suddenly become 1 from the maximum value, then, become the maximum value from 1, so RRCP is more stable than the protocols similar with TCP. We simulate RRCP under the different scenarios, such as two topologies with cache and with no cache. In the simulation, we use the real flow whose package header is handled. This ensures the lower mechanism close to ICN. The simulation results shows that RRCP is suitable for ICN transport and has better fairness, efficiency and stability than ConTug. Xu, et al Expires September 14,2013 [Page 6] Internet-Draft draft-xu-rrcp-01 March 2013 2. ICN Transport 1) Because ICN often uses multi-source distribution, information is responded to a receiver via multiple channels. ICN often uses the multi-source distribution algorithm for higher transport efficiency. The main idea of this algorithm is responding different data blocks of the information to the receiver from multiple sources at the same time. In the multi-source transport mechanism, the routers select the information sources and divides the Interest package for the information into several Interest packages for different blocks of information. These split Interest packages are sent to the different information sources via the different channels so that the sources can respond to the different parts of information to the receiver. The receiver reconstructs the blocks into the complete information. Accordingly, in the multi- source transport, a request package will be divided into several request packages. Each request has a window to control the channel's transport. We should independently consider the congestion control of each request. Otherwise, this will lead to disturb each other and increase the complexity of the congestion control protocol. 2) The intermediate nodes have caches which store the information in ICN. The data in the caches change continuously over time. This will lead to unpredictable sources which bring uncertainty for information transport. Adding the cache into the routing is the apparent feature in ICN. The cache makes a tradeoff between storage costs and transport efficiency. It is proved by the practice and theory that the caches bring higher efficiency and less resources' use. But the cache also leads to the complexity of the congestion control protocol. During the transport process, the channel might change at any time due to the cache. TCP is hard to adapt to the change. We should advance a sensitive congestion control protocol for the unpredictability of cache sources. 3) ICN uses pull based transport. The information sources passively respond to the receiver. The transport of the current IP network is push-based, the sender proactively sends the datum to the receiver. In ICN, a receiver pulls the datum from the network, not a single server. The source doesn't know who requests the datum and which data is requested in Xu, et al Expires September 14,2013 [Page 7] Internet-Draft draft-xu-rrcp-01 March 2013 the next time. Accordingly, the resulting congestion control protocol is necessarily receiver-driven. Given the upper facts, we should design the congestion control protocol for each feature. The resulting congestion control protocol is necessarily suitable for ICN. 3. The Problem TCP Used In ICN 1) Because of the unpredictability of cache sources in ICN, the TCP window can't accurately and quickly reflect the states of the variable channels. This leads to more packages missing and the transport efficiency decreasing. In ICN, cache sources are unpredictable. The unpredictability leads to the transport channel changing. TCP window changes with the arrival of the Data packages in ICN. When the cache source is closer to the receiver, RTT becomes smaller and the sending interval of the TCP window is smaller, furthermore, the transport rate will be increased. If the close cache source is disappear, the Data packages are responded from the further sources. In this situation, if the window value is bigger than the congestion value of the new channel, the congestion will happen and some packages will miss. We still take Fig.1 for an example, the bottleneck is the link between Router1 and Router2. Suppose the current bottleneck value is 8 packages. When Router1 responds the Data packages to Receiver1, the window in Receiver1 is increasing. When the window increases to 12, because the cache source updates the data and has no the needed data, the data is returned only from Sender1. Because the bottleneck value of the channel from Receiver1 to Sender1 is 8, while the window value is 12, if Receiver1 still sends Interest according to the window value, the network congestion will happen and some packages will miss. 2) One feature of TCP is quickly grabbing the bandwidth. The fairness of TCP need be improved in the future. The feature of TCP is quickly grabbing the bandwidth. When the receiver gets the Data packages, TCP increases the window until the bandwidth is used up. During the communication between one user and the server, if the other user requests the data, the first user doesn't decrease the window and enjoy the bandwidth with the second user. Accordingly, there isn't a good fairness in TCP. Xu, et al Expires September 14,2013 [Page 8] Internet-Draft draft-xu-rrcp-01 March 2013 4. RRCP Design In the congestion control protocol, drops become a sign of congestion. In fact, the drop is a necessary condition of congestion, not a sufficient condition. In the congestion control protocol, we should consider a true feedback selecting congestion losses or error losses. This draft provides a receiver-driven router-feedback congestion control protocol-RRCP. RRCP based on XCP and the ICN transport features remains efficiency, fairness and stability. 4.1. RRCP Framework Fig. 2 shows the RRCP framework. Firstly, we still use the single- window mechanism for the multi-source transport in ICN. Because RRCP is a feedback mechanism in which the feedback value may accurately reflect the change of the sources, the single window change with the feedback value and may reflect the variability of the sources. Secondly, ICN is pull based transport. Accordingly, RRCP controls congestion window via the receiver. The receiver sends Interest according to window, while the sender gives a response according to the Interest's rate. We adopts receiver- driven to control transport and avoid congestion. At last, we address a router-feedback mechanism for the changing cache sources. In the router, we set the efficiency controller and fairness controller which compute the spare bandwidth and the feedback per flow regularly. In RRCP, we consider allocating the spare bandwidth to each flow based on the popularity of content in the fairness controller. When the Data packages return, the feedback is put into the congestion header of Data package. In each router along the path, the feedback is recalculated until the Data package returns the receiver. The resulting feedback is an accumulated value. The router-feedback mechanism may precisely show the congestion of network and select the feedback location based on the cache sources so that it can handle the unpredictability of the cache sources in ICN. Xu, et al Expires September 14,2013 [Page 9] Internet-Draft draft-xu-rrcp-01 March 2013 Data package with feedback <------------------------------------------ +---+ +---+ +---+ | |-------------| |-------------- | |------------ +---+ +---+ +---+ receiver router router -----------------------------------------> Interest package(H-cwnd=H-cwnd+H-feedback) Figure 2 RRCP framework 4.2. The Congestion Header In RRCP, the feedback is put into the congestion header, not the router. Fig. 3 defines the congestion header. The field H-cwnd is the congestion window, whereas the field H-rtt is the RTT of the channel. These fields are filled by the receiver and never modified in transit. The remaining field, H-feedback, is the feedback of the router. The data is a totalized value. The initial value is provided by the receiver, while the routers along the path modify the value to directly control congestion window of the receiver. +-------------------+ | H-cwnd | +-------------------+ | H-rtt | +-------------------+ | H-feedback | +-------------------+ Figure 3 Congestion header 4.3. The RRCP Sender In RRCP, since we adopt the receiver-driven congestion control, the sender isn't the driver of the congestion control. The RRCP sender is similar to a TCP receiver except that it copies the congestion header from Interest package to Data package. What's more, in ICN, cache might uncertainly give a response to the receiver as an information source. In RRCP, due to the precise feedback mechanism, the routers along the path give a feedback when Data package returns from cache. During the process, a new Xu, et al Expires September 14,2013 [Page 10] Internet-Draft draft-xu-rrcp-01 March 2013 channel's congestion control is naturally formed between the receiver and the cache source. 4.4. The RRCP Receiver The receiver controls the transport rate of network as a driver of congestion control in RRCP. In the beginning, the receiver sets the initial values for H-cwnd and H-rtt. After a RTT, H-cwnd and H-rtt are set to true values, the two values isn't modified during the transport. When the receiver gets the new feedback, it recalculates H-cwnd and H-rtt. If the feedback is positive, H-cwnd is increased. If the feedback is negative, H-cwnd is decreased. 4.5. The RRCP Router In RRCP, the job of the router is to compute the feedback to cause the system to converge to optimal efficiency and proportional fairness. We set the efficiency controller and the fairness controller in the router and decouple efficiency control from fairness control. The efficiency controller computes aggregate traffic and uses MIMD. The fairness controller uses AIMD and computes the feedback per flow in order to get the best utilization and fairness. The router computes the feedback per average RTT. Estimating the feedback over intervals longer than average RTT leads to sluggish response, while estimating the feedback over shorter intervals leads to erroneous estimates. 4.5.1. The Efficiency Controller(EC) EC computes the spare aggregate traffic to ensure the maximum link utilization. The spare aggregate traffic is associated with the spare bandwidth, the queue size. In the average RTT's interval, the aggregate feedback F is increased when the spare bandwidth is increased, while the aggregate feedback F is decreased when the persistent queue size is increased. We may judge if network is congested via F. If F>0, the network is underutilized and the resource of the router is spare. At this time, the receiver may increase the requests' frequency to utilize the spare traffic as much as possible. Eventually, network transport efficiency is increased. If F<0, the network is congested. The congestion window is decreased due to negative feedback. This decreases the resource utilization, then, relieves the network congestion. Generally speaking, because RRCP is a feedback mechanism, the stable spot should remain close to the cliff of curve, not over the cliff. Thus, RRCP doesn't drop packages. In this draft, we raise timeout mechanism to solve the drops seldom appeared. Xu, et al Expires September 14,2013 [Page 11] Internet-Draft draft-xu-rrcp-01 March 2013 4.5.2. The Fairness Controller(FC) FC considers the fairness of each flow. The purpose of EC is to maximum the spare resource's utilization, while FC allocates the spare resource to each flow. FC ensures proportional fairness. As we all know, Network traffic distribution abides by Two Eight Law where twenty percent flows hold eighty percent of the whole traffic. The twenty percent flows are the popular ones. In ICN, the popularity has a great influence with network transport efficiency. Because the transport numbers of the popular contents are far more than that of the unpopular contents in the networks, the transport rates of the popular contents decide the transport efficiency of the whole network. ICN uses in-path caches to improve the transport rates of the popular contents because the caches basically store the popular contents. As the congestion control mechanism in ICN, RRCP can't only ensure the max-min fairness, but also ensures the proportional fairness according to the content's popularity. In RRCP, we should allocate more bandwidth to the popular contents in order to improve the transport efficiency of the whole network. Because the popular flows hold eighty percent of the whole network traffic, we should allocate eighty percent bandwidth to the popular flows, while the unpopular flows only get the remaining bandwidth. We allocate the same bandwidth for the contents with the same popularity. In RRCP, we only consider the popular and unpopular contents. In fact, popularity may have fine-grained classification. We may define the popular levels according to the requiring numbers of the contents. For example, we define the most requiring contents as the first level popularity and allocate the most bandwidth to them. We define the second most requiring contents as the second level popularity and allocate the second most bandwidth to them, and so on. We may compute the requiring numbers of the content to obtain the popularity of the content. The specific popularity algorithm is beyond the scope of the draft. Given in a certain time, the numbers of the popular flows are m, while the numbers of the unpopular flows are n. Thus, we compute the per-flow feedback based on the popularity according to the policy: If F>0, when the popularity of the flow is high, allocate it so that the increase in throughput of all flows is 4F/(n+4m). If F>0, when the popularity of the flow is low, allocate it so that the increase in throughput of all flows is F/(n+4m). If F<0, allocate it so that the decrease in throughput of a flow is proportional to its current throughput. Xu, et al Expires September 14,2013 [Page 12] Internet-Draft draft-xu-rrcp-01 March 2013 When F = 0, the system is stable, then, the feedback is always 0. This may result in convergence stalling. We still use the bandwidth shuffling to defend convergence stalling. The bandwidth of 10% are simultaneously allocated and deallocated so that the total traffic rate doesn't change. 4.6. Timeout Mechanism RRCP seldom drops packages, but if the network shows the drops, we provide the timeout handling mechanism. If the network has losses, the receiver sets the congestion window half to relieve the network congestion and control the losses. When the congestion is relieved after a RTT or several RTTs, the routers will return the new feedback. Then, the network enters the state of a new feedback. If the network shows losses over the timeout, the router will forward the same Interest, while in the timeout, the router will drop the same Interest which is repeated forwarding. Dropping the repeated Interest defends the loop. RRCP as a feedback mechanism may differentiate the dropping cause. If the feedback is positive, the network is fluent. At this time dropping packages is resulted from the error. If the feedback is negative, the network is congested. At this time dropping packages is resulted from the congestion. RRCP uses the feedback to distinguish the erroneous losses from the congested losses, this solves that all losses are handled by the timeout. 5. Security Considerations Security considerations to be provided. 6. IANA Considerations This document requires the allocation of one protocol number by the IANA. This document requires that IANA will maintain the registry of ICN namespaces. 7. Conclusions Network requirements are evolved from the resource sharing to the information accessing. Information becomes the core of the network research. The network based on host isn't already suitable for the high efficiency's demand of information accessing. Information Centric Network (ICN) becomes the hot spot. ICN exists congestion which isn't well solved. The existing congestion control protocols in IP network aren't suitable for ICN transport. Accordingly, we must study a novel protocol or modify a current protocol to control Xu, et al Expires September 14,2013 [Page 13] Internet-Draft draft-xu-rrcp-01 March 2013 the congestion in ICN. In this draft, we advance a congestion control protocol-RRCP for ICN transport. RRCP based on XCP and ICN transport features raises the receiver- driven and router-feedback mechanisms. Generally speaking, RRCP doesn't almost drop, but the information transport is easy to occur congestion. We design the timeout mechanism for ensuring RRCP work normally under the scenarios of drops. 8. References [1] Van Jacobson, Diana K.Smetters, James D. Thornton, Michael F. Plass, Nicholas H. Briggs, Rebecca L. Braynard. Networking Named Content. CoNEXT'09, December 1-4, 2009. [2] BengtAhlgren, MatteoD'Ambrosio, Christian Dannewitz, Marco Marchisio, Ian Marsh, BorjeOhlman, Design Considerations for a Network of Information, ReArch'08, December 9, 2008. [3] BorjeOhlman, BengtAhlgren, Marcus Brunner and etc. First NetInf architecture description, FP7-ICT-2007-1-216041-4WARD / D-6.1, April 1,2009. [4] TeemuKoponen, MohitChawla, Byung-Gon Chun, AndreyErmolinskiy, Kye Hyun Kim, Scott Shenker, Ion Stoica, A Data-Oriented (and Beyond) Network Architecture. SIGCOMM'07, August 27-31, 2007. [5] Postel, J. (ed.), "Transmission Control Protocol -DARPA Internet Program Protocol Specification", RFC 793, Information Sciences Institute/USC, September 1981. [6] W. Stevens. TCP Slow Start, Congestion Avoidance, Fast Retransmit, and Fast Recovery Algorithms. RFC 2001, Jan. 1997. [7] S. Floyd and T. Henderson. The NewRenoModification to TCP's Fast Recovery Algorithm. RFC2582, April 1999. [8] M. Mathis, J. Mahdavi, S. Floyd, and A. Romanow. TCP Selective Acknowledgment Options. RFC 2018, October 1996. [9] L. Brakmo, S. O'Malley, and L. Peterson. TCP Vegas: New techniques for congestion detection and avoidance. In Proceedings of ACM SIGCOMM 1994. Xu, et al Expires September 14,2013 [Page 14] Internet-Draft draft-xu-rrcp-01 March 2013 [10] Dina Katabi, Mark Handley, and Charlie Rohrs. Congestion Control for High Bandwidth-Delay Product Networks, In: Proceedings on ACM Sigcomm2002. [11] Arianfar, S., Eggert, L., Nikander, P., Ott, J., and Wong, W. Contug: A receiver-driven transport protocol for content- centric networks. Under submission, 2010. [12] S. Salsano, A. Detti, Receiver driven trasport protocol for CONET ICN, draft-salsano-rditp-00, Internet Draft, http://tools.ietf.org/id/draft-salsano-rditp-00.txt. 9. Acknowledgments The authors thank to the funding supports of the CERNET, CNGI- CERNET2, CNGI Research and Development, China "863" and China "973"projects. Xu, et al Expires September 14,2013 [Page 15] Internet-Draft draft-xu-rrcp-01 March 2013 Authors' Addresses Mingwei Xu Dept. of Comp Sci. & Tech., Tsinghua University ROOM4-104, FIT Building, Tsinghua University Beijing 100084 CN Email: xmw@cernet.edu.cn Chunmei Xia Dept. of Comp Sci. & Tech., Tsinghua University ROOM9-402, East Main Building, Tsinghua University Beijing 100084 CN Email: xcm19770312@sina.cn Xu, et al Expires September 14,2013 [Page 16]