Re: [dtn-interest] DTNRG Minneapolis IETF 73 meet minutes roundup

<> Sat, 21 March 2009 10:02 UTC

Received: from ( []) by (8.13.8/8.13.8) with SMTP id n2LA28Bb021515 for <>; Sat, 21 Mar 2009 03:02:09 -0700
X-VirusChecked: Checked
X-StarScan-Version: 6.0.0; banners=-,-,-
X-Originating-IP: []
Received: (qmail 18769 invoked from network); 21 Mar 2009 10:01:22 -0000
Received: from (HELO ( by with SMTP; 21 Mar 2009 10:01:22 -0000
Received: from ([]) by with Microsoft SMTPSVC(6.0.3790.3959); Sat, 21 Mar 2009 10:01:22 +0000
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C9AA0B.FCA45F20"
Date: Sat, 21 Mar 2009 10:01:21 -0000
Message-ID: <>
Thread-Topic: [dtn-interest] DTNRG Minneapolis IETF 73 meet minutes roundup
Thread-Index: Acmp2CQ33lVdrL5kSiOncXPLSVEIigAMTqph
References: <> <>
X-OriginalArrivalTime: 21 Mar 2009 10:01:22.0213 (UTC) FILETIME=[FCF64550:01C9AA0B]
Subject: Re: [dtn-interest] DTNRG Minneapolis IETF 73 meet minutes roundup
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Delay Tolerant Networking Interest List <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sat, 21 Mar 2009 10:02:11 -0000

I did some digging - here are details, and I hope the IETF
webmaster can take action here.

the missing minutes of the IETF 73 DTNRG meet are below
at end. You have the slides, which you have been converting
from ppt to pdf where needed.

Even though the chairs missed your deadlines for submitting
minutes, can you put the DTNRG meet on the record and in the
IRTF section of the official proceedings at
, please?

Reply to Will:
It appears that several of the presentations
(mine, Will Ivancic's, Scott's and the chairs) have now been
converted to html from powerpoint by someone using a Mac,
and the links on the 'hidden' non-official agenda page at
, which is all there is, since the chairs did not send minutes
in in time, have not been updated to match.

Look under:

Only give the chairs pdfs to avoid this happening. If
there are no animations, you can present fullscreen
from Acrobat in much the same way, so ppt is not needed.
(A pdf copy of my own presentation is at the bottom of:
I gave Stephen both ppt to present and pdf for archival. )

It would be churlish to complain about the lack of organisation
of the chairs that led to this situation - even though it's
hardly the first time that deadlines have been missed, or
reminder emails have passed by without action. I believe
they're doing their best.

But really, it's just a symptom of a larger problem
in how this group is directed, evidenced in protocol design
and other problems. Enthusiasm and having a lot of activity
and drafts isn't enough by itself.



-----Original Message-----
From: Will Leland []
Sent: Sat 2009-03-21 3:50
To: Wood L Dr (Electronic Eng)
Subject: Re: [dtn-interest] DTNRG Minneapolis IETF 73 meet minutes roundup
Thanks for posting this info, Lloyd.

A possible glitch: the following URLs all generated
an object-not-found (404) error when I tried to access them just
-- Will

Lloyd Wood wrote:
> This email is intended to round up the non-final IETF 73 Minneapolis November 2009 Delay Tolerant Networking research group (DTNRG) minutes and presentations to provide information in one place in the list archive.
> Minutes were not submitted to the IETF in time by the chairs, so the minutes and presentations aren't officially in the IETF 73 proceedings at:
> which does not link to the hidden:
> where a number of presentations are stored:
> 0900-0905       Welcome & agenda bash   Chairs
> 0905-0915    DTNRG document status Chairs 
> 0915-1000    Planning to finish existing documents All
> 1000-1020       Bundle Checksums        Lloyd Wood
> 1020-1030       Ohio Univ. testbed work         Hans Kruse
> 1030-1040       UDP CL  Hans Kruse
> 1040-1050       NASA/CCSDS DTN update   Will Ivancic
> 1050-1100       N4C/PRoPHET     Avri Doria
> 1100-1115    Bundle encapsulation discussion  Susan Symmington 
> 1115-1129       Deep Impact Experiment  Scott Burleigh
> (Scott and Lloyd presented on two separate tests of the DTN bundle protocol using spacecraft.)
> The draft minutes, taken by Elwyn Davies, were posted to the list by the chairs:
> but in word and pdf format - and only text is archived on the list (so, no point in sending the above powerpoints to the list). Those draft minutes are repeated at end below as text to at least provide a readable copy in the list archive. To my knowledge, there are no final minutes or comments on these draft minutes.
> ***
> Notes on DTNRG meeting @ IETF 73 Thursday 9-11.30 
> Highlights:
> "       We'll do a "last call" on the following documents "now," where "now" means as soon as the authors say they're ready on the list:
> "       draft-irtf-dtnrg-prophet
> "       draft-irtf-dtnrg-tcp-clayer
> "       draft-irtf-dtnrg-bundle-security
> "       draft-irtf-dtnrg-sec-overview
> "       draft-irtf-dtnrg-sdnv
> "       draft-irtf-dtnrg-bundle-previous-hop-block
> "       draft-irtf-dtnrg-cbhe
> "       A bunch of people (about 10-12) agreed to put up bundle protocol nodes on the Internet and we'll use Hans Kruse's dtnbone mailing list to co-ordinate that; we set ourselves some goals to meet before the March meeting.
> " 
> "       Scott Burleigh reported on their experiment with a BP/LTP router running on the Deep Impact spacecraft and communicating 25 million km back to Earth
> Kevin Fall: Introduction
> "       Intros and agenda bashing - no changes requested
> "       Doc status (LTP RFCs now published)
> "       Announcement of standalone meeting (March 20/21 SF, hosted by Google, Logistics later)
> Stephen Farrell: Looking at drafts status
> "       Aaron Falk: Expressed wonder at number of potential RFCs
> "       Lloyd Wood: Saratoga docs future:  Saratoga base docs in Transport Area; dtnrg docs future are bundle over Saratoga.. what goes on depends on what goes on in transport area
> "       Susan Symmington:  Asked for input on retrans block.  Metadata drafts - would like them to go forward
> "       Joerg Ott:  Thinks metadata 'ontology' system is too vague for proto developers.  
> "       SF: Please start discussion on list
> "       ?: dtnbadisc.. has been implemented but not sure if author still working on it
> "       JO: dtn-appl:  will discuss with SS how to progress metadata
> "       SF: would love km to go forward 
> "       SF/JO: not sure if kutscher unicast cl is going forward
> SF: doc completion..
> "       Took 18months  to get RFCs.. asked EBD to shepherd bunch of docs
> "       Steve Crocker(?): useful to give feedback on new IRTF doc stream process
> "       AF: RG shepherd is responsible for pushing docs forward.. delay caused by dropped tokens.. difficulty is often on converging after review
> "       ?: talking about what happens in getting consensus on publishing - and where it is stated
> SF: docs ready for last call: ~6 docs
> "       SS: want previous hop block on list; also metadata docs if resolution can be achieved
> "       Scott Burleigh:  Wants compressed bundle header (CBHE) on list also
> "       SS: previous hop block is ready for last call
> "       AD: Prophet is very nearly ready - end of CY
> "       SF: Bundle sec end of CY 08
> "       SF: sec overview END OF YEAR
> "       LW: bundle checksum neds a bit more work
> "       Wes Eddy: sdnv essentially ready
> "       SB: compressed bundle header ready
> "       JO: UDP CL:  question about whether it would be good to be able to know how big bundles might be (unit of transfer)?  But doc is probably ready now - SF: took view that this shouldn't be in CL
> Lloyd Woods: Reliability - further points for discussion
> "       - scenario not covered by bundle checksum draft
> "       - presented slides
> "       - overview of DTN from a control loop PoV
> "       - asserts DTN not same as current low elasticity IPv6 state of the art - DTN needs a different approach to reliability
> "       - worked example - one bundle encrypted/integrity protected (term should be 'PCB'), other just reliability mechanism
> "       - compare how soon bundle arrives intact - in scenario exhibited insecure coperhsuite reliability one arrives first
> "       - conclusion: need to provide a combination confidentiality+ reliability mode to allow for fast resends
> "       Questions:
> "       SF: If this doesn't work already it is a bug in the docs
> "       LW: not clear that docs allow sequential application of mechanisms.. need text in docs to ensure this can happen
> "       SS: believes docs cover this
> "       LW: will think about some text and write careful notes
> "       SC: Corruption exhibited could fall into two classes:  (1) 'mother nature' induced changes would be caught by this (2) malicious changes might not be.. probably only a public key based story would be  needed
> "       LW: believes his proposal covers both cases - need both 'layers' to cover both cases
> "       KF: this kind of integrity check might not work with situations are using FEC to improve reliability
> "       SF: should chat with SS and work through docs to ensure cases are covered.
> "       KF: remember Fec case
> "       LW: Picture on how a convergence layer should support reliability. 
> "       LW/KF: No doc tells about what bundle proto expects from CLs
> "       Wes Eddy:
> "       Hans Kruse: Want to be careful about what goes in CL and what goes in bundle - architecturally common reqs need to go in higher layers or maybe in a service proto
> "       KF: might end uo with a shim at bottom of bundle proto to manage 
> "       Gory Fairhurst:  Do we have to do it in UDP CL?  IETF says you have to explain how you do all the things that UDP doesn't do for you
> "       KF: UDP draft has pointer to the RFC that talks about this story
> "       LW: reporting on reliability problems experienced in transferring images from satellite (as reported in Time magazine)
> "       KF et al: Origin of Orbital Internet phrase
> Hans Kruse: Dtnbone - test systems at OU
> "       NASA starting to use test environment as a cheaper alternative to real satellotes
> "       ION end points shortly available for trials
> "       Firefox plugin available to give access to ION web proxy 
> "       ION uses a different TCP CL - uses two TCP connections - NAT issues.. bundle relay helps
> "       No DNS mechanims yet.. so naming issues - wiki available to manage naming issues
> "       May get DTN2 nodes available in testbed help with tests
> "       network management is being thought about
> "       needs resources to maintain internal security/integrity! (war story!)
> "       Mailing list available - see slide
> "       Questions
> "       Will Ivancic: Is compact routing available?
> "       HK: yes - routing a focus in near future
> "       KF: (asking AF) Would this be something that could be factored into Geni?
> "       AF: Are you bringing infrastructure or expertise to table?
> "       HK: both
> "       AF: so would be good in Geni.  Geni looking at resource allocation interfaces 
> "       HK: that would be good as don't want to spend time on that.
> "       SF: Can anybody else consider putting up bundle agents?  How many exist at the moment?
> "       (count was around 10)
> "       HK: Send mail to HK to inform him of publically available nodes.
> "       SC: Public net would be very useful
> "       HK: Good to have a directory
> "       JO: Would be good to have something more than pings.. maybe a camera.. they have that in their net.. will have a 2.6.0 web server soon
> "       HK: good to have different sorts of traffic flying around
> "       AF: interesting to have nodes on different types of network as well as sorts of connectivity
> "       KF: PlanetLab stil has a DTN project.. also look at using lambda mechanisms.. also DARPA have stuf on transmitting VoIP over DTN (!)
> "       AD: N4C will want to connect to Geni
> "       SF/AD: might have  a 'funny' network connected during summer trials
> "       KF: Don't forget Massachusetts folk doing diesel net etc
> "       SF: register to dtnbone mailing list if can contribute
> "       SF: a goal would be useful
> "       KF/HK: see if can exchange a ping between 6 sites by march - using at least 2 different implementations and different CLs.
> Hans Kruse: UDP CL
> "       00 draft out now
> "       Why bundle protocol overUDP (rather than directly over IP)?; Does it meet pseudo-reliable assumption in RFC 5050; Do we need Ack and retransmission
> "       Questions:
> "       KF: Doesn't believe 5050 really requires pseudo-reliability
> "       Bob Cole:  Maybe nodes don't want to acknowledge their existence
> "       KF: Use UDP if don't care about acks or reliability
> "       HK: Suggest that should not feed UDP CL with segments that need further fragmentation; Would like to avid complicating the CL with further frag capabilities; UDP lite options: Suggest that should *not* disable checksums in LTP.. but might be useful for bundles
> "       WE: why UDP and not IP?  Getting through NATs is not really helpful for DTNs.  If really worried about size of packet than UDP header could be an issue.
> "       SB: Think about providing hints from bundle layer to CL (system?) about what sort of CL would be preferred.
> "       HK: shim talked about earlier might be a good solution. Bundle agent would have to pick between options
> "       LW: IPv6 doesn't allow turning off UDP checksum. Would have to use UDP lite if want to anoid reliability enforcemnet
> "       KF: wants to avoid having realiabiluty mechanisms imposed in it.  If bundle already has internal protection against bit errors then don't want to use alternatives as well
> "       GF: UDP lite is the right solution for this
> "       HK: New RFC 5450(?) tells about protecting networks from injudicious use of UDP.  Need to adhere to guidelines so that we don't get in trouble.  Need to add some text to doc guidelines.
> "       GF: RFC says must do congestion control if doing very large transfers.  PWE wg has a 'shut up' solution.. should investigate.  
> "       KF/GF: Could work over DCCP instead for working over Internet?  RFC says we ought to use it.
> "       HK: because we don't always have control loops then DCCP might not be relevant.  UDP would still be needed.
> "       LW: Look at Saratoga implementation which has studied a number of these issues.
> "       SF: Please review draft
> Will Ivancic: NASA update
> "       Discussing test plan
> "       UK-DMC implementation with partial DTN implementation; Learnt checksums were very useful.. spacecraft added MD5 checksums.. checked manually on ground
> "       NASA flight readiness by 2011 plan; trying to get operations people involved; Building a Multi-center DTN Engineering Testbed (DEN)
> "       Hoping to have a gateway from NASA network to dtnbone
> "       Description of CCSDS  - inter-governmental standards org - has DTN wg working on how to adapt bundle protocol and LTP for space work (assuming they are deemed suitable)
> Avri Doria: N4C report
> "       PRoPHEt update.. more or less ready for experimental status; needs a bit about how to set parameters to get best out of proto in various scenarios
> "       will be doing simulations to see how values should be adjusted
> "       emulation network being created
> "       Simulation status - some PRoPHET 'bashing' in papers.. need to investigate whether this is reproducible and to determine how we can fix any problems 
> Susan Symmington: Bundle-in-Bundle encapsulation (no slides)
> "       Reporting on recent teleconf
> "       3 use cases
> "       may want to send bundle from cache to late joining uses - need to encapsulate to avoid being resent to all previous recipients whe using multicast destination
> "       resend custody bundle to particular recipient
> "       tunnels
> "       draft suggested using custody records but not possible; current conclusion is that encapsulation is now an application issue; doesn't really affect bundle protocol; draft just needs to say how to do encapsulations; but may need to have new feature in bundle proto - 'diversion'
> "       Questions:
> "       KF: Not clear that multicast case is really so. Routing tables may be able to suppress retransmissions - people using information layers on top may nit need this
> "       SS: need two docs: ID for encap that is application layer and ID for specifying diverting and receiving bundles
> "       SC: Suppose you view all attempts at multicasting as partial - then you would get the sending to an extra member for free - each attempt just sends to a subset of members.. conceptual view
> "       AD: Maybe tied in with need to divert bundles into alternative routing protos.
> "       SB: Maybe think of b-in-b as a different CL.
> Scott Burleigh: First look at Deep Impact DTN Experiment
> "       Deep Impact between tasks so available for tests
> "       Demonstrating ION and getting technology readiness 7/8 qualification
> "       Used CCSDS AMS (Asynchronous Message Service) over BP/LTP
> "       Concluded that fully automatic operation of a DTN over deep space links is feasible
> "       Software is at tech readiness level 7
> "       Questions:
> "       Malcom Eris: Have there been BW efficiency calculations on various protocol stack options.
> "       SB: first pass on this expt is that DTN overhead is in noise compared with necessary FEC
> "       ME: Tictoc wg in IETf asking if DTN has any timing requirements
> "       SB: Space was OK with 5-10 secs level.. but better might be useful
> "       KF: Other project (like aircraft) might have stricter reqs: encourage people to send info to tictoc mailing list (ME to send pointer to dtn interest)
> "       WI: How was contact plan infor sent to speaccraft for routing
> "       SB: Tried to keep it low risk so didn't send stuff to spacecraft but expect o do that it follow up
> "       WI:  will a dynamic routing proto be needed to cope with change of plan?
> "       SB:  actually do parts.. management and (more static routing)
> _______________________________________________
> dtn-interest mailing list