Ad-hoc Networking Why mesh? Why ad-hoc? Requires no central - - PowerPoint PPT Presentation
Ad-hoc Networking Why mesh? Why ad-hoc? Requires no central authority (no access points); extreme flexibility Self-organizing into local micro- networks based on the population of users rather than the availability of pre-deployed
Requires no central authority (no access points); extreme flexibility Self-organizing into local micro- networks based on the population of users rather than the availability of pre-deployed infrastructure Good for network applications driven by personal proximity rules
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 ad- hoc
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
… 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
Here is a network
Suppose that some two nodes, call them A and B, want to exchange packets
A B
The network must identify a path, i.e., an exact sequence of intermediate nodes to forward those packets
A B
This involves lots of distributed negotiations, evaluations, and bookkeeping
A B
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
A B
A B
… the packet will be addressed on each hop to the single, specific, pre-determined, next node
A B
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
People like to think in terms of simple connections, like wires …
… and, if the links are in fact wires, and the nodes don’t move, that idea works quite well (see the stationary Internet)
A B
A B
A B
You never send your packet to the precisely one next hop node (you
A B
Which path is better? The one with fewer hops appears more attractive, but longer hops are less reliable
… and may disappear (or fail for many legitimate reasons)
B A
B A
… which takes effort and time, possibly traded for space and bandwidth (if you prefer to be pro- active)
B A
Note that the new “best” path may be drastically different from the previous one, e.g.,
B A
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
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!
… so the point-to-point links are purely imaginary …
B A
B
… so when a node sends something (intended to the single next hop neighbor), all its neighbors will hear that
A
… 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
A B C D E A B RTS CTS 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
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)
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?
Where should I forward the packet? How can I learn the identity
How do I make sure to know that identity at all times?
Should I transmit (broadcast) the packet? Will I help when I do that? Won’t my assistance be redundant?
I must explicitly receive the packet first Then I must know where to send it next
I cannot forward unless I know exactly how and when: 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
I cannot stop forwarding unless I am sure my help is not needed:
It has to be obsessive, because it cannot forward at all unless it has the knowledge P-P is obsessive about learning how to help The knowledge is brittle and elaborate (it relates to a volatile path within the mesh) The knowledge must be complete to be of value
It doesn’t have to be obsessive, because the lack of knowledge is not as harmful TARP is not so obsessive about learning when not to help Partial knowledge is meaningful! A better informed node will use less bandwidth … … which means that any node can help, according to its means
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)
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!
Am I the recipient ? Receive
Yes
rule 1 rule 2 rule N Rebroadcast
No
Received packet Ignore ignore don’t know don’t know don’t know ignore ignore
Am I the recipient ? Receive
Yes
rule 1 rule 2 rule N Rebroadcast
No
Received packet Ignore ignore don’t know don’t know don’t know seen already? too many hops?
smarter rules ignore ignore
Am I the recipient ? Receive
Yes
rule 1 rule 2 rule N Rebroadcast
No
Received packet Ignore ignore don’t know don’t know don’t know seen already? too many hops? … their role is to make sure that the packet is
(efficiently, constructively) help ignore ignore
A B K
K has been seeing some packets sent by A and B. It keeps track of: the smallest recently noted number of hops from A (hA) the smallest recently noted number of hops from B (hB)
hA hB
When B receives a packet from A, it notes the total number of hops hAB 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.
hAB hBA
And, of course, it works the same way for A receiving a packet from B.
A B K
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.
hA hB hAB hBA h, hBA
K compares h + hB to hBA. Note that if h + hB > hBA, 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 + hB > hBA + slack. The role of slack is to provide for controllable intentional redundancy.
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 )
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
its actual job of getting packets delivered
A B
A B
slack = 1 primary helpers secondary helpers (also forwarding) eliminates duplicates
A B
Suppose one of the primary helpers disappears
A B
The secondary helpers take over (without even realizing that) what was previously removed as a duplicate, has no competition now
A B
No disruption, no need for desperate recovery
… e.g., more rules and more tricks; they all follow the principles of non- contrivance and auto-scalability The platform has been designed with the premise of self-scalable, ad-hoc
generally unreliable nodes TARP is part of a complete, powerful platform for rapid development of networked applications (praxes)
... 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
This is in blatant contrast to present commercial solutions, which strive to provide standards of complete network functionality: one size does not fit all!