Erasure-Coding Based Routing for Opportunistic Networks: Difference between revisions
No edit summary |
No edit summary |
||
| Line 1: | Line 1: | ||
==Introduction== |
==Introduction== |
||
Most current approaches for routing in DTN are based on sending multiple identical copies of packages over different paths. There is always a tradeoff between overhead and delay. The flooding algorithm, for example, has the best delay, but the worst overhead. The direct algorithm on the other side has the worst delay but the best overhead. We present an erasure coding based algorithm, that achieves a better worst-case delay performance than existing approaches |
Most current approaches for routing in DTN are based on sending multiple identical copies of packages over different paths. There is always a tradeoff between overhead and delay. The flooding algorithm, for example, has the best delay, but the worst overhead. The direct algorithm on the other side has the worst delay but the best overhead. We present an erasure coding based algorithm, that achieves a better worst-case delay performance than existing approaches with a fixed overhead. |
||
==Erasure Codes== |
==Erasure Codes== |
||
| Line 6: | Line 6: | ||
==Erasure coding based routing(ec)== |
==Erasure coding based routing(ec)== |
||
The |
The algorithm we present is a enhancement of the simple replication algorithm (srep). Is srep with replication factor <math>r</math>, the source sends <math>r</math> identical copies of the message over <math>r</math> contacts. This contacts may only send directly to the destination. |
||
In the erasure |
In the erasure coding based algorithm (ec) the sender generates a large number of codes blocks and distributes them over <math>k*r</math> relays, for some constant <math>k</math>. This uses <math>k</math> times more relays than srep, but each relay only carries <math>1/k</math> times data. So ec uses the same number of bytes as srep. |
||
Because <math>1/r</math> code blocks are needed to reconstruct the message, <math>k</math> relays have to deliver their data successfully. |
Because <math>1/r</math> code blocks are needed to reconstruct the message, <math>k</math> relays have to deliver their data successfully. |
||
For <math>k=1</math> ec is the same as srep. |
For <math>k=1</math> ec is the same as srep. |
||
==Benefits== |
==Benefits== |
||
In srep <math>r</math> relays are used and one has to |
In srep <math>r</math> relays are used and one has to succeed. In ec <math>k*r</math> relays are used but <math>k</math> relays must succeed to reconstruct the message. If the number of low delay relays is larger than <math>k</math> ec will deliver the message with a lower delay than srep.If <math>k</math> is large, the delay distribution converges to a constant. Therefore ec has almost a constant delay. |
||
==Material== |
==Material== |
||
Latest revision as of 09:01, 20 October 2006
Introduction
Most current approaches for routing in DTN are based on sending multiple identical copies of packages over different paths. There is always a tradeoff between overhead and delay. The flooding algorithm, for example, has the best delay, but the worst overhead. The direct algorithm on the other side has the worst delay but the best overhead. We present an erasure coding based algorithm, that achieves a better worst-case delay performance than existing approaches with a fixed overhead.
Erasure Codes
Erasure Codes convert a message into a large number of code blocks so, that any sufficient large subset of this blocks can be used to reconstruct the message. In more detail, if an erasure code has a message of size Failed to parse (SVG (MathML can be enabled via browser plugin): Invalid response ("Math extension cannot connect to Restbase.") from server "https://en.wikipedia.org/api/rest_v1/":): {\displaystyle M} and a replication factor Failed to parse (SVG (MathML can be enabled via browser plugin): Invalid response ("Math extension cannot connect to Restbase.") from server "https://en.wikipedia.org/api/rest_v1/":): {\displaystyle r} as input, it produces Failed to parse (SVG (MathML can be enabled via browser plugin): Invalid response ("Math extension cannot connect to Restbase.") from server "https://en.wikipedia.org/api/rest_v1/":): {\displaystyle M*r/b} equal sized code blocks of size Failed to parse (SVG (MathML can be enabled via browser plugin): Invalid response ("Math extension cannot connect to Restbase.") from server "https://en.wikipedia.org/api/rest_v1/":): {\displaystyle b} . Any code blocks can be used to reconstruct the message. So only Failed to parse (SVG (MathML can be enabled via browser plugin): Invalid response ("Math extension cannot connect to Restbase.") from server "https://en.wikipedia.org/api/rest_v1/":): {\displaystyle 1/r} code blocks are needed.
Erasure coding based routing(ec)
The algorithm we present is a enhancement of the simple replication algorithm (srep). Is srep with replication factor Failed to parse (SVG (MathML can be enabled via browser plugin): Invalid response ("Math extension cannot connect to Restbase.") from server "https://en.wikipedia.org/api/rest_v1/":): {\displaystyle r} , the source sends Failed to parse (SVG (MathML can be enabled via browser plugin): Invalid response ("Math extension cannot connect to Restbase.") from server "https://en.wikipedia.org/api/rest_v1/":): {\displaystyle r} identical copies of the message over Failed to parse (SVG (MathML can be enabled via browser plugin): Invalid response ("Math extension cannot connect to Restbase.") from server "https://en.wikipedia.org/api/rest_v1/":): {\displaystyle r} contacts. This contacts may only send directly to the destination. In the erasure coding based algorithm (ec) the sender generates a large number of codes blocks and distributes them over Failed to parse (SVG (MathML can be enabled via browser plugin): Invalid response ("Math extension cannot connect to Restbase.") from server "https://en.wikipedia.org/api/rest_v1/":): {\displaystyle k*r} relays, for some constant Failed to parse (SVG (MathML can be enabled via browser plugin): Invalid response ("Math extension cannot connect to Restbase.") from server "https://en.wikipedia.org/api/rest_v1/":): {\displaystyle k} . This uses Failed to parse (SVG (MathML can be enabled via browser plugin): Invalid response ("Math extension cannot connect to Restbase.") from server "https://en.wikipedia.org/api/rest_v1/":): {\displaystyle k} times more relays than srep, but each relay only carries Failed to parse (SVG (MathML can be enabled via browser plugin): Invalid response ("Math extension cannot connect to Restbase.") from server "https://en.wikipedia.org/api/rest_v1/":): {\displaystyle 1/k} times data. So ec uses the same number of bytes as srep. Because Failed to parse (SVG (MathML can be enabled via browser plugin): Invalid response ("Math extension cannot connect to Restbase.") from server "https://en.wikipedia.org/api/rest_v1/":): {\displaystyle 1/r} code blocks are needed to reconstruct the message, Failed to parse (SVG (MathML can be enabled via browser plugin): Invalid response ("Math extension cannot connect to Restbase.") from server "https://en.wikipedia.org/api/rest_v1/":): {\displaystyle k} relays have to deliver their data successfully. For Failed to parse (SVG (MathML can be enabled via browser plugin): Invalid response ("Math extension cannot connect to Restbase.") from server "https://en.wikipedia.org/api/rest_v1/":): {\displaystyle k=1} ec is the same as srep.
Benefits
In srep Failed to parse (SVG (MathML can be enabled via browser plugin): Invalid response ("Math extension cannot connect to Restbase.") from server "https://en.wikipedia.org/api/rest_v1/":): {\displaystyle r} relays are used and one has to succeed. In ec Failed to parse (SVG (MathML can be enabled via browser plugin): Invalid response ("Math extension cannot connect to Restbase.") from server "https://en.wikipedia.org/api/rest_v1/":): {\displaystyle k*r} relays are used but Failed to parse (SVG (MathML can be enabled via browser plugin): Invalid response ("Math extension cannot connect to Restbase.") from server "https://en.wikipedia.org/api/rest_v1/":): {\displaystyle k} relays must succeed to reconstruct the message. If the number of low delay relays is larger than Failed to parse (SVG (MathML can be enabled via browser plugin): Invalid response ("Math extension cannot connect to Restbase.") from server "https://en.wikipedia.org/api/rest_v1/":): {\displaystyle k} ec will deliver the message with a lower delay than srep.If Failed to parse (SVG (MathML can be enabled via browser plugin): Invalid response ("Math extension cannot connect to Restbase.") from server "https://en.wikipedia.org/api/rest_v1/":): {\displaystyle k} is large, the delay distribution converges to a constant. Therefore ec has almost a constant delay.