prophet update

PRoPHET Update

DTN Research Group @ IETF 7827 March 2010

Elwyn Davies

[email protected]

Avri Doria Samo Grasič Anders [email protected] [email protected] [email protected]

mailto:[email protected]




30 July 2010 PRoPHET Update - IRTF 78 2

Progress with PRoPHETNew Version

http://tools.ietf.org/html/draft-irtf-dtnrg-prophet-06

PRoPHET in use in N4C testbeds Slovenia (continuous use for almost 2 years) Arctic Sweden (Summer testing)

Simulation work by Samo and Elwyn Draft update includes

Addressimg IRSG review comments Improvements resulting from recent experiments Additional capabilities to fix long standing issue


Experiments in Progress - 1 Slovenia

Gradually extending network of unattended environmental sensors (meteo and radiation)

Data mules Active nodes in cars Symbiotic (Parasitic) nodes – just a USB memory stick

Using PRoPHET routing Analysis of results has found problem with

transitive update algorithm


Experiments in Progress - 2 Arctic Sweden

See reports – previous DTNRG slides! GSM to edge of area, Helicopter mules Two systems running in parallel

'Village Router' hot spot system - static routing/DTN2See http://village.n4c.eu - need to set HTTP proxy for best effect! Email and web caching proxy system

PRoPHET routing nomadic systemSee http://dtn.n4c.eu for more info, NSIM, web cam, logs, etc

Two months testing during reindeer marking/ hiking season in Padjelanta

http://village.n4c.eu/

http://dtn.n4c.eu/


Refresher: Key Equations

Notation: P(A,B): Delivery Predictability in Node A for delivering a bundle to Node B.

Eqn 1: On A encountering B P_(A,B) = P_(A,B)_old + ( 1 - P_(A,B)_old ) * P_encounter

Eqn 2: If A hasn't encountered D for a while: P_(A,D) = P_(A,D)_old * gamma^K

Eqn 3: Does A meeting B mean that A is a better bet for delivering to C? Transitivity... P_(A,C) = P_(A,C)_old +

( 1 - P_(A,C)_old ) * P_(A,B) * P_(B,C) * beta


Simulation Work - 1 Samo working to reproduce and validate results

from RAPID paper comparison PRoPHET came out very poorly in this work

Slow progress due to various problems Competing demands of test bed deployment Acquisition of simulation code used by RAPID team

Found RAPID PRoPHET implementation didn't match specification

Recently got comparative results using ONE sim #1 conclusion: match proto to scenario

Otherwise random routing will work better!


Simulation Work 2 Elwyn has been working on visualizing the

evolution of delivery predictability Simple Excel Spreadsheet simulator Python program + Excel display using mobility

files generated by Anders original prpogram. Using these to check how DPs evolve and

ensure that they reflect the expected future encounters. Evaluated proposed alternative evolution

equations Selected replacements now in field trials


Main Problems Identified Inappropriate evolution of delivery

predictabilities (DPs) Repeated encounters of '3rd party' nodes leads to

jammed bundles . Parking Lot Problem – When is an encounter not a

(new) encounter? Totally random encounters => noise in DPs Deriving a relationship between the various

PRoPHET parameters Need guidelines for setting parameters appropriately


Bundles Jammed in 3rd Parties Scenario (at least 4 nodes: A - D):

Node B meets Node A & (separately) C occasionally. Nodes C and D meet each other repeatedly between

meetings of Nodes B.and C DP for Node A increases steadily in Nodes C & D

until bigger than DP for Node A in Node B Result: Bundles for A not transferred from C/D to B;

hence jam in C and are never delivered. Identified in long term Slovenian experiment Fix: Improved transitivity update algorithm


Parking Lot Problem Scenario:

Multiple Wi-FI nodes milling around in a small area Multiple 'encounters' e.g. due to Wi-Fi

reconnections. Can result in

DP update 'loops' – changes propagated round loop One actual encounter being treated as several

Identified from theoretical considerations Fix: Allow nodes to suppress DP updates


Noise in DPs from Random Encounters

Scenarios in which a node encounters lots of nodes that it will never meet again Typical of some simulation scenarios

Can lead to random routing outperforming PRoPHET (and other algorithms) if there is little pattern to encounters Make sure you are using PRoPHET in an

appropriate scenario! Fix: Set P_(A,B) to a lower value on 1st meeting

Could avoid applying transitivity on first encounter


Too Many Degrees of Freedom?

PRoPHET has a lot of (apparently) independent parameters.

There wasn't a good story on how to choose a consistent set of parameters.

Fix: Describe how they each relate to the 'characteristic time period' of the PRoPHET zone. and this also relates to the approptiate bundle

lifetime and custody timer settings


Improvements: Equation 1

Reduce the effect of random, one-off encounters

On first encounter set DP to a lower value Suggest 0.25 rather than the 0.75 in old

version Do the same if the DP has decayed below a

threshold because last encounter was a long time ago.

Use existing equation 1 on subsequent encounters when P_(A,B) not below threshold


Improvements: Equation 1

Avoid DP actually reaching 1 ('Almost Sure') on repeated encounters

New equation: P_(A,B) = P_(A,B)_old +

( 1 - delta - P_(A,B)_old ) * P_encounter Delta is a small value that stops the value

getting right to 1.0


Improvements: Equation 3 Avoid DP increasing inappropriately due to

repeated encounters between 3rd parties that haven't actually met suitable intermediaries.

The improved equation is intended to converge the DPs for C in A and B after repeated encounters BUT only to the highest value that either of them started with P_(A,C) =

MAX( P_(A,C)_old, P_(A,B) * P_(A,C) * beta ) Beta is a 'slowing factor' – reduces convergence

rate


Characteristic Time Period Concept: A ProPHET zone has a characteristic

time period (CTP) that is determined by the expected time intervals between encounters

Bundle expiry times should be set so that bundles will be around sufficiently long to be delievered but not hang around for too long

DP decay should reduce a DP to essentially zero after 3 to 5 multiples of CTP

An encounter should at least undo the expected decay between encounters

Treat closely spaced encounters as one


Improvements: Suppress DP Recalc

Added a flag into the Hello TLV that requests suppression of DP recalculation phase.

Has to be agreed by both parties in an encounter Otherwise recalculation is done on both sides

Nodes can choose to suppress recalculation if they have met very recently and they don't have new information to convey Very recently means (say) 5% of CTP


Progress towards RFC

RG Last Call completed Various clarifications (especially thanks to Kevin)

Currently in IRSG Review process Somer additional clarifications added in latest

version (-06) Some significant improvements since review

May need to repeat last call/review


New Protocol Version

The protocol has been taken to version 2 as the changes to the equations and Hello TLV are not fully interoperable.


Next Steps Pass the improvements to IRSG reviewer Check performance of improvements in the

field Do we need another Last Call?

There have been significant updates


Thank You


DTN2 Functional Spec Product of N4C work – Elwyn and Avri Doria

Nearly 200 pages!! Currently accessible at

http://www.n4c.eu/Download/n4c-wp2-023-dtn-infrastructure-fs-12.pdf

Contains: Spec of API A complete specification of the TCL command

interface Detailed operation of the core specification

Missing – Sessions and External Router/CL

http://www.n4c.eu/Download/n4c-wp2-023-dtn-infrastructure-fs-12.pdf

prophet update

Documents