[Mep-dev] Something to take a look at for a possible adaptation for Mep...?

[Timothy J. Salo]

Michelle wrote:
> I think that enabling the building up to DTN from a working IP would be 
> an entirely reasonable way to proceed. My limited understanding is that 
> DTN comes into play at the transport and application layer, and 
> therefore doesn't really compete with or replace IP.

The current protocol specifications for the DTN protocols are
available at:

https://datatracker.ietf.org/idtracker/?search_group_acronym=&search_job_owner=0&search_rfcnumber=&search_status_id=&sub_state_id=6&search_cur_state=&search_button=SEARCH&search_filename=dtnrg&search_area_acronym=

> I know that there is some interest in investigating DTN within the team. 
> I think that it is safe to say that we would like to not do anything to 
> prevent experimentation and exploration of protocols like DTN.

Two convergence layers are being defined, which transport DTN bundles
over TCP and over UDP.  As such, one could use any IP network to
transport the DTN bundle protocol.  In these cases, the DTN
protocols are invisible to a pure IP network.  I have suggested
that the MEP (and the ACP) be a pure IP network.

> DTN would be applicable to MEP data that could tolerate or 
> will experience delay. Here are some examples that occur to me. I 
> could distribute pre-recorded video files via DTN, as opposed 
> to interactive or streaming video streams, which would be delivered over 
> IP. Or, DTN could deliver video QSL cards, or files destined for the 
> virtual tables in the chat rooms. Voice would be over IP (interactive, 
> QSOs) or could be over DTN (voice mail, voice messages).

I haven't seen an authoritative description of the MEP, but
I assume that it will support, at most, the following
configurations:

1)    IP           MEP         MEP           MEP         IP
     device ------ node ----- repeater ----- node ----- device

2)    IP           MEP         MEP           MEP         IP
     network ----- node ----- repeater ----- node ----- network

3)    IP           MEP        MEP         IP
     device ------ node ----- node ----- device

4)    IP           MEP        MEP         IP
     network ----- node ----- node ----- network

It seems to me that delay-tolerant functionality is only
applicable in configurations 1 and 2.

An easy solution would be to simply run a Web server on the
MEP repeater.  I do _not_ recommend doing this, but I do suggest
that using HTTP rather than the DTN protocols would result in
a much shorter time-to-working-prototype.

> I believe that all of this could be accomplished quite handily and with 
> less Big Idea Trouble (in other words, less work) with existing QoS 
> (quality of service) schemes, but DTN is hip and cool and people want to 
> learn about it, and it costs us nothing except some advance cluefulness 
> to enable it.

I am all for people learning about networks and protocols.  I would
also like to see the MEP project deliver a working prototype before
the developers get distracted by other things.  Hence, my suggestions
to place strict boundaries on the project.

> Is there anyone would like to advocate for DTN being a requirement for 
> MEP? A bit of devil's advocacy, perhaps? Is there any great advantage to 
> DTN over IP with QoS? Perhaps the experience of implementation is 
> compelling enough to warrant exploring the idea?

If people are interested in DTN, I suggest that they join the
DTN e-mail lists.  There is at least one reference implementation
available.

-tjs