Internet DRAFT - draft-xu-rrcp


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 

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-

   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 

   The list of Internet-Draft Shadow Directories can be accessed at 

   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 
   ( 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. 


   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 
   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 

   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 

   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 

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 

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 
   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, 

9. Acknowledgments 

   The authors thank to the funding supports of the CERNET, CNGI-
   CERNET2, CNGI Research and Development, China "863" and China 

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 

   Chunmei Xia 
   Dept. of Comp Sci. & Tech., Tsinghua University 
   ROOM9-402, East Main Building, Tsinghua University 
   Beijing  100084 

Xu, et al             Expires September 14,2013              [Page 16]