Subject: [dtn-interest] Thanks/Slides/Minutes ...

From: Stephen Farrell <[email-masked]>
Date: Sat, 28 Jul 2012 05:34:19 +0100

Hi all,

Many thanks to Google for hosting what I think was a
very successful two days of DTN. Special thanks to
Carla for all her wonderful help in getting the many
arrangements sorted so smoothly and professionally.
And also to Vint and the other Googlers (with or
without special glasses!) for their excellent input
over the two days.

I've put up all the slides I have on the web page [1]
and the raw-minutes [2] are there too for those that want
to check for any bad errors. We'll try produce a tidied
up version in the next few days, so let us know if there're
any errors there that need correcting.

Thanks,
S.

[1] http://down.dsg.cs.tcd.ie/dtnrg-at-google-12/
[2] http://down.dsg.cs.tcd.ie/dtnrg-at-google-12/raw-mins.txt

---

From: "Fall, Kevin" <[email-masked]>
Date: Sat, 28 Jul 2012 04:42:47 +0000

Yes, I would like to echo that.
Thanks again for everything... And for the years of support!

regards,
=-K

On 7/27/12 9:34 PM PDT, "Stephen Farrell" <[email-masked]>
wrote:

>_______________________________________________
>dtn-interest mailing list
>[email-masked]
>https://www.irtf.org/mailman/listinfo/dtn-interest

---

From: Joerg Ott <[email-masked]>
Date: Sat, 28 Jul 2012 11:04:24 +0300

I'd like to join in that.  Thanks a lot!

Jörg

---

From: "laveen vikram sundararaj" <[email-masked]>
Date: 30 Jul 2012 14:11:52 -0000

Greetings!
Pls find enclosed link (http://youtu.be/IBFg4qXR3dc) to Youtube where I have uploaded a 28 minute video of Sergey's session at DTNRG 2012. I am sorry about the abrupt ending as my (still) camera ran out of memory.
Regards,
Laveen Sundararaj.

On Sat, 28 Jul 2012 10:04:41 +0530  wrote

Hi all,

over the two days.

Thanks,

S.

[email-masked]

---

From: "Ivancic, William D. (GRC-RHN0)" <[email-masked]>
Date: Mon, 30 Jul 2012 12:04:57 -0500

Thanks to those who took notes.  I feel I was able to get a pretty good understanding of what occurred at last weeks meeting.

Scott, from the meeting notes, could you clarify.

>From Alan Hylton's work and just getting off the phone with him.  If I understood correctly, ION required CBHE if using IPN naming (as of ION 2.5).  Is this still the case or can DTN-2 or IBR or some other DTN implementation use IPN naming and communicate with an ION implementation without using CBHE?

Also, from the meeting notes below, are you saying that CBHE could be used with dtn naming scheme or others that are not yet defined? I am a bit confused because RFC6260 implies (to me) that CBHE cannot be used with "dtn" naming scheme.

Thanks,

Will

KS: You could have things that interoperate with static routing.
SB: You could do it now with the IPN scheme.
KS: Yes, with the IPN scheme you could get interoperability.
SF: Is it entwined with CBHE?
SB: No. IPN is defined in the CBHE RFC but CBHE doesn't require IPN.

>From RFC6260:

2.1<http://tools.ietf.org/html/rfc6260#section-2.1>.  Constraints
   The only valid scheme name for BP EIDs identified to date is "dtn".
   Although no specification of valid SSP syntax for URIs composed
   within the "dtn" scheme has yet been formally defined, the syntax on
   which rough agreement has been reached in practice is unsuitable for
   CBHE's compression procedures.  For the purposes of CBHE, then, this
   document defines an additional URI scheme named "ipn".  As noted in
   Section 4<http://tools.ietf.org/html/rfc6260#section-4>, IANA has registered this new URI scheme.

---

From: "Burleigh, Scott C (313B)" <[email-masked]>
Date: Mon, 30 Jul 2012 17:17:30 +0000

Hi, Will.  No, actually, it's the other way around: CBHE requires IPN naming, because it depends on being able to parse explicit numerical node and service IDs out of the endpoint, but you can always use IPN-scheme endpoints whether you're using CBHE or not.  Either I misspoke in the meeting or else the note that was taken was inaccurate.  An IPN-scheme endpoint ID is just a URI, the same as a DTN-scheme endpoint ID, and you should be able to do globbing on that string in your routing table in just the same way.

Scott

From: Ivancic, William D. (GRC-RHN0) [mailto:[email-masked]]
Sent: Monday, July 30, 2012 10:05 AM
To: DTN interest; Burleigh, Scott C (313B)
Subject: Re: [dtn-interest] Thanks/Slides/Minutes ...

Thanks,

Will

---

From: Paulo Mendes <[email-masked]>
Date: Tue, 31 Jul 2012 17:50:01 +0100

Hi Stephen and all

I would like to leave here a set of comments about the discussion around the topic of the future of routing in DTNRG:

a) About the proposal to have dLife as a RG draft: comments seem to have been positive ("its reasonable"), but I didn't find any conclusion on this matter. Can you clarify what would be the evolution on this track? As Stephen mentioned in the meeting, in the 2009 meeting at Google, people realized that it would be good to "get some other DTN routing schemes documented in I-D form, since otherwise we might be giving an impression that PRoPHET is the only way to do DTN routing." We started to work on this line of though and we have now a new sped in I-D form.

b) About the routing framework: It is also my opinion that we do not need a large set of protocols. As I mentioned before the meeting, it is my opinion that we should have a generic routing framework with a well defined interface to plug in specific methods of doing routing, which should be selected based on their applicability and proven performance results.

c) Emphasize multicast: I agree that protocols should not flood the network. Protocols should be able to forward within certain limits. First I would like to mention that we do not need an explicit multicast-type of protocol to avoid network flooding. There are already opportunistic protocols (such as dLife) that do not flood the network. But if you way to make it explicit, the idea of flooding within groups is one way, that can be worked out in two different ways: i) explicit group joining, as happens with multicast; ii) explicit group creation has happens when you apply community detection algorithms.. Our work with dLife follows the second track, but we use implicit groups by analysis of user behavior, since group creation can take a long time. But dLife can also work with the explicit creation of communities (that we call dLifeComm - in IEEE AOC 2012). So currently dLife forwards to a specific destinations, being aware of similarities among nodes, but could also forward to group of nodes with similar behavior. However, if we progress in this track of forwarding to groups, we may end up concluding that it will be better to forward based on data interests and not on group of nodes.

Cheers
Paulo

> [2] http://down.dsg.cs.tcd.ie/dtnrg-at-google-12/raw-mins.txt

-------------------------------------------------------------
Paulo Mendes, Ph.D
Scientific Director for Innovation of the Research Unit in Informatics Systems and Technologies (SITI)
Secretary of the ACM SIGCOMM Chapter - Portugal
University Lusofona, Portugal
[email-masked]
http://siti.ulusofona.pt/~pmendes
Tel.: 217 515 500 Fax: 21 757 7006