Subject: [dtn] DTN Management Drafts

From: Jéferson Campos Nobre <[email-masked]>
Date: Fri, 20 Jun 2014 21:15:09 -0300

Hi.
With network management as an item of the DTN BoF, I think we should
pay attention to the DTN management drafts.To my knowledge, all drafts
are expired now.
The requirements drafts (draft-ivancic-dtnrg-network-management and
draft-clark-dtnrg-netman-req) are expired for a long time, but I think
they can be important to define what to expect of network management
features in a possible DTNWG.
Concerning protocol ones (draft-irtf-dtnrg-dtnmp and
draft-irtf-dtnrg-ding-network-management), only DTNMP has received
attention recently, although I believe DING was mentioned in the last
discussions (not sure if here or in the dtn-interest list).
Returning to the DTN BoF: since we have these draft they could/should
appear in the problem statement and solutions items?
Cheers.

Jéferson Campos Nobre
PhD Student
Computer Networks Group -  Institute of Informatics
Federal University of Rio Grande do Sul
http://www.inf.ufrgs.br/~jcnobre

---

From: "Birrane, Edward J." <[email-masked]>
Date: Fri, 20 Jun 2014 21:36:11 -0400

Hello,

  I wrote up DTNMP and provided an initial (though not feature complete) reference implementation in ION. Yes, the DTNMP spec from September has expired as an internet-draft, but the spec is under active development (I am hoping to have a new version ready before the BOF). There is funded work to continue DTNMP development and associated standards and plans for its operational deployment.  

  I think that management is a requirement for operational deployment and agree that it should be part of the charter.

-Ed

________________________________________
From: dtn [[email-masked]] On Behalf Of Jéferson Campos Nobre [[email-masked]]
Sent: Friday, June 20, 2014 8:15 PM
To: [email-masked]
Subject: [dtn] DTN Management Drafts

Hi.

Jéferson Campos Nobre
PhD Student

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

---

From: Jéferson Campos Nobre <[email-masked]>
Date: Sat, 21 Jun 2014 16:20:25 -0300

Hi Ed.
Great news about DTNMP.
It would be good to see the DTNMP draft and a revamped DTN management
requirements in the charter.
Best.

Jéferson Campos Nobre
PhD Student

On Fri, Jun 20, 2014 at 10:36 PM, Birrane, Edward J.

---

From: Gilbert Clark <[email-masked]>
Date: Sun, 22 Jun 2014 17:00:32 -0400

+1 that management is a requirement for operational deployment.

With that said, I do also wonder if the inclusion of specific use-cases 
should be a requirement for including the development of any *specific 
network management protocol* as a part of this charter.  Network 
management is going to necessarily involve discussing / deciding on a 
number of trade-offs that will impact not only the network conditions 
the protocol is best equipped to support, but also the hardware 
requirements necessary to support running the new protocol stack in the 
first place.  Without context for such a conversation, I don't believe 
there will often be a good way to argue that a specific decision is 
either right *or* wrong.

For what it's worth,
Gilbert Clark

---

From: "Burleigh, Scott C (312G)" <[email-masked]>
Date: Mon, 23 Jun 2014 14:48:56 +0000

Gilbert, can you say a little more about the kinds of trade-offs you're thinking of, and how decisions on those trade-offs would affect the design of a network management protocol?  What are some examples?

Scott

-----Original Message-----
From: dtn [mailto:[email-masked]] On Behalf Of Gilbert Clark
Sent: Sunday, June 22, 2014 2:01 PM
To: [email-masked]
Subject: Re: [dtn] DTN Management Drafts

With that said, I do also wonder if the inclusion of specific use-cases should be a requirement for including the development of any *specific network management protocol* as a part of this charter.  Network management is going to necessarily involve discussing / deciding on a number of trade-offs that will impact not only the network conditions the protocol is best equipped to support, but also the hardware requirements necessary to support running the new protocol stack in the first place.  Without context for such a conversation, I don't believe there will often be a good way to argue that a specific decision is either right *or* wrong.

For what it's worth,
Gilbert Clark

On 6/21/14, 3:20 PM, Jéferson Campos Nobre wrote:
> Computer Networks Group -  Institute of Informatics Federal University 
> of Rio Grande do Sul http://www.inf.ufrgs.br/~jcnobre
>
>> pay attention to the DTN management drafts.To my knowledge, all 
>> drafts are expired now.
>> draft-clark-dtnrg-netman-req) are expired for a long time, but I 
>> think they can be important to define what to expect of network 
>> management features in a possible DTNWG.
>> Computer Networks Group -  Institute of Informatics Federal 
>> University of Rio Grande do Sul http://www.inf.ufrgs.br/~jcnobre

---

From: Gilbert Clark <[email-masked]>
Date: Tue, 24 Jun 2014 02:17:54 -0400

Hi Scott:

No guarantees on coherence / intelligent discourse here, but a few 
thoughts ...

* What's an acceptable level of overhead (both on the node and on the 
network) for a DTN network management protocol?  Reducing node overhead 
might involve building a simpler protocol, deploying less sophisticated 
self-management capabilities, and / or giving the node better hardware.  
Reducing network overhead might involve sending fewer updates, sending 
less accurate updates (e.g. aggregate statistics instead of individual 
updates), or giving the node better hardware to support doing more 
elaborate things with the data (e.g. better compression).

* Situational optimizations are usually going to require making 
assumptions.  For example, if we know a device is going to continually 
be sending updates in a relatively fixed format, then it makes sense to 
find ways to cut metadata from the transmissions because said metadata 
is going to be redundant information.  More generally, the less we 
*know* about the managed devices and / or the managed networks, the more 
information we'll be forced to encode / send across the wire.  Also, the 
less we *know* about the managed devices and their capabilities, the 
more complex the resulting protocol is (probably) going to become.

* Link characteristics are going to influence the kind of data the 
protocol can record and send.  For example:

With high delay, high capacity, and high reliability, the links become 
pretty effective storage buffers of their own: 8 minutes of delay (= 480 
seconds) * 1 Mbps with no loss => the link is effectively a buffer / 
storage device for up to 480 million bits of information.  This kind of 
link is probably going to work pretty well for streaming (possibly 
incremental) updates, but is also going to demand open-loop design / 
larger degrees of automation on the nodes due to the RTT involved.

On the other hand, networks with links that are less predictable but 
with lower latency are going to require more flexibility with regard to 
both the type and quantity of data that is sent ... but maybe network 
links would flash into / out of existence often enough that there's a 
reasonable chance that a command will make it to a remote node in a 
reasonable amount of time.  For these cases, maybe it would make sense 
to look at adapting a more MANET-like NM protocol to work with DTN.

* Including some kind of support for existing infrastructure (e.g. 
support for IPFIX, SNMP, etc) into a DTN NM protocol might be a 
consideration.  It could be that the WG would want to design a DTN NM 
protocol in a way such that it'd be marginally less efficient / 
effective for DTN operation, but would also have a more straightforward 
interaction with existing NM protocols.  Offering the capability to 
re-use existing NM infrastructure for DTN monitoring and / or management 
might (or might not) be an attractive option for some.

Maybe I'm missing something here and the above is way off-base and / or 
already completely obvious to everyone, but ... I do still believe that 
the more specifically we can define the goals for a network management 
protocol, the better the protocol is going to eventually turn out :)

-Gilbert

---

From: "Burleigh, Scott C (312G)" <[email-masked]>
Date: Tue, 24 Jun 2014 15:25:24 +0000

Thanks, Gilbert, this is very helpful.

Scott

-----Original Message-----
From: dtn [mailto:[email-masked]] On Behalf Of Gilbert Clark
Sent: Monday, June 23, 2014 11:18 PM
To: [email-masked]
Subject: Re: [dtn] DTN Management Drafts

Hi Scott:

No guarantees on coherence / intelligent discourse here, but a few thoughts ...

* What's an acceptable level of overhead (both on the node and on the
network) for a DTN network management protocol?  Reducing node overhead might involve building a simpler protocol, deploying less sophisticated self-management capabilities, and / or giving the node better hardware.  
Reducing network overhead might involve sending fewer updates, sending less accurate updates (e.g. aggregate statistics instead of individual updates), or giving the node better hardware to support doing more elaborate things with the data (e.g. better compression).

* Situational optimizations are usually going to require making assumptions.  For example, if we know a device is going to continually be sending updates in a relatively fixed format, then it makes sense to find ways to cut metadata from the transmissions because said metadata is going to be redundant information.  More generally, the less we
*know* about the managed devices and / or the managed networks, the more information we'll be forced to encode / send across the wire.  Also, the less we *know* about the managed devices and their capabilities, the more complex the resulting protocol is (probably) going to become.

* Link characteristics are going to influence the kind of data the protocol can record and send.  For example:

With high delay, high capacity, and high reliability, the links become pretty effective storage buffers of their own: 8 minutes of delay (= 480
seconds) * 1 Mbps with no loss => the link is effectively a buffer / storage device for up to 480 million bits of information.  This kind of link is probably going to work pretty well for streaming (possibly
incremental) updates, but is also going to demand open-loop design / larger degrees of automation on the nodes due to the RTT involved.

On the other hand, networks with links that are less predictable but with lower latency are going to require more flexibility with regard to both the type and quantity of data that is sent ... but maybe network links would flash into / out of existence often enough that there's a reasonable chance that a command will make it to a remote node in a reasonable amount of time.  For these cases, maybe it would make sense to look at adapting a more MANET-like NM protocol to work with DTN.

* Including some kind of support for existing infrastructure (e.g. 
support for IPFIX, SNMP, etc) into a DTN NM protocol might be a consideration.  It could be that the WG would want to design a DTN NM protocol in a way such that it'd be marginally less efficient / effective for DTN operation, but would also have a more straightforward interaction with existing NM protocols.  Offering the capability to re-use existing NM infrastructure for DTN monitoring and / or management might (or might not) be an attractive option for some.

Maybe I'm missing something here and the above is way off-base and / or already completely obvious to everyone, but ... I do still believe that the more specifically we can define the goals for a network management protocol, the better the protocol is going to eventually turn out :)

-Gilbert

On 6/23/14, 10:48 AM, Burleigh, Scott C (312G) wrote:
>>> attention recently, although I believe DING was mentioned in the 
>>> last discussions (not sure if here or in the dtn-interest list).
>>> Returning to the DTN BoF: since we have these draft they 
>>> could/should appear in the problem statement and solutions items?
>>> Cheers.
>>>
>>> Jéferson Campos Nobre
>>> PhD Student