Why mesh? Why ad-hoc?

Transcription

1 Ad-hoc Networking

2 Why mesh? Why ad-hoc? Requires no central authority (no access points); extreme flexibility Self-organizing into local micronetworks based on the population of users rather than the availability of pre-deployed infrastructure Good for network applications driven by personal proximity rules

3 What is wrong with popular commercial solutions? First of all, they don t really work: Bluetooth is mostly for building small personal hubs: arcane pairing rules and no flexible multi-hoping make true ad-hoc impossible WiFi is essentially AP-oriented; as an ad-hoc solution, it is too costly, too cumbersome, power hungry, and unsuitable for most of the applications we have in mind ZigBee has been mostly used in one-hop networks; it doesn t scale very well to true adhoc

4 What is wrong with popular commercial solutions? Second of all, they are isolated networking solutions (design layers) trying to provide standards and cater to unknown applications (that somebody else must build) Complete and rigid application-independent networking stack cannot be effective and small at the same time Being devised by committees and consortia, they try to accommodate too much and tend to be large and messy

5 Ad-hoc networks built around the popular commercial solutions are all based on point-to-point forwarding i.e., setting up hop-by-hop paths in the network Unfortunately, there are no such things as paths in wireless one can only pretend

6 How do they work? Here is a network

7 How do they work? Suppose that some two nodes, call them A and B, want to exchange packets B A

8 How do they work? The network must identify a path, i.e., an exact sequence of intermediate nodes to forward those packets B A

9 How do they work? This involves lots of distributed negotiations, evaluations, and bookkeeping B A

10 Details depend on the scheme Reactive: only look for a path when a specific connection is required Proactive: constantly negotiate paths for all possible (or anticipated) connections to be ready in advance These two generic approaches trade complexity (overhead) for responsiveness

11 Once the path has been established B A

12 Once the path has been established B A

13 Once the path has been established the packet will be addressed on each hop to the single, specific, pre-determined, next node B A

14 Why is this bad? The procedure for discovering the path(s) is tricky and complex The nodes must remember some descriptions of all active (pro-active?) paths passing through them If one node on a path fails, the path becomes broken (its fixing may be as complex as finding a new path) Mind you: we are wireless (possibly mobile); nodes come and go

15 This approach is a legacy of wired networking People like to think in terms of simple connections, like wires

16 This approach is a legacy of wired networking and, if the links are in fact wires, and the nodes don t move, that idea works quite well (see the stationary Internet) B A

17 But there are no wires in the wireless world! B A

18 But there are no wires in the wireless world! You never send your packet to the precisely one next hop node (you only think you do!) B A

19 Also, the illusory links are not as reliable as wires Which path is better? The one with fewer hops appears more attractive, but longer hops are less reliable B A

20 Then, as we have already noticed, the nodes are not nailed down and may disappear (or fail for many legitimate reasons) B A

21 Broken paths must be detected and recovered from B A

22 Broken paths must be detected and recovered from which takes effort and time, possibly traded for space and bandwidth (if you prefer to be proactive) B A

23 Broken paths must be detected and recovered from Note that the new best path may be drastically different from the previous one, e.g., B A

24 The problem is inherent and laden with tradeoffs If you are proactive, your objective is to maintain up to date information about all or anticipated possible paths If you are reactive, you should expect longish hiccups while your paths are being discovered and/or recovered Wisdom requires memory in proportion to the number of paths the node may be involved in (its amount scales more than linearly to the total number of nodes) Timely (up-to-date) wisdom requires traffic, which wastes bandwidth and power

25 Such schemes do not fit the poor reliability model of ad-hoc systems P-P paths are contrived and brittle: you either have a (full) path, or have no path at all (note that the remnants of a broken path may be completely useless) Nodes are inherently unreliable. Don t whine about it! This is OK! This is their charm! Just learn to avoid contrived and fragile solutions, i.e., ones whose global integrity depends on the reliability of a single component!

26 The wireless medium is broadcast

27 The wireless medium is broadcast so the point-to-point links are purely imaginary B A

28 The wireless medium is broadcast so when a node sends something (intended to the single next hop neighbor), all its neighbors will hear that B A

29 The P-P schemes view this as a nuisance that must be fought through various collision avoidance techniques that isolate uninterested neighbors from the one supposedly linked to the sender Those techniques only work (somewhat) if data packets are long; they are useless when sending small amounts of data and, of course, they complicate the messy scheme even more

30 The notorious 4-way handshake A B C D A RTS B CTS E DATA ACK What if the packet you have to send is comparable in size to RTS/CTS/ACK? Then, we have the exposed terminal problem Then, we have the RTS chain problem

31 Here s a scheme that does away with the superstition: TARP The broadcast nature of the medium is a feature, not a flaw! No wires! Deal with it! Instead of wasting time, memory, and bandwidth on discovering and recovering the illusory paths, you should be sending the damn packets! Wisdom will emerge as the regular, useful, packets propagate and are overheard by all the nodes than can rightfully hear them No single item of that wisdom is critical (in the sense that the fate of an elaborate connection would entirely depend upon it)

32 The simple idea: I am A and I have a packet addressed to B; never heard of B before; what to do? A P-P scheme would say: hey, let s send some queries around and wait until everybody learns exactly how to go TARP says: let s send the packet right away I do have to send it eventually, right? no matter where I think it goes, all my neighbors will hear it anyway, right? so why bother with the queries?

33 This is a difference in paradigm; the forwarder s dilemma:? P-P Where should I forward the packet? How can I learn the identity of the next node on the path? How do I make sure to know that identity at all times? TARP Should I transmit (broadcast) the packet? Will I help when I do that? Won t my assistance be redundant?

34 TARP is extremely proactive in the cheapest, most natural sense:? P-P TARP I cannot forward unless I know exactly how and when: I must explicitly receive the packet first Then I must know where to send it next I cannot stop forwarding unless I am sure my help is not needed: Nobody tells me what to receive: I receive what I hear I forward packets by default Unless I have learned that I am not helpful

35 In simple words: P-P is obsessive about learning how to help It has to be obsessive, because it cannot forward at all unless it has the knowledge The knowledge is brittle and elaborate (it relates to a volatile path within the mesh) The knowledge must be complete to be of value

36 In simple words: TARP is not so obsessive about learning when not to help It doesn t have to be obsessive, because the lack of knowledge is not as harmful Partial knowledge is meaningful! A better informed node will use less bandwidth which means that any node can help, according to its means

37 In its vanilla version, this approach amounts to flooding A broadcasts its packet If the node receiving the packet is B, the packet has made it Otherwise, the node re-broadcasts the packet (to all its neighbors) Well, this one is scary indeed: it never stops and does flood the network. Here are two easy fixes: Do not re-broadcast a packet that you have already handled a short while ago Do not re-broadcast stray packets (ones that have made too many hops)

38 TARP does connote with flooding (boo!), but don t let them fool you! There is no way to get something for nothing! All those complicated P-P schemes need flooding at least for path discovery! When TARP knows nothing, it starts by naive flooding; when they know nothing, they are down to (necessarily naive) flooding, too; so we are even there But we can do much better than that!

39 TARP is driven by a chain of rules Received packet rule 1 ignore don t know Am I the recipient? Yes No rule 2 don t know ignore rule N ignore Receive don t know Rebroadcast Ignore

40 TARP is driven by a chain of rules Received packet seen already? rule 1 don t know ignore Am I the recipient? Yes No too many hops? ignore rule 2 don t know ignore rule N Receive don t know other, smarter rules Rebroadcast Ignore

41 TARP is driven by a chain of rules Received packet seen already? rule 1 don t know ignore Am I the recipient? Yes No too many hops? ignore rule 2 don t know ignore rule N Receive don t know their role is to make sure that the packet is only rebroadcast by those nodes that can actually (efficiently, constructively) Rebroadcast help Ignore

42 One of the essential rules: SPD A K h B h AB B h BA h A K has been seeing some packets sent by A and B. It keeps track of: the smallest recently noted number of hops from A (h A ) the smallest recently noted number of hops from B (h B ) When B receives a packet from A, it notes the total number of hops h AB made by it. This number will be conveyed towards A in the header of a next packet going in the opposite direction, i.e., from B to A. And, of course, it works the same way for A receiving a packet from B.

43 One of the essential rules: SPD A h BA K h A h B h AB B h, h BA Suppose K receives a packet sent by A and going to B. K sees that the packet has made h hops so far. The rule has to decide between ignore and don t know. K compares h + h B to h BA. Note that if h + h B > h BA, the node has grounds to believe that there are better forwarders than itself (so the rule may say ignore). A dampening parameter (slack) is usually applied; the rule says ignore if h + h B > h BA + slack. The role of slack is to provide for controllable intentional redundancy.

44 All rules of TARP follow a certain important philosophy They are driven by cached information collected and stored by the node If the node has no room to store all the information, the rule may not know what to do, so it says don t know This means that the packet will not be ignored; it will be rebroadcast! This way we smoothly trade the node s footprint for the redundancy of routes (try this with a P-P scheme )

45 The SPD (Suboptimal Path Discard) rule makes sure that: An un-informed node will not ignore the packet on its account (the node will rebroadcast, thus trying to help) A node that has seen some traffic involving the A-B pair, will tend to help only if its help matters With time, the population of helpers will tend to converge to a stripe of nodes along the best path (its width depends on slack) This will happen without an explicit discovery or recovery phase, while the network is doing its actual job of getting packets delivered

46 No hiccups, no critical nodes A B

47 No hiccups, no critical nodes A B eliminates duplicates primary helpers slack = 1 secondary helpers (also forwarding)

48 No hiccups, no critical nodes A X B Suppose one of the primary helpers disappears

49 No hiccups, no critical nodes A B what was previously removed as a duplicate, has no competition now The secondary helpers take over (without even realizing that)

50 No hiccups, no critical nodes A B No disruption, no need for desperate recovery

51 There is a bit more e.g., more rules and more tricks; they all follow the principles of noncontrivance and auto-scalability TARP is part of a complete, powerful platform for rapid development of networked applications (praxes) The platform has been designed with the premise of self-scalable, ad-hoc oriented collaboration of small and generally unreliable nodes

52 Owing to its open-ended, ruledriven nature... TARP is a meta-protocol: its final shape is determined in the context of the specific application Applications can easily add their own rules, if required, and/or remove some of the standard rules This is in blatant contrast to present commercial solutions, which strive to provide standards of complete network functionality: one size does not fit all!