DTNWG BOF Meeting Minutes ======================== Key points: ======================== * Not much disagreement on DTN architecture (RFC4838) * Charter could and should be simplified * Concern that IPN naming scheme is too space-centric * Multiple organizations proposed support (Boeing, Airbus, Peace Corps, NASA, European Defense Agency, DARPA) * By vote, about half a dozen direct supporters for writing I-Ds * Question of whether to look at HTTP/MIME, perhaps in the DTNRG. * Not clear that MANET solutions are helpful here. ======================== Marc: Walking through the agenda. ======================== ======================== Questions and Comments from Fred’s Presentation ======================== Dirk: Internetworking requirement. We see more DTN deployments, but largely isolated deployments, no connected to anything other than themselves. Do you see this differently? Fred: Yes and no. Based on use case. See cases that use Internet as hop between isolated nodes. DTN as overlay can be over multiple networks, including corporate network or MANET. Dirk: Are people doing it, and is there a need? Don’t see why these systems will interact. Fred: Would like to see underlying networks. Whether it is on open, public internet, or others, it still needs to have underlying support. Nalini Elkins? Comment: Not DTN on the Internet, but a few use cases where internet+DTN are both involved. Working with Peace Corps, humanitarian arm of US government going to remote villages for internet access: Internet book mobile – go from village to village with vehicle(taxi, car, bus) and village is remote, so people come to the bus. When we reach a point for an internet AP, we have “blammo” connectivity. Fred: Agreed. Stephen Farrell: Lots of use cases are known for years. People have done lots of experiments. What is not clear is that any of them would be deployed if there is a standard. Absent that being clear, that presents the WG with a problem of, when faced with a choice of standards, we will be guessing. Fred: Inside of Boeing we have 4 products asking for DTN maturation within the next 2 years, only 1 is space based. Stephen: None of that will help make decisions, for example, on how to change the timestamping. A WG will not have a basis to rationally choose. Brian: Will WG include ownership of stuff like SKIPS? (TCP proxying protocol over sitcom). Fred: No. Scott Burleigh: Integration question: It is important, to NASA, to have a simplified infrastructure to integrate space and ground communications. Bulk of NASA comms is on the ground. Expect this to also be true in oceanographic use cases. John Dowdell: Work for Airbus, also implementing 2 DTN protocols right now. Stephen Farrell: If someone from airbus wants to use this, then the “for what” part is what is missing? John: Implementing 5050, also implement PRoPHET as well for some proper use caes that Nalini was mentioning earlier: long range pairs. ======================== Scott’s Presentation: Summary of Technical Topics ======================== JabberQ: What was used here from IETF? Scott Burleigh: Used IRTF protocols from DTNRG. Jabber Q: IETF MANET Protocols and Ad-Hoc protocols. IETF has had a WG there for 15 years and question is: why not leverage those in some way? Stephen Farrell: MANET to network in ADHOC, in DTN network is all broken up, it is a different problem. Stephen Farrell: Missing thing on list of extra problems: 5050 built in a specialized way. You can’t just go and pick up the normal toolkits developers of the internet use and implement 5050. Ease of implementation is a problem that is not on the list. Not proposed in the charter to be addressed. Scott Burleigh: Fine with addressing it in the charter, do you have an example? Stephen Farrell: Lots of standard protocols that have HTTP headers and use MIME for payloads. If you design a protocol that meets RFC4838 it could be transitioned more easily to development on the Internet. May be on the rough in this area. List of changes given is too long. Would need us to arrive at a consensus list. Scott Burleigh: Lots of stuff has been prototyped, but not in every implementation. Not specific to space, per se, but space efforts do need it. Roman Filtino (sp): Current 5050 serves space and terrestrial use cases. To what extent do you propose simplifications or modifications to make it more space oriented? Worry that this is too much towards space needs. Scott Burleigh: Getting rid of the dictionary would cut down on the complexity. Using URLs as endpoint IDs that don’t match up with nodes creates enormous complexity in the implementations. Changes would make implementation, and utilization easier. Roman: Not everyone wants to use the IPN naming scheme. Scott Burleigh: Extension block for other scheme endpoint IDs. Will not rule out other naming schemes, but for many applications, you want to send data to a node that you know where it is. We can discuss in the WG. Wes Eddy: bundle of problems paper wasn’t intended as needs for a WG. It was more like a research agenda looking at non-BP alternatives to solve the same architecture problems. In particular, the HTTP-based work. Wanted to agree with Stephen’s goal, especially with bridging to the Internet. Same group wrote another paper where we realized a lesson from DTNRG was that people are doing DTN in a specific use case (much like Dirk’s question). The use cases need to be pretty clear and turn into requirements. Fred’s presentation was high level, and should boil down to scalability requirements. How is it possible to make decisions without scoping the use cases a lot better. Stephen Farrell: Concept of baking in IPN naming and CBHE would be a mistake. Because CBHE is half-way between CL and a set of naming principals. It is nearly a convergence layer. What CBHE tries to do should be done via a convergence layer. Scott Burleigh: The CBHE comment is a valid input with which I disagree. Jorg: Nervous about hop count and node number. Were happy to use identifiers for nodes that can be self-generated with fewer problems of collision. IPN by itself seems to be too limiting. What Wes and Dirk said before, there are scenarios that don’t interoperate and therefore don’t need to agree, may be fine, but then we shouldn’t be picking one scenario over another is not a correct path. Maybe selecting tools is better, for example text encoding. We should not make decisions that do not push us into one specific corner. Scott Burleigh: Valid POV, and thing to work about in the context of the WG. ======================== Discussion of charter ======================== No questions on the proposed charter. Stephen Farrell: Next agenda item is the interesting part. Open Mic. It’s hard to delve into the text. So, open the mic for discussions. ======================== Open Mic: Should we have a WG, ======================== Charlie Perkins: In MANET group. No question was asked if there was useful work in that group. For the DTN, not too much has been done there. Some discussion on buffering, but that isn’t very much help. As far as disruption and patching up routes, considerable work has been done for that and it may be helpful. Martin: Responsible area director for the BOF. Helpful to say is it useful or not. Ronald in'Velt: International project run by European Defense Agency is looking at networking MITNET? Following DTNRG, during last months. Would very much like to base our solutions on standards and we see a need for connecting to the internet on occasion, so we really support this. With provision that we are coming in from the terrestrial side of the DTN use cases. Don’t make it too space oriented. On the whole, we really support this and are willing to do work here on security and extending QoS mechanisms. Maybe other things. Person favorite would be neighbor discovery and contact management listed as long-term, perhaps it does not need to be long term. Marc: Please send summary e-mail. Rick Taylor: Getting up to speed on DTN. We need to look at this. We have a lot of internal use, and it must be interoperable. Let’s make it standards based and interoperate. We support this and move it on. As a second point, heavily involved in MANET. There is not a lot of cross-over. It is connected, just in a random way. Store and forward is not covered at all. Fred: DTN can run over Manet. Wes Eddy: You mentioned in chartering, there is a perfectly good DTNRG that is still alive. No shortage of work. Really good to factor it between the two groups. If the WG has small number of things, that would be a WG scope and IRTF does the rest? Don’t understand what is the fate of the DTNRG. Marc: Had discussion already. Seems to be clear designation is research stuff goes to DTNRG and standards track goes to IETF WG. So we should make sure they do not overlap. Jeff Hanson: Carnegie Melon SW engineering institute. Express support for standards track here. We have a research project here developing SSA tool for first-responders and they found lots of trouble in the field trying to get this. Started a new project to apply DTN to solve problems we are having with that. DARPA is interested in that application. Published standards would be helpful. Marc: For support, also mention topics to work on. Stephen Farrell: As an IESG member, would like to hear if people are willing to actually do work. As DTNRG co-chair, I think if an IETF WG is formed, DTNRG will go dormant. Not a good or bad thing, I don’t see both working together, not enough people in this community. Marc: Understand the number of people. But fact that there is some research things. Stephen Farrell: Just reality, not enough effort. There is DTN research outside of DTNRG. DTNRG itself working as an IRTF WG would have air sucked out by this. Not saying that is a bad thing. For BOF, I think we are looking at the wrong target. May try again on the list to talk about this. If the work as planned on the IETF WG, and if there is enough people to do work, I would support it. I would support the charter if there is enough people willing to do the work. Andrew Sullivan: On IAB and do reports on IESG about BOFs. To follow Stephen, there been rumors that DTNRG is proceeding actively. Certain amount of lack of movement there. A little worried that there could be lots of interest, but people not doing the work. Given potential disagreement on whether BP is right architecture. Lots of people interested in doing this, but what opinions, would reflect in what I saw to IESG. Fred: Boeing has 4 projects that we need to have DTN built to practicality (standards track documents). Tim: Colleagues doing research in this area. From the work they are doing deploying V6 areas, taken 5050, tweaked it minorly, certainly be advantages for something compatible to other things. Very keen to contribute to a 5050bis. Colleagues asked that I come to BOF and express support in person. (Did not catch name): Danger this will suck energy out of WG, but if it does, then it does. Ths injects energy into the research group. (agreed to point). Don’t worry to much about DTNRG will look like afterwards. Key question: what can be put on standards track now. Stephen Farrell: Disagree with Andrew: no disagreement with architecture in RFC4838. 5050 is different case. Question is whether minimal change to 5050, or go back and look at another design of a protocol with those same features, but easier to interoperate with internet protocols using MIME as the payload. Disagreement is flavors of protocol design, so less serious from an architectural point of view. Marc: Ignore standard process questions for now, what is desirable is that vendors building DTN solutions, it would be great if gap list would be addressed somehow. To get a better tool set to build solutions. Could be further work in DTNRG for new protocol builds. Want DTN to evolve as technology. Anon: Q: Nothing here about is there a need that multiple implementations are working together, for example, military could e a closed shop. Do you have a multi-vendor environment where you need a std to ensure interoperability. Fred: Both Boeing and Airbus have said they need these technologies as standards. Scott Burleigh: NASA right now operates multiple ION nodes on Space an DTN2 nodes on the ground. It has been a deliberate design decision to ensure continuing operability of those implementations. Stephen Farrell: Done work on ION/DTN2 interop. IT worked, but a bit of a pain. New deployments would prefer IBR-DTN now, so for different platform types, reasons to want different implementations. Even prior to competing commercial vendors. Jorg: Comment by company “We need this in the next 2 years”. Would caution expectations on how long it takes to get something done, like an industry consortium. Fred: When we talk about standards track, we are not talking about published RFCs. Jorg: W/o published RFCs, no guarantee of what will and will not change. So we have lots of hassle because people are jumping ahead. Companies risk to ship something based on drafts before RFCs, so be aware. If that is a concern, safer to implement based on RFC from DTNRG rather than draft from an IETF WG. John D: Parallel in MANET with protocol called DLEP - 6 organizations developing it, and pushing ahead quickly. Lots of industry guys asking us to finish this because we want to implement it. Just a question, if everyone is more or less on the same page. Marc: Summary. Good interest for an RFC5050bis being on standard track. So industry could do solutions. Current charter seems to go large in terms of work items. Maybe we can cut down some of these work items based on needs of people who want to work on this. ======================== By-hands voting: ======================== - ~Half of room read charter - ~Half read 5050bis - ~Half who understood technical issues. - Very few did not understand technical issues. - From charter: 4-6 believe it is scoped right. - 3 think it is not scoped right. - Who would write I-Ds: 6-7. Stephen Farrell: Question is more of the energy level. Personally think this is not the technical right direction, but it is reasonable, and if enough willing to work on it, the charter does not need fixing. Wrap-up discussion on charter. There are people and organizations willing to support by writing I-Ds in targeted areas. General consensus that the charter should be reviewed again to make it initially simpler.