DTNRG met Friday November 13th 2009 from 9am to 11:30am at the Hiroshima IETF meeting.
(Thanks to Pete Lovell and Elwyn Davies for taking notes and to Peter St. Andre for jabber scribing.)
Agenda: http://tools.ietf.org/agenda/76/DTNRG.html
Slides: https://datatracker.ietf.org/meeting/76/materials.html#wg-DTNRG
Jabber log: http://www.ietf.org/jabber/logs/dtnrg/2009-11-13.txt
Meeting audio: http://www.ietf.org/audio/ietf76/ietf76-ch5-fri-am.mp3
Brief addition from Peter St. Andre: XMPP has a serverless mode for P2P style operation and its normal client-server mode, thinking about DTN as a way to bridge between these. If interested contact Peter. Kevin Fall noted that folks doing network management were working on a space use-case draft, and this might be another one, so encouraged folks to write such things.
No IRTF RFCs were published since last IETF meeting due to boilerplate/IP problems (nothing from DTNRG delayed by this though).
DTNRG has five published RFCs, seven drafts about to go to IRSG. (20091218: Five so far now in IRSG review, prophet still being finalised, retrans to to be done later.)
Seven other non-expired draft-irtf-dtnrg-* drafts and six other non-expired draft-<author>-dtnrg-* drafts.
Kevin voiced concerns regarding BSP spec, hoped that these could be resolved this week. (20091218: They were.)
There was discussion of the "EID naming" issue raised by Kevin and several others. The issue affects protocols that want to include an EID for “this node” where there can be multiple registrations – which of those EIDs (or a different one) to use?
Joerg Ott thinks that the issue is resolved w.r.t. prophet, and probably resolved for PHIB (by Susan Symmington). He understands that there are three options and is unsure which will be the solution. It turns out that TCP convergence layer has a similar issue. Kevin points out that the issue is one of multiple registrations (for a single node), and that it is deeper than we had previously thought.
Masahiro Sasabe (Osaka University)
An interesting proposal based upon the notion that, when two nodes meet, they can set their clocks to the mean of their current times. Accuracy needed depends on purpose us for transmission sync or maybe only ms for other purposes. NTP clearly not suitable for manets. Could possibly use GPS – issue with costs and need to see satellites difficult for nodes to estimate reliability of time info of neighbors.
Kevin was concerned that one of the clocks goes backwards, and that may have nasty side effects. However, it's possible to pause clock that would otherwise go backwards. Or to slow it to bring it into sync. (said Joerg). Kevin was also concerned about having a few nodes that are poorly synchronized throwing others off. An improvement could be to have a variance also factored into the adjustment.
Joerg also was concerned about the impact of some clocks having a large time skew, malicious or otherwise.
Stephen Farrell asked if there might be a way to extend this to the transit time of a bundle being moved in static storage (i.e. USB flashdrive or similar) as opposed to being transmitted node-to-node. No-one had an acceptable idea for this, though.
chat room:
Q: does this rely on directly-neighboring nodes?
A: yes
Q: does this use BP? What is the timeout?
A: No BP implementation but could be done that way.
Q: how can this be extended to absolute time, such as UTC?
A: there could be an externally provided source for absolute time that would enable the relative-time offset to be used to calculate absolute time
Hideya Ochiai (The University of Tokyo / NICT)
A routing proposal that looks at mobility pattern and forwarding. Nodes with limited mobility deliver messages through hop-by-hop forwarding, more mobile ones often deliver by coming close(r) to the destination. The routing decision uses "potential field" as inspired by diffusion theory. PEAR looks at high and low entropy systems – affects the sorts of contacts, assigns a 'potential field' to the network – equations used for these are like diffusion equations - analogy to heated plate with a lump of ice on it.
Experimental results were presented based on armadillo box (http://linuxgazette.net/145/john1.html): a couple of sensors + Internet gateway + 10 mobiles; useful contact graph – high entropy case; seems to have achieved good delivery throughput.
Some attendees noted that the system would work best for a relatively stable set of sources and sinks, rather than many/all nodes being both.
Joerg and Elwyn Davies asked: how is potential calculated?
Elwyn asked if it would work for other than fixed source/sink situation?
A: a longish discussion (not minuted;-)
Brenton Walker: would code/data size if many sources?
A: not too much (didn't catch answer properly)
Someone asked: how long was a reasonable time? (for convergence?) ?
A: about half an hour
chat room:
Q: were the nodes pre-configured to know about their neighbors
A: no
Q: is the code published?
A: no, but it will be
Q: is the hardware shown available only in Japan?
A: no - it's not Japanese-specific
Q: is the system suitable for interplanetary systems?
A: unknown
Prof. Masato Tsuru (Kyushu Institute of Technology / NICT)
The presentation covered the wide range of DTN experiments that have been undertaken funded by NICT, and also ones that are planned to be done. Commercial interest is starting to grow, but is still limited. Generally using DTN2.
Kevin: what types of commercial interest are increasing?
A: bus companies – currently use docomo and spend lots of money – wifi may be cheaper; construction companies in rural areas
chat room : Are these projects using RFC5050 or other or both
A: RFC 5050
Elwyn: throughput is theoretical as yet.. not using ad-hoc mode – hope to get output on throughput in future messages about getting comments/bug fixes on DTN2 code
Elwyn: are the "contact-time" figures experimental data or calculated estimates?
A: estimated data, for now
chat room: it would be good to get feedback about RI
Stephen Farrell (TCD)
Stephen's report on networking for communications-challenged communities (http://www.n4c.eu/) experiments in Laponia in summer 2009 as part of the ExrtremeCom workshop (http://www.extremecom.org/).
Q: what were the clock issues?
A: none really, although there were some configuration issues. Especially for bundle-timeout; drift wasn't an issue; some issues with synchronization of clocks when analysing logs
Q: was it static routing or opportunistic discovery
A: (Elwyn) static, but with IP discovery
Q: how did you know what to set the bundle lifetimes to?
A: we didn't. So we guessed. In one case the guess was a bit short so we have to adjust it upward
Elwyn Davies (Folly Consulting)
http://www.ietf.org/proceedings/09nov/slides/DTNRG-7.pdf
Elwyn proposed an "anycast for dtn:" URI scheme for service location and other uses. Kevin believes that existing mechanisms provide all the functionality needed. It would seem that there will be offline discussion to decide this.
Kevin Fall (Intel)
http://www.ietf.org/proceedings/09nov/slides/DTNRG-5.pdf
New release (2.7) coming soon done by Alex McMahon (a TCD student visiting Kevin in Berkeley thanks to Intel sponsorship). (20091218: That has happened.)
Peter Lovell: DTN2 contains BSP code, and that there will be updates for key transport.
Q: (Elwyn) is anyone using "sessions ?
A: (Kevin) it's under development
Brenton Walker, Laboratory for Telecommunications Sciences
http://www.ietf.org/proceedings/09nov/slides/DTNRG-6.pdf
An investigation of usability and stability of DTN software on mobile handsets.
Crucial question: which code base to start from?
Joerg: standardization would be great, there won't be a single common code base, no good *general* routing protocol, so use flooding as a default.