Internet DRAFT - draft-xu-rrcp
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
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]
