Design of Link and Routing Protocols for Cache-and ...

Design of Link and Routing Protocols for Cache-and-Forward Networks· Shweta Jain, Ayesha Saleem, Hongbo Liu, Yanyong Zhang, Dipankar Raychaudhuri Abstract---Cache-and-Forward (CNF) is a future Internet architecture designed for content delivery to mobile users over wireless networks with varying link quality and intermittent connectivity. The CNF protocol is based on strict hop-by-hop transport of media files with in-network storage at each router or wireless access point. The protocol also incorporates content caching capabilities for efficient delivery of popular media files. In this paper, we briefly describe the CNF architecture, present a survey of prior work, and describe new CNF link and routing protocols. Throughput results comparing CNF with TCPIIP are summarized for an example wide-area Internet scenario with wireless access networks. The design of a reliable CNF link layer protocol is discussed and performance results are given for multihop wireless scenarios. The paper concludes with an outline of dynamic CNF routing algorithms which consider both short-term and long-term path quality along with available in-network storage.

F

I.

INTRODUCTION

uture Internet usage is expected to involve an increasing proportion of content de~ivery to m~bi~e end users. The mobile content delIvery scenano IS associated with wireless access networks of varying quality, with the likelihood of occasional disconnection. The end to end connection model of today's TCP/IP is unsuitable for mobile and wireless Internet access [1], and this has motivated a variety of transport protocol enhancements such as I-TCP [2] and CLAP [3]. More recently, the networking community has started to consider so-called "clean-slate" protocol solutions under research programs such as NSF (FIND [4] and GENI [5]) in the US, and FP7 Future Networks [6] and FIRE [7] in Europe. A completely new protocol design for mobile content delivery has the potential to significantly improve performance and robustness relative to existing TCP/IP. In this paper, we present preliminary results on such a clean-slate network design from an ongoing NSF FIND research project called the "cache-and-forward" architecture. Cache-and-forward (CNF) is a clean slate information centric architecture specifically optimized for mobile content delivery. The architecture is based on innetwork storage at routers along with hop-by-hop transport of large media files. Figure 1 shows the conceptual view of the CNF architecture as envisioned in [8]. As illustrated in the figure, a media file is routed in a hop-by-hop manner towards its destination. If the path quality is poor, or the enduser is temporarily disconnected, the network stores the file in transit, delivering it at a later time when conditions improve. The routing protocol incorporates awareness of

1 Research supported by the National Science Foundation's NeTS-FIND program under collaborative grant # CNS-0626959.

both short-term and long-term path metrics along with innetwork storage availability. l\Julti-hop 'Vir~I~5.~ .-\cce~~ n~",'ork

Reliable Link L.n·er In Network StorllKe ~/:->/~

Content Retriel'al Interface

Content Retriel'al Protocol

Figure 2: CNF Protocol Stack

Although proposed as a "clean slate" design, CNF can also be implemented as an overlay over IP. CNF routers have sufficient storage capacity for temporary storage while awaiting connectivity with mobile destinations and for innetwork caching of content. The network is robust to intermittent disconnections, a feature similar to disruption tolerant networks (DTN) [9]. CNF's hop-by-hop transport protocol contrasts with the connection-oriented TCP model, and has the potential for significant throughput and delay improvements even in various wired and wireless network scenarios [10]. CNF also supports content and information centric applications by supporting a mode in which the end-user can directly request content files from the network using a content identifier tag (CID). Caching and content retrieval are thus as an integral part of the underlying network and the routing protocol in CNF. The content delivery protocol is responsible for searching the in-network caches to find the nearest copy of the content rather than fetching the content from the original source. This requires efficient content caching and cache advertisement protocols as discussed in [11 ]. In the following sections we present a brief summary of the CNF protocol architecture. We then present

Authorized licensed use limited to: Univ of Calif Los Angeles. Downloaded on April 05,2010 at 02:10:39 EDT from IEEE Xplore. Restrictions apply.

the design and evaluation of CNF link layer protocol that provides reliable hop-by-hop file transfer. We then present results from prior work showing the network performance of end-to-end CNF transport using this CNF link protocol and static routing. We conclude with an outline of a dynamic CNF routing protocol that finds the best path to the destination taking into account short-term and long-term path quality along with availability of in-network storage. II. CNF ARCHITECTURE The CNF network [8] consists of wired core as well as wireless access clouds. Each network router or wireless access point/base station has large storage capacity which can be used for packets in transit as well as to provide innetwork caching service for popular content. The network provides traditional client server communication as well as content and file delivery. The content delivery may be in either "push" or "pull" mode. In the push mode, the service provider unicasts or multicasts content to the end-users while in the pull mode an end user may request a specific content from the network. Each query and content is transported in a strictly hop-by-hop fashion through the CNF network. CNF introduces the concept of a Post Office (PO) specifically to improve content delivery to mobile users. The PO associates content in transit to its mobile requestor. If a destination becomes unavailable during content retrieval, the content is cached at an intermediate location and the PO is informed. When the mobile reconnects after an interruption, it may query the PO to obtain a pointer to the intermediate cache and resume content retrieval where it was left off instead of making a new request to the content source. The CNF protocol stack (Figure 2) consists of a control plane that consists of file or content name resolution service (CNRS) and content routing service. The data plane contains CNF application, transport, network and link protocols. The CNRS protocol provides naming service for the content and resolves a content name to its actual location. The content routing protocol provides a content discovery service that searches in-network caches to find the content at nearest location from the requestor.

I~ '~

(C'ID.J)

('m.2) (CID, 1)

«'ID.O)

Figure 3: Hop By Hop Transport in CNF

The CNF application is an information centric content service that transmits large files (,....,1O's of GB) to the requestor. In the CNF transport protocol, a very large file (,...., 1O's of GB) is first fragmented into smaller chunks (,...., 1OOMB-l GB) at the original source and each chunk is

tagged with content ID and offset tuples (CID, offset). These chunks are then transmitted in a hop by hop fashion. Error control and congestion control are delegated to the link and network layer keeping the transport protocol much simpler than TCP. Figure 3 illustrates the CNF transport protocol with an example. Here the file is divided into four chunks. Each chunk is identified by the tuple. The transport layer at S sends the chunks to D and transport layer at D reassembles the file from the chunks. The routing layer initially picks the path S-A-C-D but switches to an alternate path A-B-E-D for . This might happen if the original route does not have enough storage space (congestion), the link layer reports a broken link or the routing layer detects a better route in the short term. If the destination is unavailable for a long time, the intermediate router stores the content in its storage space. These route changes and storage decisions are transparent to the transport layer. In summary, the CNF transport protocol serves content query, fragments large content into smaller chunks, reassembles the chunks into the original file, retrieves missing chunks from the network and maintains a content cache. The network protocol discovers routes to the destination after the content has been located and the link layer provides hop by hop reliability for content transmission. In the following sections, we will present the design and evaluation of the CNF link layer followed by prior results in CNF transport and future work in CNF routing protocols. III. CNF LINK PROTOCOL In CNF the link protocol must receive the entire file or content chunk before sending it to the routing layer. Therefore, in this context we introduce per hop file transfer reliability which may be used instead of or in addition to per packet reliability provided by an 802.11 like MAC protocol. When a file to be transferred arrives at the link layer, it is assigned a temporally unique identifier and the file is divided into batches of a fixed number of packets. The link layer then reliably transfers each batch to the next hop before moving onto the next batch. To achieve this reliability we introduce two new link layer control packets, Request for Batch (RFB) and negative acknowledgement NACK. The RFB contains the MAC addresses to identify sending and receiving routers, the file and batch identifiers, the file size, number of packets in a batch and a timestamp indicating when the batch transmission started. The sender relies upon the MAC layer acknowledgement to ensure successful reception of the RFB by the next hop. The sending node must wait for the receiver to transmit a NACK that contains a bitmap indicating the packets from the previous batch that were not received. The receiving node might be in the middle of another batch reception/transmission and therefore the sender might have to wait for as much as the transmission time for the maximum size batch. When the receiving node is ready to receive a batch, it first checks whether any part of the file

Authorized licensed use limited to: Univ of Calif Los Angeles. Downloaded on April 05,2010 at 02:10:39 EDT from IEEE Xplore. Restrictions apply.

indicated in the RFB has been received already. If this is a new file, the receiver creates an entry for the file in its own memory and sends a NACK with all bits set to 1. Otherwise, the receiving node creates a bitmap to appropriately indicate all un-received packets from the last batch. When the sending node receives a NACK, it (re)transmits any packet that was marked as not received or moves on to the next batch if all packets were received. This reliability may be in addition to the per-packet MAC layer retransmission and reliability. We have evaluated the CNF link layer without the additional MAC layer per packet reliability. IV. SIMULATION RESULTS 1500

~ 1000 8

~

.: -;it soo Q

i

f

!

I

!i ! I I

I

=+-== T 3

~

---J

-r-

200

~CNF

400

t--'rCP

800

1000

1200

1400

1600

1800

Dela)· (seconds)

IjI

J

----f-. I

I

600

Figure 5: CDF of file transfer delay with TCP

I

J

I

I

....-- __-a ,....-----~.

.a-.

~-

678

10

11

O&red Load (Mltps)

Figure 4: Perfonnance comparison ofUDP with CNF LL against TCP.

We present the performance evaluation of the CNF link layer in an NS2 simulation of a wireless multi-hop network of 49 nodes placed in a uniform 7x7 grid. Adjacent nodes in the grid are 200m apart, the transmission range is 250m and the carrier sensing range is 550m. The channel is implemented as a two-ray ground path loss model and the MAC layer data rate is fixed at 11 Mbps. Each node in the network transmits a 10MB file to a random destination at the rate of A per hour, where A is a Poisson variable. We define offered load (p) as

The results presented in Figure 4 show that CNF achieves 71 % higher network capacity compared to TCP (10.6Mbps vs. 6.2 Mbps). Next we study the file transfer delay and plot CDF of the average delay at various offered loads with CNF and TCP in Figure 5 and Figure 6. We see that at offered load of I file/hr (5.28 Mbps), 60% of the files incur less than 200 seconds delay for both CNF and TCP. However, the next 40% incur another 350 seconds delay in CNF and 1200 seconds with TCP. The flows that traverse larger number of hops or through bottleneck links are flow controlled in TCP hence the increased delay. This TCP unfairness has been studied in [1 ].

p = A * file _ size *8 * number _ of _ sources * average _ hop _length / 3600 We vary A to change the offered load and note the average file delay. We define the capacity of the network as the offered load for which the average file delay remains below 500s. We set up the CNF network with UDP at the transport layer, IP at the routing layer, CNF link layer and IEEE 802.11 at the MAC layer. We compare this with TCP over normal network and link layers. To allow the network to stabilize, we wait for the first 450 files to enter the network before we start measurements. We measure the average delays incurred by the next 550 files as they enter and exit the network. We observe that on an average the hop length from file source to destination is 4.63.

0.5 file/hr (2.64l\Ibps) 1 file/hr (5.28 l\Ibps) 1.5 file/hr (7.93l\.lbps) 2 file/hr(10.57l\.lbps)

200

400

600

800

Dela~'

(seconds)

1000

1200

1400

1600

Figure 6: CDF of file transfer delay when using CNF LL and CNF transport

We have presented in Figure 7 results from prior work [10] that shows the composite performance of CNF transport protocol used with CNF link layer protocol in comparison with TCP over IP routing and link protocols. Figure 7(a) shows that even in a purely wired network, CNF transport and link layers can sustain a much higher throughput with lower delays. Figure 7(b) shows the results when one wireless link is added to the same route. Here TCP incurs 100s delays when the offered load is 5Mbps while CNF can sustain a 20Mbps load with the same delay

Authorized licensed use limited to: Univ of Calif Los Angeles. Downloaded on April 05,2010 at 02:10:39 EDT from IEEE Xplore. Restrictions apply.

1800

based upon ETX [12], ETT [13], LQI [14], error rate or a combination of several cost metrics. We have used expected transmission time (ETT) for our initial study. We also include the minimum available storage space along the route in both the long and short term routing tables. We have used OLSR as the baseline routing protocol to implement our routing metric. OLSR uses topology control (TC) and Hello messages to disseminate connectivity information throughout the network. We will now describe the routing table building algorithm using two hop neighbor

constraint. 500 450 400

u- 35O

•

~

i;' 300

"i)

~ 250 .

.! (IJ

g200

.!!

u::

150 100 50 .~:S!M~.....-""

--e-CNF delay --'-CNF delay 1% noise F-····,,·······:················:···'-+-CNF delay 5% noise .......- CNF delay 10% noise ......-rcp delay --.-rcp delay 1% noise ···... ·············;·················1 -+- rcp delay 5% noise

tables received in the TC messages. At node x, let N(2) k be the set of two hop neighbors n(2) ki that appear in the

TC k received from node k. Let n (1) kj be the one hop

.......-rcp delay 10% noise

00

20

10

30

40

50

60

70

Offered traffic load (Mbps)

neighbor that are advertised as the nexthop to reach n(2) ki

ETT(k, n(2) ki) is the short term link cost in terms ofETT

7

to reach k from 6

minimum

isl-··.··.···.··-:··· .. ·· ·····.···············:······· .!!!,

k Jr

.

~ CD

'lJ

i

4

(IJ

c: as

~

~

31-··························;·········,······

LL

2 C11111i1

~o

100

iii

150

iii

iii

200 250 300 Offered traffic load (Mbps)

.

350

400

450

Figure 7: CNF and TCP file transfer delays with varying number of wireless links in the route (8) (a) no wireless links, (b) one wireless link.

We have seen benefits of using CNF link and transport layer and we believe that CNF routing layer would improve these results further. We will present the preliminary design of this routing philosophy in the next section. V. CNF ROUTING PROTOCOL In this section we describe the design of a dynamic CNF routing protocol which is intended to improve the performance even further relative to static routing considered in Section IV. We also incorporate the storage capacity available in CNF routers into our routing algorithm design so that content can be temporarily stored in the network until the end-to-end path quality is considered acceptable. The design is also robust to link quality variations and is opportunistic in utilizing short term improvements in the end-to-end path quality. We propose a routing metric design in which each router maintains two routing tables: a long-term routing table that contains the average link costs over long time duration and a short-term table that maintains link costs averaged over shorter time duration. The link cost may be

~

n(l) kj

n(l) Iq" and Space(k, n(2) ki) is the

storage ~

space

along

the

route

n(2) ki' Algorithm 1 illustrates the short

term routing table building process using this information. Similarly we build the long term table by taking a moving average of link costs from several TC messages. The long term table consists of several alternate paths. We currently keep the five best paths in the long term table where the goodness of the path is determined by their long term costs. We resolve route to a destination by looking up the long term cost of the route obtained from the short term table. We map the route in the two dimensional decision graph shown in Figure 8. This decision graph classifies routes in three regions based upon their long term and short term costs. The stable region contains routes in which there is little deviation from the long term cost. The store region is comprised of routes with slower short term links and the forward and store region that have good short term links but slow long term links. As the names suggest, if a route in the store region is selected, the data needs to be stored until the route quality improves. This implies the routes in the store region must have sufficient storage space. Similarly in routes that fall in the forward and store region, it is desirable for the Algorithm 1: Algorithm to build the short term routing table

for

':;'n(2 lkl

~V (2)k

do

~st1llatioll:= n! 2)/"-1

Cost:= jll1' for vq E .V (1).1' do if Cost £TT(f. 1/(1 Lrq) + £TT(n(1 ).1'q' k) + E:'TT I: k_11 (2 )kl) then Cost:= £TT(.f. nil ).rq) + ETT('11{ 1 )xq. k) + ETT(k. n(2)kJ) N~xt Hop:= 11 ( 1).1'q Storage:= S'rH1Cf'\l'. n(21I\1', = IBin Spacfi .... :1. '7 nod~s . . in th~ rout~ frotu .1' to 1} i: ~ 11.~1 end if end for end for

downstream router to have enough storage space. When a route is in the stable region, storage might not come in play

Authorized licensed use limited to: Univ of Calif Los Angeles. Downloaded on April 05,2010 at 02:10:39 EDT from IEEE Xplore. Restrictions apply.

but the path selection protocol should favor a route with more storage when comparing two routes in the stable region with equivalent long term costs. ~ UJ boO

C

.Q

'0 "QJ

"Eo

boO

C

"V; ~

-

Store regi on (long term En « short term En)

E

2

1

11111111~

(Iongterm En == short term En) Stable region Forward and Store reqi on (long term En» short term En)

~ o Q.I

o

Decreasi ng order of short term En

Figure 8: Routing Metric Design

By selecting a path from the forward and store region, the routing protocol opportunistically utilizes better short term paths. By choosing to store the data and wait for the better link to become available, the routing protocol avoids using links that are poor in the short term. While waiting for a link to improve, the router may either serve another route or defer the medium access to other routers that have better links. This scheme has the promise to improve the overall system performance while preserving individual performance objectives. At the time of writing this paper, we are in the process of implementing this protocol in the ORBIT testbed as well as in the NS2 simulator. VI. CONCLUSION The CNF project is currently at an intermediate stage of development. We have completed initial design and evaluation and we are working on routing protocol optimization and proof-of-concept prototyping on the ORBIT testbed at WINLAB [15]. Our long term goal is to move toward real world deployment of the CNF network using the outdoor ORBIT deployment covering the Rutgers campus with open Wi-Fi access points and WiMax/cellular base stations. It is also noted here that although CNF was designed as a clean-slate architecture, we are also in the process of evaluating strategies such as network virtualization [16] [17] that would enable evolutionary CNF deployment and coexistence with existing services such as TCP/IP and VOIP.

Communication Systems Software and Middleware COMSWARE, Bangalore, India, 2007. [4] "Networking Technology and Systems: Future Internet Design (FIND)," 07-507, 2007. [5] "Global Environment for Networking Innovations (GENI)," 06-601, 2006. [6] "FP7 Information and Communication Technologies:Pervasive and Trusted Network and Service Infrastructures," FP7-ICT-2007-2, 2007. [7] M Lemke, "Position Statement: The European FIRE Initiative," , Washington DC, 2007. [8] Roy Yates, Dipankar Raychaudhuri, Jim Kurose Sanjoy Paul, "The Cache-ADd-Forward Network Architecture for Efficient Mobile content delivery services in the future internet," in First lTU- T Kaleidoscope Academic Conference on Innovations in NGN: Future Network and Services, 2008, pp. 367-374. [9] Kevin Fall, "A delay-tolerant network architecture for challenged intemets," SIGCOMM '03: Proceedings of the 2003 conference on Applications, technologies, architectures, and protocols for computer communications, Karlsruhe, Germany, 2003. [10] Yanyong Zhang, and Dipankar Raychaudhuri Hongbo Liu, "Performance Evaluation of the Cache-and-Forward (CNF) Network for Mobile Content Delivery Services,"Under Submission, 2008. [11] Yanyong Zhang, Dipankar Raychaudhuri, Sanjoy Paul, Hongbo Liu Lijun Dong, "Content Retrieval in a Cache-and-Forward Network," WINLAB technical report, New Brunswick, New Jersey, 2008. [12] Daniel Aguayo, John Bicket, Robert Morris Douglas S. 1. De Couto, "A high-throughput path metric for multi-hop wireless routing," in MobiCom '03: Proceedings ofthe 9th annual international conference on Mobile computing and networking, San Diego, 2003. [13] R., Padhye, 1., and Zill, B Draves, "Routing in multi-radio, multi-hop wireless mesh networks," in In Proceedings ofthe 10th Annual international Conference on Mobile Computing and Networking, Philadelphia,USA, 2004. [14] Erol Gelenbe and Ricardo Lent, "Link quality-aware routing," PEWASUN '04: Proceedings of the 1st ACM international workshop on Performance evaluation of wireless ad hoc, sensor, and ubiquitous networks, Venezia, 2004. [15] 1. Seskar, M. Ott, S. Ganu, K. Ramachandran, H. Kremo, R. Siracusa, H. Liu and M. Singh D. Raychaudhuri, "Overview of the ORBIT Radio Grid Testbed for Evaluation of Next-Generation Wireless Network Protocols," Proceedings of the IEEE Wireless Communications and Networking Conference, 2005. [16] Kumar Reddy Victor Moreno, "Network virtualization," Cisco Press, Indianapolis, USA, 2006. [17] Rui Zhang-Shen, Sampath Rangarajan, and Jennifer Rexford Yaping Zhu, "Cabernet: Connectivity architecture for better network services," Proceedings of the Workshop on Rearchitecting the Internet, 2008.

REFERENCE [1] A. DeSimone, Mooi Choo Chuah, and On-Ching Vue, "Throughput performance of transport-layer protocols over wireless LANs," Global Telecommunications Conference, 1993, including a Communications Theory Mini-Conference, Houston, Texas, 1993. [2] A. V. Bakre and B. R. Badrinath., "1-TCP: indirect TCP for mobile hosts," Proceedings - International Conference on Distributed Computing Systems, 1995. [3] S. Paul, S. Raychaudhuri, D Gopal, "Leveraging MAC-layer information for single-hop wireless transport in the Cache and Forward Architecture of the Future Internet," 2nd International Conference on

Authorized licensed use limited to: Univ of Calif Los Angeles. Downloaded on April 05,2010 at 02:10:39 EDT from IEEE Xplore. Restrictions apply.