Outline Delay-Tolerant Networking

Transcription

1 Outline Delay-Tolerant Networking Jiang Leo Li Dept. of Sys. & Comp. Sci. Howard University Why the Internet Architecture is not a one-size-fit-all solution DTN Architecture Overview Some Projects Recent Research Oct. 18 th, GWU Partialy adapted from slides by Kevin Fall RFC1149 : A Challenged Internet encapsulation of IP datagrams in avian carriers (i.e. birds, esp carrier pigeons) Delivery of datagram: Printed on scroll of paper in hexadecimal Paper affixed to AC by duct tape On receipt, process is reversed, paper is scanned in via OCR Implementation of RFC1149 CPIP: Carrier Pigeon Internet Protocol See Ping Results Script started on Sat Apr 28 11:24: vegard@gyversalen:~$ /sbin/ifconfig tun0 tun0 Link encap:point-to-point Protocol inet addr: P-t-P: Mask: UP POINTOPOINT RUNNING NOARP MULTICAST MTU:150 Metric:1 RX packets:1 errors:0 dropped:0 overruns:0 frame:0 TX packets:2 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 RX bytes:88 (88.0 b) TX bytes:168 (168.0 b) vegard@gyversalen:~$ ping -i PING ( ): 56 data bytes 64 bytes from : icmp_seq=0 ttl=255 time= ms 64 bytes from : icmp_seq=4 ttl=255 time= ms 64 bytes from : icmp_seq=2 ttl=255 time= ms 64 bytes from : icmp_seq=1 ttl=255 time= ms ping statistics packets transmitted, 4 packets received, 55% packet loss round-trip min/avg/max = / / ms vegard@gyversalen:~$ exit Script done on Sat Apr 28 14:14: About 1.5 hours High loss Unstated Internet Assumptions End-to-end RTT is not terribly large A few seconds at the very most [typ < 500ms] (window-based flow/congestion control works) Some path exists between endpoints Routing usually finds single best existing route [Equal Cost Multipath Protocol is an exception] E2E Reliability using ARQ (Automatic Repeat request) works well True for low loss rates (under 2% or so) Packet switching is the right abstraction Internet/IP makes packet switching interoperable 1

2 Non-Internet-Like Networks Stochastic and periodic mobility Military/tactical networks Mobile routers w/disconnection (e.g. ZebraNet) Spacecraft communications (LEO sats) Buses, mail trucks, delivery trucks, etc. (InfoStations) Exotic links Deep space [Mars: 40 min RTT; episodic connectivity] Underwater [acoustics: low capacity, high error rates & latencies] Sensor networks, mules DTN challenges Intermittent/Scheduled/Opportunistic Links Scheduled transfers can save power and help congestion; scheduling common for esoteric links High Link Error Rates / Low Capacity RF noise, light or acoustic interference, LPI/LPD concerns Very Large Delays Natural prop delay could be seconds to minutes If disconnected, may be (effectively) much longer Different Network Architectures Many specialized networks won t/can t ever run IP What to Do? Some problems surmountable using Internet/IP cover up the link problems using PEPs Mostly used at edges, not so much for transit Performance Enhancing Proxies (PEPs): Do something in the data stream causing endpoint (TCP/IP) systems to not notice there are problems Lots of issues with transparency security, operation with asymmetric routing, etc. Some environments never have an e2e path Consider an approach tolerating disconnection, etc... Delay-Tolerant Networking Architecture Goals Support interoperability across radically heterogeneous networks Acceptable performance in high loss/delay/error/disconnected environments Decent performance for low loss/delay/errors Components Flexible naming scheme with late binding Message overlay abstraction and API Routing and link/contact scheduling w/cos (Class of Service) Per-(overlay)-hop reliability and authentication Naming Support radical heterogeneity using regions: Instance of an internet, not so radical inside a region Common naming and protocol conventions Endpoint Name: ordered name pair {R,L} R: routing region [globally valid] L: region-specific, opaque outside region R Late binding of L permits naming flexibility: L used only in destination region of interest R Could be associative or location-oriented names [URN vs URL] May encompass esoteric routing [e.g. diffusion] Perhaps an Internet-style URI [see RFC2396] To do: make R,L compressible in transit networks Message Overlay Abstraction E2E Async Message Service: Bundles postal-like message delivery over regional transports with coarse-grained CoS [4 classes] Options: return receipt, traceroute -like function, alternative reply-to field, custody transfer Supportable on nearly any type of network Applications send/receive messages Application data units of possibly-large size May require framing above some transport protocols API supports response processing long after request was sent (application re-animation) 2

3 DTN So, is this just ? Naming/ late binding Routing N Flow control N() Multi-app N() optional optional Many similarities to (abstract) service Primary difference involves routing/restart and API depends on an underlying layer s routing: Cannot generally move messages closer to their destinations in a partitioned network In the Internet (SMTP) case, not disconnection-tolerant or efficient for long RTTs due to chattiness security authenticates only user-to-user Security optional Reliable delivery Priority N() Existing DTN Projects InterPlanetary Internet (IPN) ZebraNet Data MULEs SWIM DakNet SNC Project and more InterPlanetary Internet (IPN) DTN is most closely based on IPN but also significantly generalizes it Licklider Transmission Protocol (IRTF draft) designed to provide retransmission-based reliability over links characterized by extremely long message round-trip times (RTTs( RTTs) ) and/or frequent interruptions in connectivity. ZebraNet Collar on zebra 35,000 zebras range widely over the 40,000 sq. km. in central Kenya Data go to base station Flooding Collar exchange data with neighbors History-based Hierarchy level based on past success at transferring data to the base station Data forwarded to those with higher hierarchy levels Mobile Ubiquitous LAN Extensions MULEs collect data from sensors and forward to access points async. No data exchange between MULEs Data MULEs The MULEs three-tier architecture SWIM Shared Wireless Infostation Model Where there is a Whale, there is a Way Whales are tagged When whales meet, stored information is exchanged with certain probability Most whales follow consistent migration and surfacing patterns When whales come close to SWIM stations, information offloaded 3

4 Deployed in remote parts of both India and Cambodia Provides extraordinarily low-cost digital communication DakNet As the MAP-equipped vehicle comes within range of a village WiFi-enabled kiosk, it automatically senses the wireless connection and then uploads and downloads tens of megabytes of data. When a MAP-equipped vehicle comes within range of an Internet access point (the hub), it automatically synchronizes the data from all the rural kiosks, using the Internet. SNC Project Sámi Network Connectivity Project To establish Internet communications for the Sámi population of Reindeer Herders, who live in remote areas, and relocate their base in accordance with a yearly cycle dictated by the natural behavior of reindeer. Relay data between gateways using opportunistic routing through fixed and mobile relays which move back and forth Recent Research Example Routing Problem Mostly routing Reactive Leverage existing mobility Proactive Modify mobility pattern Many open issues Example Graph Abstraction Routing on Dynamic Graphs DTN routing takes place on a time-varying topology Links come and go, sometimes predictably Use any/all links that can possibly help Scheduled, Predicted, or Unscheduled Links May be direction specific [e.g. ISP dialup] May learn from history to predict schedule Messages fragmented based on dynamics Proactive fragmentation: optimize contact volume Reactive fragmentation: resume where you failed Both are important for high utilization of precious link resources 4

5 The DTN Routing Problem Inputs: topology (multi)graph, vertex buffer limits, contact set, message demand matrix (w/priorities) An edge is a possible opportunity to communicate: One-way: (S, D, c(t), d(t)) (S, D): source/destination ordered pair of contact c(t): capacity (rate); d(t): delay A Contact is when c(t) > 0 for some period [t i, t i+1 ] Vertices have buffer limits; edges in graph if ever in any contact, multigraph for multiple physical connections Problem: optimize some metric of delivery on this structure Sub-question: what metric to optimize? FC MED ED EDLQ EDAQ LP Abbr. Knowledge vs Performance Name First Contact Minimum Expected Delay Earliest Delivery Earliest Delivery with Local Queue Earliest Delivery with All Queue Linear Program Use any available contact Dijkstra with time-invariant invariant edge costs based on average edge waiting time Modified Dijkstra with time- varying cost function based on waiting time ED with cost function incorporating local queuing ED with cost function Contacts and incorporating queuing information Queueing at all nodes and using reservations - Description S. Jain (UW): SIGCOMM 2004 None Oracle Used Contacts Summary Contacts Contacts Contacts, Queueing and Traffic Knowledge vs Performance (cont d) Routing for Opportunistic Connectivity Predictable connectivity easier to deal with Known c(t) & d(t) in (S, D, c(t), d(t)) What if with poor predictability? c(t) ) & d(t) ) have to be estimated somehow Direct contact Flooding Single-copy Limited flooding Performance Metrics Delivery ratio (throughput) Percentage of original data reaching the dest. Reliable transfer vs. loss tolerant Delay The time required to achieve certain delivery ratio Lower delay => higher delivery ratio (S. Jain, SIGCOMM 2004) Direct Contact Hand the data over only when the source meets with the destination Most economical Will source meet with the destination? 5

6 Flooding Data spread whenever peers meet Best delivery ratio & delay with infinite buffer & bandwidth What if with finite buffer & bandwidth? Waste resources Single-Copy After forwarding, data is removed from the sender Intermediate nodes may exchange data Or may not, e.g. Data MULEs, DakNet Very economical Probably with poor delivery ratio & delay But could excel if given Oracle Limited Flooding Data only forwarded to some encountered nodes Some: how many? which? Deterministic Randomized Spray & Wait The source initially starts with L copies of a message Any node A that has n > 1 copies, when encountering B, gives half to B, and keeps another half Delay proven to be minimum if all nodes move I.I.D. Open issues Real-world objects don t t move I.I.D Can we do sth other than half and half? History (Utility) Based Estimate the likelihood (utility) of a node meeting with the destination Data only forwarded to nodes with higher utility values Many proposed schemes Differ on how to estimate utility Heavily dependent on mobility models Erasure-Coding Based Erasure coding Message sized m Replication factor r Generate data sized m r Message can be recovered given (1+e)m Two-hop Source => relay Relay => destination Forward to first encountered k r relays Each carrying m/k Good as long as (k + e) relays see the destination 6

7 Randomized Flooding When in contact, forward message with probability p p =? 1 1/n (n: # encountered nodes) (1/n, 1) n =? Network Coding Based (1) Packet => vector Linear combinations of packets are sent out Destinations solve equations to derive original packets Network Coding Based (2) Node i: (e i, x i ) e i : i-th unit vector x i : elements in the finite field F k 2 (e.g. k = 8) Decoding matrix G v Each row Encoding vector g: a linear combination of e i Information vector y: a linear combination of x i Has all vectors received Innovative packet Its vector increases the rank of G v Network Coding Based (3) Derive x i from G v a1e1 + a2e2 + + anen M z1e1 + z2e2 + L+ znen For original packets a1x1 + a2x2 + L+ anxn e1 n M M z x + z x + L+ z nxn en L 1 x M x n max (1, floor(d)) vectors are generated and broadcast One more is generate w.p.. d floor (d) if d > 1 Relay Floor(d) ) vector are generated and broadcast at the receipt of an innovative packet A further vector is generated w.p.. d floor (d) Multiple packets originated by a source Generations Proactive Routing Message ferrying W. GIT Main goals: Throughput Delay Two steps Minimize the delay to visit all nodes Augment the route to provide enough throughput (enough time around a node to communicate) Tradeoff, Tradeoff, Tradeoff Resource Storage Energy CPU power Bandwidth etc Outcome Delay Throughput 7

8 Other Stuff Mobility models Zebra = human Power law Small world Critical to history-based schemes Congestion control Open-loop Coupled with routing Security Reference Sites DTN Research group SIGCOMM 2005 DTN workshop wdtn.html K. Fall (who proposed the name of DTN) W. Zhao S. Jain and references within 8