Subject: [dtn] DTN WG Virtual Meeting - Thursday December 5, 2014 (fixed the links )

From: "Ivancic, William D. (GRC-LCA0)" <[email-masked]>
Date: Fri, 5 Dec 2014 17:20:25 +0000

Please let me know if I got something wrong.

Sorry if I misspelled any names.

==============================
DTN  Meeting December 5, 2014
 
Notes by Will Ivancic

Marc - Agenda and Goals
Get consensus on what to work on.

Reviewing google documents
https://docs.google.com/document/d/1RVwIUVIoJbZDCqIaZX5SICZN06kVjx42VzH82_r
m3JI/edit

Will -  terminate  bundles stuck in routing loops and hop-by-hop
integrity for the header and end-to-end integrity for the bundle if the
bundles
are large.
 
Conesus that these need to be worked.

Marc, where should these topics reside?

Discussion of header.

Created INTEGRITY task for  header
integrity, header immutability.

Discussion of primary block vs header blocks.

Elwynd indicated that extension blocks get quite complicated
 particularly if you have meta-data blocks, order of blocks.

???Need something to indicate what headers are there???

Marc  we think we need to work some type of addressing, but
scope may be to large. Need to determine the scope of the work.

Fred  volunteered to work on use cases that correspond to
Addressing

Marc  what does the industry need with regard to
addressing?

Fred  what about zero/one indicating aggregated vs flat
address space.

Will  mult-homed, mobile systems are hard.  Adding disconnection is
harder. Adding
propagation delay adds additional complication.

Neighbor discovery:

Elwynd  is discovery, discovering your neighbors or
discovering what you neighbors are capable of?

Marc  first just discovering you neighbors.

Keith  should neighbor discovery be part of the core
bundling protocol or an application that uses the neighbor discovery?

Simple Routing:  

From Group  what does it mean?
 
F
red  manet has routing protocol separate from neighbor
Discovery

Elwynd  manet may not be a good example.  One that uses 2 hop discovery
is good work,
but only by one (or a few) manet routing protocols.

Elwynd  recommend that discovery is separate from routing.

Scott Burleigh  agrees with Elwynd.

Marc  summary and consensus is to work some type of
neighbor discovery.

Fred  a modular neighbor discovery will enable hooks with
routing protocols.

Dynamic routing: 
Consensus is to not include as work item at this time.  Too big and one
size does not fit all.

Simple Routing: 
What is it?  Consensus appears to be Static Routing.

Keith Scott  simple forwarding table.  No discussion about how to
populate the
Table.

Network Management:

Scott Burleigh  needed, but to big for current charter.

Elwynd  is this just monitoring or monitoring and
configuration.

Brian  may be synergy with other working groups.  Some groups are working
layer independent
management models.  DTN may be able to
make their needs known.

Marc  would like to hear from industry as experience has shown
that network management is usually needed.

Jeremry Pierce Mayer  Network management is important even
for small networks.

Marc  is configuration or just monitoring.

Jeremy  to many open items such as addressing that need to
be discussed prior to configuration.
Concentrate on monitoring.

Scott Burleigh  really to large at this time.

Fred  can work on items that are not in charter?

Marc  individuals can submit individual submissions and
then working group can consider the draft as moved to WG item.

SECURITY:

Marc  improved security.

Scott Burleigh  needs to be done.

Brian  what are you discussing: integrity, confidentiality,
none repudiation?

Chuck Sheehe  what about creation/expiration time, how is
that treated?

Ed Barrine  allows layering of security.

Scott and Fred  strong support for simplified bundle
security.

Elwynd  what about key distribution.

Fred and Scott  both Boeing and JPL working on
implementations of key management.

Brian  there appears to be interest in working on
simplified security.

Elwynd  need to ensure that BP structure does not make
security break.

Will  Does security have to operate with reactive
Fragmentation?

Scott B. If reactive fragmentation is part of core bundle
protocol, then security my work with reactive fragmentation or whatever
else.

EXTENDED CLASS OF SERVICE:
Scott B and Keith Scott  Extended Class of Service should
be left for future work

Elwynd  forget ECOS, it doesn¹t work except perhaps for
close deployments.

MULTICAST:
 
Scott B  have some work, but propose until next iteration.

Elwynd  existing protocol has multi-node endpoints.

Will  ICN has multicast concepts that my be useful.

Ronald Velt  interested and relevant, but push to later.

STREAMING:

Scott B.  JPL has working solution for NASA.

DRL is working on this, but no need for standards track.

Keith Scott  does base protocol need something for
streaming?  

Answer, ECOS is mandatory for streaming to work, but nothing needed
in base protocol.

BUNDLE SIZE:

Will  large, small or what?  large bundles requires reactive
Fragmentation.

Keith  perhaps no need for reactive fragmentation.

Elwynd  restricting bundle size would be fundamental change
to architecture/protocol.

TIME:
 
Will  explained position and referenced wiki:
https://sites.google.com/site/dtnresgroup/home/dtn-bone

Scott B.  Work item but disagrees with Will on time

Elwynd  keep as work item.

Item 18  22:  Bugs, operation in constrained environments, default
operations, gateway for 5050.

Scott B.  all items should be considered.

Elwynd  do we really need to be gateway consideration.

REGISTRY OF SERVICE IDENTIFIER

Marc  Already a work item.

SUMMARY OF TOPICS TO WORK / EXCLUDE  See Google Docs document:
https://docs.google.com/document/d/1RVwIUVIoJbZDCqIaZX5SICZN06kVjx42VzH82_r
m3JI/edit

---

From: "Burleigh, Scott C (312B)" <[email-masked]>
Date: Fri, 5 Dec 2014 18:55:23 +0000

Thanks for capturing these notes, Will.  A couple of comments:

1.  I think Elwyn's point wasn't that the extension blocks can get complicated, but rather that BP provides no mechanism for determining whether or not the extension blocks in the delivered bundle are the same as the ones that were in the bundle when it was sourced.  We need something in the protocol that indicates which blocks (not headers) were originally present in the bundle.

2.  The answer to Brian's question about the scope of security was that it includes integrity, confidentiality, and authentication.  There wasn't any discussion of non-repudiability that I recall.

3.  I don't think Elwyn said "Forget ECOS" specifically, but rather "Forget about quality of service" in general.

4.  Keith responded to the question about whether or not we needed to keep gatewaying to BPv6 (RFC 5050) in mind, saying that this was important for NASA because operational deployment was already under way.

Scott

-----Original Message-----
From: dtn [mailto:[email-masked]] On Behalf Of Ivancic, William D. (GRC-LCA0)
Sent: Friday, December 5, 2014 9:20 AM
To: [email-masked]
Subject: [dtn] DTN WG Virtual Meeting - Thursday December 5, 2014 (fixed the links )

 
Notes by Will Ivancic

Marc - Agenda and Goals

Will -  terminate  bundles stuck in routing loops and hop-by-hop integrity for the header and end-to-end integrity for the bundle if the bundles are large.

Discussion of header.

Elwynd indicated that extension blocks get quite complicated  particularly if you have meta-data blocks, order of blocks.

Marc  we think we need to work some type of addressing, but scope may be to large. Need to determine the scope of the work.

Fred  volunteered to work on use cases that correspond to Addressing

Marc  what does the industry need with regard to addressing?

Fred  what about zero/one indicating aggregated vs flat address space.

Will  mult-homed, mobile systems are hard.  Adding disconnection is harder. Adding propagation delay adds additional complication.

Neighbor discovery:

Elwynd  is discovery, discovering your neighbors or discovering what you neighbors are capable of?

Keith  should neighbor discovery be part of the core bundling protocol or an application that uses the neighbor discovery?

>From Group  what does it mean?
 
F
red  manet has routing protocol separate from neighbor Discovery

Elwynd  manet may not be a good example.  One that uses 2 hop discovery is good work, but only by one (or a few) manet routing protocols.

Marc  summary and consensus is to work some type of neighbor discovery.

Fred  a modular neighbor discovery will enable hooks with routing protocols.

Dynamic routing: 
Consensus is to not include as work item at this time.  Too big and one size does not fit all.

Simple Routing: 

Keith Scott  simple forwarding table.  No discussion about how to populate the Table.

Network Management:

Elwynd  is this just monitoring or monitoring and configuration.

Brian  may be synergy with other working groups.  Some groups are working layer independent management models.  DTN may be able to make their needs known.

Marc  would like to hear from industry as experience has shown that network management is usually needed.

Jeremry Pierce Mayer  Network management is important even for small networks.

Jeremy  to many open items such as addressing that need to be discussed prior to configuration.
Concentrate on monitoring.

Marc  individuals can submit individual submissions and then working group can consider the draft as moved to WG item.

SECURITY:

Marc  improved security.

Brian  what are you discussing: integrity, confidentiality, none repudiation?

Chuck Sheehe  what about creation/expiration time, how is that treated?

Scott and Fred  strong support for simplified bundle security.

Fred and Scott  both Boeing and JPL working on implementations of key management.

Brian  there appears to be interest in working on simplified security.

Elwynd  need to ensure that BP structure does not make security break.

Will  Does security have to operate with reactive Fragmentation?

Scott B. If reactive fragmentation is part of core bundle protocol, then security my work with reactive fragmentation or whatever else.

EXTENDED CLASS OF SERVICE:
Scott B and Keith Scott  Extended Class of Service should be left for future work

Elwynd  forget ECOS, it doesn¹t work except perhaps for close deployments.

MULTICAST:

STREAMING:

Keith Scott  does base protocol need something for streaming?  

Answer, ECOS is mandatory for streaming to work, but nothing needed in base protocol.

BUNDLE SIZE:

Will  large, small or what?  large bundles requires reactive Fragmentation.

Elwynd  restricting bundle size would be fundamental change to architecture/protocol.

TIME:

 

Item 18  22:  Bugs, operation in constrained environments, default operations, gateway for 5050.

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

---

From: Amy Alford <[email-masked]>
Date: Fri, 5 Dec 2014 14:21:38 -0500

I agree that you summarized Elwyn's point more accurately, but I think
there was some larger discussion about the complexity of extension blocks.

I'm not entirely sure I understand Elwyn's point.  If the destination
requires a BSP block which provides integrity protection to the whole
bundle, then it knows that the bundle can't have changed in transit.  This
could be required for every bundle as part of the spec, but I'm not sure
what the advantage is.

Aside from that, I concur that the current generality of extension blocks
leads to enormous complexity.  I'm pretty sure no implementation has
tackled the question of reassembling extension blocks during fragment
reassembly.  If those features are both useful, then the interaction needs
lots of fleshing out.
- Amy

On Fri, Dec 5, 2014 at 1:55 PM, Burleigh, Scott C (312B) <
[email-masked]> wrote:

> 1.  I think Elwyn's point wasn't that the extension blocks can get
> complicated, but rather that BP provides no mechanism for determining
> whether or not the extension blocks in the delivered bundle are the same as
> the ones that were in the bundle when it was sourced.  We need something in
> the protocol that indicates which blocks (not headers) were originally
> present in the bundle.
>
> 2.  The answer to Brian's question about the scope of security was that it
> includes integrity, confidentiality, and authentication.  There wasn't any
> discussion of non-repudiability that I recall.
>
> 3.  I don't think Elwyn said "Forget ECOS" specifically, but rather
> "Forget about quality of service" in general.
>
> 4.  Keith responded to the question about whether or not we needed to keep
> gatewaying to BPv6 (RFC 5050) in mind, saying that this was important for
> NASA because operational deployment was already under way.
>
> Scott
>
> Will -  terminate  bundles stuck in routing loops and hop-by-hop integrity
> for the header and end-to-end integrity for the bundle if the bundles are
> large.
>
> Marc  we think we need to work some type of addressing, but scope may be
> to large. Need to determine the scope of the work.
>
>
> harder. Adding propagation delay adds additional complication.
>
>
>
> Neighbor discovery:
>
>
> Keith  should neighbor discovery be part of the core bundling protocol or
> an application that uses the neighbor discovery?
>
>
>
> Simple Routing:
>
>
> is good work, but only by one (or a few) manet routing protocols.
>
>
> populate the Table.
> layer independent management models.  DTN may be able to make their needs
> known.
>
>
> Marc  individuals can submit individual submissions and then working
> group can consider the draft as moved to WG item.
>
>
>
> SECURITY:
>
>
> Marc  improved security.
>
>
> Scott B. If reactive fragmentation is part of core bundle protocol, then
> security my work with reactive fragmentation or whatever else.
>
>

---

From: "Burleigh, Scott C (312B)" <[email-masked]>
Date: Fri, 5 Dec 2014 20:14:24 +0000

Amy, you may well be right that there was a general discussion about the complexity of extension blocks; I don’t remember it, but I may just have been distracted.

I think Elwyn’s point is that a given bundle may start life with attached extension blocks D, E, F, and G but arrive with blocks D, F, and H, and the destination bundle protocol agent has no way of knowing that E and G were deleted – and H was added – by intermediate forwarding nodes.  I’m not yet clear, myself, on what implication this may have on the application or on the operation of the network, but in any case I’m willing to see it as an end-to-end integrity issue.

We actually don’t have any BSP block that provides end-to-end integrity protection to the whole bundle, since the BAB is only hop-by-hop.  We could do this with Bundle-in-Bundle Encapsulation if we wanted, by forwarding the original bundle as the payload of an encapsulating bundle and attaching a BIB (or formerly PIB) for that payload.  But I suspect that doesn’t go to the problem Elwyn is talking about.

Extension blocks don’t technically need to be “reassembled” during fragment reassembly, since only the payload is actually fragmented, but I think I know what you mean: the rules for deciding which extension blocks to forward with which fragments are not necessarily as well thought through as they might be.  I believe ION and (I think) DTN2 and IBR-DTN and other BP implementations actually do already perform conformant bundle reassembly including attachment of the forwarded extension blocks.  This could certainly be made simpler, though.

My concern is that the extension block mechanism has proven extremely valuable, not only for blue-sky research but also for operational use that requires capabilities that go beyond the core protocol functions.  While simplicity is wonderful, I would hate to see genuinely useful capability sacrificed to achieve it.  I would like to see us just be thoughtful and inventive in the way the protocol is designed.  (And in particular I would like to see development of an alternative to reactive fragmentation, which I believe is the cradle of most of the infelicities in fragmentation/reassembly that we wrestle with.)

Scott

From: Amy Alford [mailto:[email-masked]]
Sent: Friday, December 5, 2014 11:22 AM
To: Burleigh, Scott C (312B)
Cc: Ivancic, William D. (GRC-LCA0); [email-masked]
Subject: Re: [dtn] DTN WG Virtual Meeting - Thursday December 5, 2014 (fixed the links )

I agree that you summarized Elwyn's point more accurately, but I think there was some larger discussion about the complexity of extension blocks.

I'm not entirely sure I understand Elwyn's point.  If the destination requires a BSP block which provides integrity protection to the whole bundle, then it knows that the bundle can't have changed in transit.  This could be required for every bundle as part of the spec, but I'm not sure what the advantage is.

Aside from that, I concur that the current generality of extension blocks leads to enormous complexity.  I'm pretty sure no implementation has tackled the question of reassembling extension blocks during fragment reassembly.  If those features are both useful, then the interaction needs lots of fleshing out.
- Amy

On Fri, Dec 5, 2014 at 1:55 PM, Burleigh, Scott C (312B) <[email-masked]<mailto:[email-masked]>> wrote:
Thanks for capturing these notes, Will.  A couple of comments:

Scott

-----Original Message-----
From: dtn [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Ivancic, William D. (GRC-LCA0)
Sent: Friday, December 5, 2014 9:20 AM
To: [email-masked]<mailto:[email-masked]>
Subject: [dtn] DTN WG Virtual Meeting - Thursday December 5, 2014 (fixed the links )

Notes by Will Ivancic

Marc - Agenda and Goals

Discussion of header.

Neighbor discovery:

F

Dynamic routing:

Simple Routing:

Network Management:

SECURITY:

Marc  improved security.

MULTICAST:

STREAMING:

BUNDLE SIZE:

TIME:

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

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

---

From: "Will Ivancic" <[email-masked]>
Date: Fri, 5 Dec 2014 21:27:08 -0500

I think you are correct regarding Item 1.

Also correct regarding Item 2.  I had a brain cramp and couldn't come up
with the word "Authentication"  but I could come up with non-repudiation.
Go figure.  They are similar but not exactly the same.  

3.  I don't think Elwyn said "Forget ECOS" specifically, but rather "Forget
about quality of service" in general.

Agree again.

Yes, I believe that is what Keith said.  

IMHO,,there is not nearly enough deployment to worry about and deploying a
protocol that has no integrity check on headers with SDNVs and can bet stuck
in routing loops is not good flight code - I believe JSC has experience this
in ground testing although they might not have realized the cause..  Also, I
would rather stick with one implementation that have to maintain a gateway -
particularly in a flight system.  But that is just my opinion. 

Will

---

From: Elwyn Davies <[email-masked]>
Date: Sat, 06 Dec 2014 14:59:41 +0000

> I think you are correct regarding Item 1.
     Yes.  There is no way to record what was in the original bundle or 
indeed to record where any extra blocks were added if they were.

Further (I believe) the BSP doesn't help with this sort of integrity 
because if the extension block and its associated security protection is 
all removed there is nothing to say it was ever there.

On the complexity front, recording the block pattern would probably also 
remove the bodge where one is obliged to have a non-empty payload block 
in every fragment. Recording the block list straight after the primary 
block and making the primary and the blocklist the only mandatory bits 
in any fragment would make processing easier.

Just to mention also that I would personally get rid of SDNVs.  The 
experiment has shown how long bit fields are likely to be.  I think 
length fields can be handled more easily by flags or TLV types to say 
how long the length field is.  Payload lengths couild be 1, 2, 4 or 16 
octets (or the last one reverting to SDNV if you insist) but frankly if 
the payload octet length is greater than will fit in 4 octets the 
overhead of an extra 12 octets isn't going to make a whole lot of 
difference.  Name lengths could be 1 or 2 octets.

And please, please, please let's scrap the dictionary.  It especially 
makes bundle building a nightmare even apart from the integrity problems.
> about quality of service" in general.
Yes.  I can see that in a closed system such as the space scenario 
having a priority system can help but for a general purpose common 
carrier use case trying to prioritize one user/applications bundles over 
another's is rapidly turned into an economics argument as to how much 
the priority costs and will anybody pay?  OTOH having a bit that says I 
am a 'control bundle' is potentially useful (c.f., routing data in the 
Internet) but only allowed to, be set by 'the system'.

I have seen too many Internet/Link layer schemes try to do  QoS and be 
trumped by economics in the end.

Regards,
Elwyn

---

From: Amy Alford <[email-masked]>
Date: Sat, 6 Dec 2014 13:08:07 -0500

Yes, I meant extension block combination during fragment reassembly.  5050
gives detailed rules for which extension blocks are included with which
fragment during fragmentation, but not which extension blocks are preserved
during reassembly of the fragments.  It doesn't work to reverse the rules
for what happens during fragmentation because extension blocks may have
been added, removed, or modified in the interim.  There is no way to handle
those situations that works for all extension block types.  I've played
with DTN2s implementation, which is buggy.  But, I can't believe any
implementation is doing it really well, which would require special
handling of the different extension block types.

Additionally, the order of defragmentation and BSP validation is a
problem.  Some BSP blocks attached to fragments should be processed before
defragmentation and some should be processed after.  Checks for policy need
to take all this into account.

If an example would help, I can write one out.

That's not an argument against extension blocks.  I'd like to see the
interaction with bundle in bundle encapsulation and fragmentation spelled
out more clearly.
- Amy

On Fri, Dec 5, 2014 at 3:14 PM, Burleigh, Scott C (312B) <
[email-masked]> wrote:

>  Amy, you may well be right that there was a general discussion about the
> complexity of extension blocks; I don’t remember it, but I may just have
> been distracted.
>
>
>
> I think Elwyn’s point is that a given bundle may start life with attached
> extension blocks D, E, F, and G but arrive with blocks D, F, and H, and the
> destination bundle protocol agent has no way of knowing that E and G were
> deleted – and H was added – by intermediate forwarding nodes.  I’m not yet
> clear, myself, on what implication this may have on the application or on
> the operation of the network, but in any case I’m willing to see it as an
> end-to-end integrity issue.
>
>
>
> We actually don’t have any BSP block that provides end-to-end integrity
> protection to the whole bundle, since the BAB is only hop-by-hop.  We could
> do this with Bundle-in-Bundle Encapsulation if we wanted, by forwarding the
> original bundle as the payload of an encapsulating bundle and attaching a
> BIB (or formerly PIB) for that payload.  But I suspect that doesn’t go to
> the problem Elwyn is talking about.
>
>
>
> Extension blocks don’t technically need to be “reassembled” during
> fragment reassembly, since only the payload is actually fragmented, but I
> think I know what you mean: the rules for deciding which extension blocks
> to forward with which fragments are not necessarily as well thought through
> as they might be.  I believe ION and (I think) DTN2 and IBR-DTN and other
> BP implementations actually do already perform conformant bundle reassembly
> including attachment of the forwarded extension blocks.  This could
> certainly be made simpler, though.
>
>
>
> My concern is that the extension block mechanism has proven extremely
> valuable, not only for blue-sky research but also for operational use that
> requires capabilities that go beyond the core protocol functions.  While
> simplicity is wonderful, I would hate to see genuinely useful capability
> sacrificed to achieve it.  I would like to see us just be thoughtful and
> inventive in the way the protocol is designed.  (And in particular I would
> like to see development of an alternative to reactive fragmentation, which
> I believe is the cradle of most of the infelicities in
> fragmentation/reassembly that we wrestle with.)
>
>
>
> Scott
>
>
>
> *From:* Amy Alford [mailto:[email-masked]]
> *Sent:* Friday, December 5, 2014 11:22 AM
> *To:* Burleigh, Scott C (312B)
> *Cc:* Ivancic, William D. (GRC-LCA0); [email-masked]
> *Subject:* Re: [dtn] DTN WG Virtual Meeting - Thursday December 5, 2014
> (fixed the links )
>
>
>
> <https://docs.google.com/document/d/1RVwIUVIoJbZDCqIaZX5SICZN06kVjx42VzH82_rm3JI/edit>
>
>
> <https://docs.google.com/document/d/1RVwIUVIoJbZDCqIaZX5SICZN06kVjx42VzH82_rm3JI/edit>
>
>
>
>

---

From: "Will Ivancic" <[email-masked]>
Date: Sun, 7 Dec 2014 09:53:05 -0500

Just to mention also that I would personally get rid of SDNVs.  The
experiment has shown how long bit fields are likely to be.  I think length
fields can be handled more easily by flags or TLV types to say how long the
length field is.  Payload lengths couild be 1, 2, 4 or 16 octets (or the
last one reverting to SDNV if you insist) but frankly if the payload octet
length is greater than will fit in 4 octets the overhead of an extra 12
octets isn't going to make a whole lot of difference.  Name lengths could be
1 or 2 octets.

	I believe there are many that would agree.  Can we hear from you?

And please, please, please let's scrap the dictionary.  It especially makes
bundle building a nightmare even apart from the integrity problems.

	Elwynd, can you elaborate on you use of the dictionary?  You are the
first one I heard state a desire to keep it.  Since you have 	written and
have a lot of experience with deploying DTN, I highly respect your input.

	Are there other code writers out there that desire to keep the
dictionary?

Will

---

From: "Burleigh, Scott C (312B)" <[email-masked]>
Date: Sun, 7 Dec 2014 16:19:14 +0000

Okay, good point; none of the testing I’ve done has required resolution of conflicts among extension blocks that have been modified en route, so simply attaching the union of all the delivered blocks has been okay for ION, but it’s not a general solution.

Ed’s SBSP draft prohibited attachment of confidentiality and integrity blocks to fragments, to head off exactly the problem you describe, and it recommended encapsulation as an alternative but without going into detail.  I agree, we really need to get this spelled out very clearly.

Scott

Sent: Saturday, December 06, 2014 10:08 AM

Yes, I meant extension block combination during fragment reassembly.  5050 gives detailed rules for which extension blocks are included with which fragment during fragmentation, but not which extension blocks are preserved during reassembly of the fragments.  It doesn't work to reverse the rules for what happens during fragmentation because extension blocks may have been added, removed, or modified in the interim.  There is no way to handle those situations that works for all extension block types.  I've played with DTN2s implementation, which is buggy.  But, I can't believe any implementation is doing it really well, which would require special handling of the different extension block types.

Additionally, the order of defragmentation and BSP validation is a problem.  Some BSP blocks attached to fragments should be processed before defragmentation and some should be processed after.  Checks for policy need to take all this into account.

That's not an argument against extension blocks.  I'd like to see the interaction with bundle in bundle encapsulation and fragmentation spelled out more clearly.
- Amy

On Fri, Dec 5, 2014 at 3:14 PM, Burleigh, Scott C (312B) <[email-masked]<mailto:[email-masked]>> wrote:
Amy, you may well be right that there was a general discussion about the complexity of extension blocks; I don’t remember it, but I may just have been distracted.

Scott

From: Amy Alford [mailto:[email-masked]<mailto:[email-masked]>]
Sent: Friday, December 5, 2014 11:22 AM
To: Burleigh, Scott C (312B)
Cc: Ivancic, William D. (GRC-LCA0); [email-masked]<mailto:[email-masked]>
Subject: Re: [dtn] DTN WG Virtual Meeting - Thursday December 5, 2014 (fixed the links )

Scott

-----Original Message-----
From: dtn [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Ivancic, William D. (GRC-LCA0)
Sent: Friday, December 5, 2014 9:20 AM
To: [email-masked]<mailto:[email-masked]>
Subject: [dtn] DTN WG Virtual Meeting - Thursday December 5, 2014 (fixed the links )

Notes by Will Ivancic

Marc - Agenda and Goals

Discussion of header.

Neighbor discovery:

F

Dynamic routing:

Simple Routing:

Network Management:

SECURITY:

Marc  improved security.

MULTICAST:

STREAMING:

BUNDLE SIZE:

TIME:

---

From: "Burleigh, Scott C (312B)" <[email-masked]>
Date: Sun, 7 Dec 2014 16:31:53 +0000

The original SDNV concept, way back in the early days of the LTP design, was that the first byte of a numeric field would normally indicate the length of the field.  The indicated number of subsequent bytes would normally contain the field's value, but there was also an option to instead place a very small value inside the first byte itself.

We switched from that concept to one that was derived from ASN.1 because it seemed more extensible and better aligned with the direction being taken by IETF.  I personally find SDNVs very easy to work with, requiring about 35 lines of C code to implement.  But I wouldn't argue too hard against a change to a different design that was no less efficient and powerful.

Will, I think you may have misread Elwyn's second point.  He said let's "scrap" the dictionary, not keep it.

Scott

-----Original Message-----
From: Will Ivancic [mailto:[email-masked]] 
Sent: Sunday, December 07, 2014 6:53 AM
To: 'Elwyn Davies'; Burleigh, Scott C (312B); 'Ivancic, William D. (GRC-LCA0)'; [email-masked]
Subject: RE: [dtn] DTN WG Virtual Meeting - Thursday December 5, 2014 (fixed the links )

Just to mention also that I would personally get rid of SDNVs.  The experiment has shown how long bit fields are likely to be.  I think length fields can be handled more easily by flags or TLV types to say how long the length field is.  Payload lengths couild be 1, 2, 4 or 16 octets (or the last one reverting to SDNV if you insist) but frankly if the payload octet length is greater than will fit in 4 octets the overhead of an extra 12 octets isn't going to make a whole lot of difference.  Name lengths could be
1 or 2 octets.

And please, please, please let's scrap the dictionary.  It especially makes bundle building a nightmare even apart from the integrity problems.

	Are there other code writers out there that desire to keep the dictionary?

Will

---

From: "Ivancic, William D. (GRC-LCA0)" <[email-masked]>
Date: Mon, 8 Dec 2014 13:25:46 +0000

>"scrap" the dictionary, not keep it.

I'm fine with scrapping the dictionary if it is not being used by anyone
who is highly attached to the concept.  I have yet to find that someone.
I certainly must have misread Elwyn.

Will

---

From: Elwyn Davies <[email-masked]>
Date: Mon, 08 Dec 2014 18:08:49 +0000

> We switched from that concept to one that was derived from ASN.1 because it seemed more extensible and better aligned with the direction being taken by IETF.  I personally find SDNVs very easy to w…
I agree SDNVs don't take much code to implement but they still probably 
run several 10s of times slower than using what is effectively a built 
in processor type (at least for one kind of processor).  I can just 
about justify it for the payload length but using SDNVs  for bit flag 
fields has proven somewhat difficult to specify and much more costly for 
accessing and rebuilding the fields since we now know how big they ought 
to be, even allowing for some additional expansion.  Using SDNVs for 
less variable length fields is clearly not so clear cut a decision.
> Will, I think you may have misread Elwyn's second point.  He said let's "scrap" the dictionary, not keep it.
Sorry - is this a case of two countries divided by the same language? 
"scrap" => junk, get rid off, cause to turn up its toes, eliminate with 
extreme prejudice. Please! :-)

Cheers,
Elwyn

---

From: Amy Alford <[email-masked]>
Date: Mon, 8 Dec 2014 15:28:06 -0500

At the STINT workshop of SMC-IT, there was some discussion that SDNVs are
hard to implement in hardware.  I'm going to butcher this discussion,
because I know nothing about either speeding up code with hardware support
or satellites.  Someone was experimenting with optical links on a
satellite.  They were having trouble saturating the links in experiments.
They wanted to offload computation to dedicated hardware, but SDNV and the
generally variable layout of DTN bundles makes that difficult.  I'm hoping
someone who knows about this jumps in here.
- Amy

On Mon, Dec 8, 2014 at 1:08 PM, Elwyn Davies <[email-masked]> wrote:

>> The original SDNV concept, way back in the early days of the LTP design,
>> was that the first byte of a numeric field would normally indicate the
>> length of the field.  The indicated number of subsequent bytes would
>> normally contain the field's value, but there was also an option to instead
>> place a very small value inside the first byte itself.
>>
>> We switched from that concept to one that was derived from ASN.1 because
>> it seemed more extensible and better aligned with the direction being taken
>> by IETF.  I personally find SDNVs very easy to work with, requiring about
>> 35 lines of C code to implement.  But I wouldn't argue too hard against a
>> change to a different design that was no less efficient and powerful.
>>
> run several 10s of times slower than using what is effectively a built in
> processor type (at least for one kind of processor).  I can just about
> justify it for the payload length but using SDNVs  for bit flag fields has
> proven somewhat difficult to specify and much more costly for accessing and
> rebuilding the fields since we now know how big they ought to be, even
> allowing for some additional expansion.  Using SDNVs for less variable
> length fields is clearly not so clear cut a decision.
>
>>

---

From: "Ivancic, William D. (GRC-LCA0)" <[email-masked]>
Date: Mon, 8 Dec 2014 20:38:19 +0000

Amy,

I asked the question, "Do we need to consider speed and hardware implementation?" because of a know desire to operate at Gigabit speeds and offload as much of the processing as possible into hardware.  SDNVs and I suspect extension blocks will make this rather difficult – regardless of the memory read/write speeds.  On of my colleagues was working some of this, but he is now away at graduate school.  Perhaps in two weeks, he will have some time to comment.

I think JPL had someone looking at putting DTN into an FPGA a few years ago as well.  I don't know the details or issues they ran across.

Will

From: Amy Alford <[email-masked]<mailto:[email-masked]>>
Date: Monday, December 8, 2014 3:28 PM
To: Elwyn Davies <[email-masked]<mailto:[email-masked]>>
Cc: "Burleigh, Scott C (JPL-312B)[Jet Propulsion Laboratory]" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [dtn] DTN WG Virtual Meeting - Thursday December 5, 2014 (fixed the links )

At the STINT workshop of SMC-IT, there was some discussion that SDNVs are hard to implement in hardware.  I'm going to butcher this discussion, because I know nothing about either speeding up code with hardware support or satellites.  Someone was experimenting with optical links on a satellite.  They were having trouble saturating the links in experiments.  They wanted to offload computation to dedicated hardware, but SDNV and the generally variable layout of DTN bundles makes that difficult.  I'm hoping someone who knows about this jumps in here.
- Amy

On Mon, Dec 8, 2014 at 1:08 PM, Elwyn Davies <[email-masked]<mailto:[email-masked]>> wrote:
On 07/12/14 16:31, Burleigh, Scott C (312B) wrote:
The original SDNV concept, way back in the early days of the LTP design, was that the first byte of a numeric field would normally indicate the length of the field.  The indicated number of subsequent bytes would normally contain the field's value, but there was also an option to instead place a very small value inside the first byte itself.

We switched from that concept to one that was derived from ASN.1 because it seemed more extensible and better aligned with the direction being taken by IETF.  I personally find SDNVs very easy to work with, requiring about 35 lines of C code to implement.  But I wouldn't argue too hard against a change to a different design that was no less efficient and powerful.
I agree SDNVs don't take much code to implement but they still probably run several 10s of times slower than using what is effectively a built in processor type (at least for one kind of processor).  I can just about justify it for the payload length but using SDNVs  for bit flag fields has proven somewhat difficult to specify and much more costly for accessing and rebuilding the fields since we now know how big they ought to be, even allowing for some additional expansion.  Using SDNVs for less variable length fields is clearly not so clear cut a decision.

Will, I think you may have misread Elwyn's second point.  He said let's "scrap" the dictionary, not keep it.
Sorry - is this a case of two countries divided by the same language? "scrap" => junk, get rid off, cause to turn up its toes, eliminate with extreme prejudice. Please! :-)

Cheers,
Elwyn

Scott

-----Original Message-----
From: Will Ivancic [mailto:[email-masked]<mailto:[email-masked]>]
Sent: Sunday, December 07, 2014 6:53 AM
To: 'Elwyn Davies'; Burleigh, Scott C (312B); 'Ivancic, William D. (GRC-LCA0)'; [email-masked]<mailto:[email-masked]>
Subject: RE: [dtn] DTN WG Virtual Meeting - Thursday December 5, 2014 (fixed the links )

Will

---

From: "Burleigh, Scott C (312B)" <[email-masked]>
Date: Mon, 8 Dec 2014 21:05:04 +0000

My suspicion is that the most egregious element of "the generally variable layout of DTN bundles" is the dictionary.  I agree that fixing the size of bit fields at this point seems reasonable.  And I don't know anything about hardware, so if somebody who does know hardware says that SDNVs are hard to implement then I'll listen.  But other aspects of the variable nature of bundles don't seem unusually hardware-hostile to me; IPv6 has extension headers, right?

Scott

From: dtn [mailto:[email-masked]] On Behalf Of Ivancic, William D. (GRC-LCA0)
Sent: Monday, December 8, 2014 12:38 PM
To: Amy Alford; Elwyn Davies
Cc: Hylton, Alan G. (GRC-LCA0); Burleigh, Scott C (312B); [email-masked]
Subject: Re: [dtn] DTN WG Virtual Meeting - Thursday December 5, 2014 (fixed the links )

Amy,

I asked the question, "Do we need to consider speed and hardware implementation?" because of a know desire to operate at Gigabit speeds and offload as much of the processing as possible into hardware.  SDNVs and I suspect extension blocks will make this rather difficult - regardless of the memory read/write speeds.  On of my colleagues was working some of this, but he is now away at graduate school.  Perhaps in two weeks, he will have some time to comment.

Will

Cheers,
Elwyn

Scott

-----Original Message-----
From: Will Ivancic [mailto:[email-masked]<mailto:[email-masked]>]
Sent: Sunday, December 07, 2014 6:53 AM
To: 'Elwyn Davies'; Burleigh, Scott C (312B); 'Ivancic, William D. (GRC-LCA0)'; [email-masked]<mailto:[email-masked]>
Subject: RE: [dtn] DTN WG Virtual Meeting - Thursday December 5, 2014 (fixed the links )

Will

---

From: Marc Blanchet <[email-masked]>
Date: Mon, 8 Dec 2014 16:06:56 -0500

> Le 2014-12-08 à 15:38, Ivancic, William D. (GRC-LCA0) <[email-masked]> a écrit :
> 
> Amy,
> 

- for fast forwarding, one need things that can be processed in fixed blocks so they can be mapped in memory. So anything of variable lengths, of unspecified number of fields prior to parse them, is causing headaches to hardware designers.  However, this is only for forwarding decisions. IPv6 has shown with variable extension headers that people want to do more than just forwarding, such as looking in the « payload » , such as transport data or application protocol data, …  and with variable length headers it becomes a big problem.  
- simple and fixed length fields, least amount of variable headers and fields are much better for hardware.

Marc.

> From: Amy Alford <[email-masked] <mailto:[email-masked]>>
> To: Elwyn Davies <[email-masked] <mailto:[email-masked]>>
> Cc: "Burleigh, Scott C (JPL-312B)[Jet Propulsion Laboratory]" <[email-masked] <mailto:[email-masked]>>, "[email-masked] <mailto:[email-masked]>" <[email-masked] <mailto:[email-masked]>>
> On Mon, Dec 8, 2014 at 1:08 PM, Elwyn Davies <[email-masked] <mailto:[email-masked]>> wrote:
>>> From: Will Ivancic [mailto:[email-masked] <mailto:[email-masked]>]
>>> To: 'Elwyn Davies'; Burleigh, Scott C (312B); 'Ivancic, William D. (GRC-LCA0)'; [email-masked] <mailto:[email-masked]>
>>> [email-masked] <mailto:[email-masked]>
>>> https://www.ietf.org/mailman/listinfo/dtn <https://www.ietf.org/mailman/listinfo/dtn>
>> 
>> [email-masked] <mailto:[email-masked]>
>> https://www.ietf.org/mailman/listinfo/dtn <https://www.ietf.org/mailman/listinfo/dtn>
>

---

From: Marc Blanchet <[email-masked]>
Date: Mon, 8 Dec 2014 16:08:04 -0500

> Le 2014-12-08 à 16:05, Burleigh, Scott C (312B) <[email-masked]> a écrit :
> 
> My suspicion is that the most egregious element of “the generally variable layout of DTN bundles” is the dictionary.  I agree that fixing the size of bit fields at this point seems reasonable.  And I don’t know anything about hardware, so if somebody who does know hardware says that SDNVs are hard to implement then I’ll listen.  But other aspects of the variable nature of bundles don’t seem unusually hardware-hostile to me; IPv6 has extension headers, right?

see my just previous email…  

IPv6 extension headers have been always identified as a big issue for hardware designers.

Marc.

>  
> Scott
>   <>
> From: dtn [mailto:[email-masked] <mailto:[email-masked]>] On Behalf Of Ivancic, William D. (GRC-LCA0)
> Cc: Hylton, Alan G. (GRC-LCA0); Burleigh, Scott C (312B); [email-masked] <mailto:[email-masked]>

---

From: "Templin, Fred L" <[email-masked]>
Date: Mon, 8 Dec 2014 21:19:52 +0000

Hi Marc,

Extension headers are certainly a core component of the IPv6 architecture, but some
networks apparently drop packets with extension headers presumably for the reason
you mention. As a result, there seems to be a growing movement to deprecate aspects
of the IPv6 architecture that present problems to the network and some people have
been lumping extension headers into this category.

That said, not all networks are created equal such that some networks would run
perfectly fine with extension headers and hosts would see benefits in using them.
So, I think a movement that says: “extension headers are bad in certain use cases,
so we must deprecate them everywhere” is short-sighted. So, maybe the same
logic applies here. At least that’s my $.02.

Thanks – Fred
[email-masked]

From: dtn [mailto:[email-masked]] On Behalf Of Marc Blanchet
Sent: Monday, December 08, 2014 1:08 PM
To: Scott Burleigh
Cc: Hylton, Alan G. (GRC-LCA0); Amy Alford; Elwyn Davies; [email-masked]; William Ivancic
Subject: Re: [dtn] DTN WG Virtual Meeting - Thursday December 5, 2014 (fixed the links )

Le 2014-12-08 à 16:05, Burleigh, Scott C (312B) <[email-masked]<mailto:[email-masked]>> a écrit :

Marc.

Scott

Cc: Hylton, Alan G. (GRC-LCA0); Burleigh, Scott C (312B); [email-masked]<mailto:[email-masked]>

Amy,

Will

Cheers,
Elwyn

Scott

-----Original Message-----
From: Will Ivancic [mailto:[email-masked]<mailto:[email-masked]>]
Sent: Sunday, December 07, 2014 6:53 AM
To: 'Elwyn Davies'; Burleigh, Scott C (312B); 'Ivancic, William D. (GRC-LCA0)'; [email-masked]<mailto:[email-masked]>
Subject: RE: [dtn] DTN WG Virtual Meeting - Thursday December 5, 2014 (fixed the links )

Will

---

From: "Burleigh, Scott C (312B)" <[email-masked]>
Date: Mon, 8 Dec 2014 21:34:08 +0000

So my understanding is that Cisco routers will inspect incoming packets and switch them from the “hardware” forwarding path to the “software” path (which is much slower) if their main headers indicate that they will be complex to process.  Maybe we should have that sort of model in mind.  If we can fix the structure and maximum size of a “simple” bundle and somehow indicate that simplicity in the primary block, then perhaps we can continue to provide lots of optional flexibility and simply warn users that taking advantage of those options will impose a cost.  Let the users decide.

Possibly pushing this concept too hard, we might even think up 7 (or 15) canonical bundle structures that hardware implementers could design for, so that forwarding would need to be switched over to the “software path” only in some especially exotic use cases.

Scott

From: Templin, Fred L [mailto:[email-masked]]
Sent: Monday, December 8, 2014 1:20 PM
To: Marc Blanchet; Burleigh, Scott C (312B)
Cc: Hylton, Alan G. (GRC-LCA0); Amy Alford; Elwyn Davies; [email-masked]; William Ivancic
Subject: RE: [dtn] DTN WG Virtual Meeting - Thursday December 5, 2014 (fixed the links )

Hi Marc,

Thanks – Fred
[email-masked]<mailto:[email-masked]>

From: dtn [mailto:[email-masked]] On Behalf Of Marc Blanchet
Sent: Monday, December 08, 2014 1:08 PM
To: Scott Burleigh
Cc: Hylton, Alan G. (GRC-LCA0); Amy Alford; Elwyn Davies; [email-masked]<mailto:[email-masked]>; William Ivancic
Subject: Re: [dtn] DTN WG Virtual Meeting - Thursday December 5, 2014 (fixed the links )

Marc.

Scott

Amy,

Will

Cheers,
Elwyn

Scott

-----Original Message-----
From: Will Ivancic [mailto:[email-masked]<mailto:[email-masked]>]
Sent: Sunday, December 07, 2014 6:53 AM
To: 'Elwyn Davies'; Burleigh, Scott C (312B); 'Ivancic, William D. (GRC-LCA0)'; [email-masked]<mailto:[email-masked]>
Subject: RE: [dtn] DTN WG Virtual Meeting - Thursday December 5, 2014 (fixed the links )

Will

---

From: "Templin, Fred L" <[email-masked]>
Date: Mon, 8 Dec 2014 21:40:30 +0000

I agree with you Scott, and I think the ability to accommodate diversity will be important.
Based on the diversity of use cases I am seeing, I can’t imagine a “one size fits all” as
being the best in all cases.

Thanks – Fred

From: Burleigh, Scott C (312B) [mailto:[email-masked]]
Sent: Monday, December 08, 2014 1:34 PM
To: Templin, Fred L; Marc Blanchet
Cc: Hylton, Alan G. (GRC-LCA0); Amy Alford; Elwyn Davies; [email-masked]; William Ivancic
Subject: RE: [dtn] DTN WG Virtual Meeting - Thursday December 5, 2014 (fixed the links )

Scott

Hi Marc,

Thanks – Fred

Marc.

Scott

Amy,

Will

Cheers,
Elwyn

Scott

-----Original Message-----
From: Will Ivancic [mailto:[email-masked]<mailto:[email-masked]>]
Sent: Sunday, December 07, 2014 6:53 AM
To: 'Elwyn Davies'; Burleigh, Scott C (312B); 'Ivancic, William D. (GRC-LCA0)'; [email-masked]<mailto:[email-masked]>
Subject: RE: [dtn] DTN WG Virtual Meeting - Thursday December 5, 2014 (fixed the links )

Will

---

From: Marc Blanchet <[email-masked]>
Date: Mon, 8 Dec 2014 18:34:37 -0500

> Le 2014-12-08 à 16:19, Templin, Fred L <[email-masked]> a écrit :
> 
> Hi Marc,
>  
> so we must deprecate them everywhere” is short-sighted.

this is not what I wrote. I wrote that extension headers is an example which makes hardware design much more difficult. One of the reason IPv6 extensions headers are dropped is that it is difficult to implement in hardware, therefore, it is the processed by software by the main cpu and then may easily kill the router. So instead, dropping is « safer ».

I’m not justifying anything. I’m just stating reality I know (I worked for some hardware companies…).  

Marc.

> So, maybe the same
> [email-masked] <mailto:[email-masked]>
>  
> From: dtn [mailto:[email-masked] <mailto:[email-masked]>] On Behalf Of Marc Blanchet
> Cc: Hylton, Alan G. (GRC-LCA0); Amy Alford; Elwyn Davies; [email-masked] <mailto:[email-masked]>; William Ivancic
> Le 2014-12-08 à 16:05, Burleigh, Scott C (312B) <[email-masked] <mailto:[email-masked]>> a écrit :
>

---

From: Marc Blanchet <[email-masked]>
Date: Mon, 8 Dec 2014 18:35:52 -0500

> Le 2014-12-08 à 16:34, Burleigh, Scott C (312B) <[email-masked]> a écrit :
> 
> So my understanding is that Cisco routers will inspect incoming packets and switch them from the “hardware” forwarding path to the “software” path (which is much slower) if their main headers indicate that they will be complex to process. 

exactly. see my previous response.

> Maybe we should have that sort of model in mind.

yes.

Marc.

>   If we can fix the structure and maximum size of a “simple” bundle and somehow indicate that simplicity in the primary block, then perhaps we can continue to provide lots of optional flexibility and simply warn users that taking advantage of those options will impose a cost.  Let the users decide.
>  
> From: Templin, Fred L [mailto:[email-masked] <mailto:[email-masked]>]

---

From: "Templin, Fred L" <[email-masked]>
Date: Mon, 8 Dec 2014 23:56:06 +0000

>So instead, dropping is « safer ».

“Safer” – do you mean, “safer *in some environments*”? I’m not even very fond
of a statement like that – extension headers are  core part of the IPv6 architecture,
and routers that can’t pass them are broken. Or, at least, if I want to run with
extension headers *in my network* I should be allowed to do so.

That said, I think we are vectoring off on a tangent…

Thanks – Fred

From: Marc Blanchet [mailto:[email-masked]]
Sent: Monday, December 08, 2014 3:35 PM
To: Templin, Fred L
Cc: Scott Burleigh; Hylton, Alan G. (GRC-LCA0); Amy Alford; Elwyn Davies; [email-masked]; William Ivancic
Subject: Re: [dtn] DTN WG Virtual Meeting - Thursday December 5, 2014 (fixed the links )

Le 2014-12-08 à 16:19, Templin, Fred L <[email-masked]<mailto:[email-masked]>> a écrit :

Hi Marc,

Marc.

So, maybe the same

Thanks – Fred

Marc.

Scott

Amy,

Will

Cheers,
Elwyn

Scott

-----Original Message-----
From: Will Ivancic [mailto:[email-masked]<mailto:[email-masked]>]
Sent: Sunday, December 07, 2014 6:53 AM
To: 'Elwyn Davies'; Burleigh, Scott C (312B); 'Ivancic, William D. (GRC-LCA0)'; [email-masked]<mailto:[email-masked]>
Subject: RE: [dtn] DTN WG Virtual Meeting - Thursday December 5, 2014 (fixed the links )

Will

---

From: Marc Blanchet <[email-masked]>
Date: Mon, 8 Dec 2014 18:59:17 -0500

> Le 2014-12-08 à 18:56, Templin, Fred L <[email-masked]> a écrit :
> 

safer in the sense that some operators prefer dropping those packets instead of risking their router to be significantly affected. There are known attack vectors on this.

> That said, I think we are vectoring off on a tangent…

right, but the main point remains: fixed and least number of variable fields is the best way to get it implemented in hardware. 

Marc.

> From: Marc Blanchet [mailto:[email-masked] <mailto:[email-masked]>] 
> Cc: Scott Burleigh; Hylton, Alan G. (GRC-LCA0); Amy Alford; Elwyn Davies; [email-masked] <mailto:[email-masked]>; William Ivancic
> Le 2014-12-08 à 16:19, Templin, Fred L <[email-masked] <mailto:[email-masked]>> a écrit :
>  
> Hi Marc,
>

---

From: Eric Travis <[email-masked]>
Date: Mon, 8 Dec 2014 21:28:46 -0500

On Mon, Dec 8, 2014 at 3:38 PM, Ivancic, William D. (GRC-LCA0) <
[email-masked]> wrote:

>  Amy,
>
>  I asked the question, "Do we need to consider speed and hardware
> implementation?" because of a know desire to operate at Gigabit speeds and
> offload as much of the processing as possible into hardware.  SDNVs and I
> suspect extension blocks will make this rather difficult – regardless of
> the memory read/write speeds.  On of my colleagues was working some of
> this, but he is now away at graduate school.  Perhaps in two weeks, he will
> have some time to comment.
>
>  I think JPL had someone looking at putting DTN into an FPGA a few years
> ago as well.  I don't know the details or issues they ran across.
>
>  Will
>
>
Will,

Surely you've been around long enough to remember when there was angst
regarding whether TCP implementations
would ever be able to saturate a 10Mbps LAN?

The issue is less the aggregate data rate than the number of bundles per
second to be processed.  Small bundles are
as bad as small datagrams (probably worse).

               Make everything as simple as possible, but not simpler.  -
Albert Einstein

Excess complexity should *always* be avoided.  (Allowing for) Extension
headers add some degree of
complexity, but the added flexibility they provide outweighs the generic
costs (in my opinion).  Extensions (options?)
allow the protocol to evolve in a backwards compatible fashion, and avoids
having to baseline a kitchen sink
for a core protocol.    As RFC-5050 goes from experimental entity toward a
standards-track entity, the *way*
extension headers are constructed/handled certainly should be reevaluated.
The same is true with all aspects
of the candidate protocol, as the stakes are higher (Standard >>
Experiment).

My (otherwise premature) concerns about Gigabit speed operations of a DTN
would be related to buffer
sizing/management and the lack of node coordination and congestion handling
(a expiration time is at best
a fallback crutch).  <Fear Mongering> Bundlebloat looms </Fear Mongering>.

Regarding SDVN, almost everything in a bundle header being of variable
length and therefore encoded seems
*to me* as adding unnecessary complexity.

Has anyone done an engineering tradeoff regarding the value of mostly SDVN
versus fixed length fields + TLVs where
necessary?  How about versus fixed length fields + SDVNs where necessary?
Just judicious use of SDVNs
versus TLVs?  SDVNs likely win on storage/bandwidth, but is that sufficient?

Variable length fields - and therefore - SDVNs certainly can provide some
future-proofing and reduction in
bandwidth overhead.  Playing with them in an experimental domain was
appropriate - have the potential
benefits been determined in a quantifiable manner? In a subjective manner?

Simpler is always better - except when it isn't... Is SDVN one of those
exceptions?

Eric

---

From: Wesley Eddy <[email-masked]>
Date: Mon, 08 Dec 2014 21:44:21 -0500

On 12/8/2014 4:05 PM, Burleigh, Scott C (312B) wrote:
> My suspicion is that the most egregious element of “the generally
> variable layout of DTN bundles” is the dictionary.  I agree that fixing
> the size of bit fields at this point seems reasonable.  And I don’t know
> anything about hardware, so if somebody who does know hardware says that
> SDNVs are hard to implement then I’ll listen.  But other aspects of the
> variable nature of bundles don’t seem unusually hardware-hostile to me;
> IPv6 has extension headers, right?
> 

I fully agree, and think some of this discussion is premature
optimization.  There are ways to parallelize and pipeline the
processing functionalities if necessary.  It's true that it
takes a little more creativity with variable length fields and
packings, but it's not the end of the world and there's no
reason that it can't be done on high rate links.

Making concessions for doing high rates with out a lot of gates
seems like it would impact flexibility and bit efficiency for
the really low rate links that we should not ignore.

-- 
Wes Eddy
MTI Systems

---

From: Elwyn Davies <[email-masked]>
Date: Tue, 09 Dec 2014 19:06:00 +0000

Yes, the "fast path" in all hardware assisted routers today (typically 
with network processors and often with very fast - and expensive - CAM 
memory to do longest prefix address lookup) will dump anything that is 
not a plain vanilla IP packet to the slow path through the control 
processor using software mechanisms.

If you are going to worry about fast path compatibility, you first have 
to think about how addresses might be processed.  It is not clear that 
late binding and fast path processing will be compatible, but that is 
another question for the addressing box. Maybe the reduced size 
numerical node IDs proposed for the space use case would be OK.

On the subject of IPv6 extension headers: Yes, they can be defined BUT 
the IETF will no longer allow you to standardise hop-by-hop headers that 
were intended to be processed in each router on the path for exactly the 
reason that started this thread: the fast path has to recognize any 
combination of hop-by-hop headers and do whatever is "the right thing" 
according to that header.  In general routers are not software 
upgradeable to do arbitrary things that a hop-by-hop header might want 
and there is every chance that a subset of the routers on the path of 
your packet with the brand new hop-by-hop header would not recognize the 
new header because their software is old and at best it will get dumped 
to slow path and more likely get dropped because the router can't 
understand it.

However, given all this, I am not sure why we are particularly worried 
about hardware assisted processing.  DTN is store-carry-forward so, 
especially in sparse networks, most bundle processing is not direct 
input line to output line low latency queue.  Most bundles will be line 
to internal storage or internal storage to output line queue according 
to what contact(s) are in progress.  Also in a good percentage of cases 
there is only one or a very few output lines active at any one time.  
Bundles travelling across the well-connected Internet will a.s. be 
wrapped up in IP packets anyway as they are today unless we are 
intending to have a native bundle transport in the Internet .

Regards,
Elwyn

On 08/12/14 21:34, Burleigh, Scott C (312B) wrote:
>
> So my understanding is that Cisco routers will inspect incoming 
> packets and switch them from the “hardware” forwarding path to the 
> “software” path (which is much slower) if their main headers indicate 
> that they will be complex to process. Maybe we should have that sort 
> of model in mind.  If we can fix the structure and maximum size of a 
> “simple” bundle and somehow indicate that simplicity in the primary 
> block, then perhaps we can continue to provide lots of optional 
> flexibility and simply warn users that taking advantage of those 
> options will impose a cost.  Let the users decide.
>
> Possibly pushing this concept too hard, we might even think up 7 (or 
> 15) canonical bundle structures that hardware implementers could 
> design for, so that forwarding would need to be switched over to the 
> “software path” only in some especially exotic use cases.
>
> Scott
>
> *From:*Templin, Fred L [mailto:[email-masked]]
> *Sent:* Monday, December 8, 2014 1:20 PM
> *To:* Marc Blanchet; Burleigh, Scott C (312B)
> *Cc:* Hylton, Alan G. (GRC-LCA0); Amy Alford; Elwyn Davies; 
> [email-masked]; William Ivancic
> *Subject:* RE: [dtn] DTN WG Virtual Meeting - Thursday December 5, 
> 2014 (fixed the links )
>
> Hi Marc,
>
> *From:*dtn [mailto:[email-masked]] *On Behalf Of *Marc Blanchet
> *Sent:* Monday, December 08, 2014 1:08 PM
> *To:* Scott Burleigh
> *Cc:* Hylton, Alan G. (GRC-LCA0); Amy Alford; Elwyn Davies; 
> [email-masked] <mailto:[email-masked]>; William Ivancic
> *Subject:* Re: [dtn] DTN WG Virtual Meeting - Thursday December 5, 
> 2014 (fixed the links )
>
>     Le 2014-12-08 à 16:05, Burleigh, Scott C (312B)
>     <[email-masked]
>     <mailto:[email-masked]>> a écrit :
>
>     variable layout of DTN bundles” is the dictionary.  I agree that
>     fixing the size of bit fields at this point seems reasonable.  And
>     I don’t know anything about hardware, so if somebody who does know
>     hardware says that SDNVs are hard to implement then I’ll listen. 
>     But other aspects of the variable nature of bundles don’t seem
>     unusually hardware-hostile to me; IPv6 has extension headers, right?
>
>     *From:*dtn [mailto:[email-masked]]*On Behalf Of*Ivancic,
>     William D. (GRC-LCA0)
>     *Sent:*Monday, December 8, 2014 12:38 PM
>     *To:*Amy Alford; Elwyn Davies
>     *Cc:*Hylton, Alan G. (GRC-LCA0); Burleigh, Scott C
>     (312B);[email-masked] <mailto:[email-masked]>
>     *Subject:*Re: [dtn] DTN WG Virtual Meeting - Thursday December 5,
>     2014 (fixed the links )
>
>     Amy,
>
>     implementation?" because of a know desire to operate at Gigabit
>     speeds and offload as much of the processing as possible into
>     hardware.  SDNVs and I suspect extension blocks will make this
>     rather difficult – regardless of the memory read/write speeds.  On
>     of my colleagues was working some of this, but he is now away at
>     graduate school.  Perhaps in two weeks, he will have some time to
>     comment.
>
>     I think JPL had someone looking at putting DTN into an FPGA a few
>     years ago as well.  I don't know the details or issues they ran
>     across.
>
>     Will
>
>     *From:*Amy Alford <[email-masked] <mailto:[email-masked]>>
>     *Date:*Monday, December 8, 2014 3:28 PM
>     *To:*Elwyn Davies <[email-masked] <mailto:[email-masked]>>
>     *Cc:*"Burleigh, Scott C (JPL-312B)[Jet Propulsion Laboratory]"
>     <[email-masked]
>     <mailto:[email-masked]>>, "[email-masked]
>     <mailto:[email-masked]>" <[email-masked] <mailto:[email-masked]>>
>     *Subject:*Re: [dtn] DTN WG Virtual Meeting - Thursday December 5,
>     2014 (fixed the links )
>
>     At the STINT workshop of SMC-IT, there was some discussion that
>     SDNVs are hard to implement in hardware.  I'm going to butcher
>     this discussion, because I know nothing about either speeding up
>     code with hardware support or satellites.  Someone was
>     experimenting with optical links on a satellite.  They were having
>     trouble saturating the links in experiments.  They wanted to
>     offload computation to dedicated hardware, but SDNV and the
>     generally variable layout of DTN bundles makes that difficult. 
>     I'm hoping someone who knows about this jumps in here.
>
>     - Amy
>
>             The original SDNV concept, way back in the early days of
>             the LTP design, was that the first byte of a numeric field
>             would normally indicate the length of the field.  The
>             indicated number of subsequent bytes would normally
>             contain the field's value, but there was also an option to
>             instead place a very small value inside the first byte itself.
>
>             We switched from that concept to one that was derived from
>             ASN.1 because it seemed more extensible and better aligned
>             with the direction being taken by IETF.  I personally find
>             SDNVs very easy to work with, requiring about 35 lines of
>             C code to implement.  But I wouldn't argue too hard
>             against a change to a different design that was no less
>             efficient and powerful.
>
>         I agree SDNVs don't take much code to implement but they still
>         probably run several 10s of times slower than using what is
>         effectively a built in processor type (at least for one kind
>         of processor).  I can just about justify it for the payload
>         length but using SDNVs for bit flag fields has proven somewhat
>         difficult to specify and much more costly for accessing and
>         rebuilding the fields since we now know how big they ought to
>         be, even allowing for some additional expansion.  Using SDNVs
>         for less variable length fields is clearly not so clear cut a
>         decision.
>
>
>             Will, I think you may have misread Elwyn's second point. 
>             He said let's "scrap" the dictionary, not keep it.
>
>         Sorry - is this a case of two countries divided by the same
>         language? "scrap" => junk, get rid off, cause to turn up its
>         toes, eliminate with extreme prejudice. Please! :-)
>
>         Cheers,
>         Elwyn
>
>
>             Scott
>
>             To: 'Elwyn Davies'; Burleigh, Scott C (312B); 'Ivancic,
>             William D. (GRC-LCA0)';[email-masked] <mailto:[email-masked]>
>             Just to mention also that I would personally get rid of
>             SDNVs.  The experiment has shown how long bit fields are
>             likely to be.  I think length fields can be handled more
>             easily by flags or TLV types to say how long the length
>             field is. Payload lengths couild be 1, 2, 4 or 16 octets
>             (or the last one reverting to SDNV if you insist) but
>             frankly if the payload octet length is greater than will
>             fit in 4 octets the overhead of an extra 12 octets isn't
>             going to make a whole lot of difference.  Name lengths
>             could be
>             1 or 2 octets.
>
>             And please, please, please let's scrap the dictionary.  It
>             especially makes bundle building a nightmare even apart
>             from the integrity problems.
>

---

From: "Juan A. Fraire" <[email-masked]>
Date: Tue, 9 Dec 2014 16:33:25 -0300

Hi Elwyn,

It is true that in sparse DTNs can take advantage of late-processing as
forwarding is not necessarily instantaneous; however, there are cases where
this might be desired. This is true at least for our space agency project
where the satellite communications system is DTN but also need to support a
real-time multiple-hop networking scenario (Ground Station to Satellite 1
to Satellite 2).

Best regards,

J. Fraire

On Tue, Dec 9, 2014 at 4:06 PM, Elwyn Davies <[email-masked]> wrote:

> memory to do longest prefix address lookup) will dump anything that is not
> a plain vanilla IP packet to the slow path through the control processor
> using software mechanisms.
>
> If you are going to worry about fast path compatibility, you first have to
> think about how addresses might be processed.  It is not clear that late
> binding and fast path processing will be compatible, but that is another
> question for the addressing box.  Maybe the reduced size numerical node IDs
> proposed for the space use case would be OK.
>
> On the subject of IPv6 extension headers: Yes, they can be defined BUT the
> IETF will no longer allow you to standardise hop-by-hop headers that were
> intended to be processed in each router on the path for exactly the reason
> that started this thread: the fast path has to recognize any combination of
> hop-by-hop headers and do whatever is "the right thing" according to that
> header.  In general routers are not software upgradeable to do arbitrary
> things that a hop-by-hop header might want and there is every chance that a
> subset of the routers on the path of your packet with the brand new
> hop-by-hop header would not recognize the new header because their software
> is old and at best it will get dumped to slow path and more likely get
> dropped because the router can't understand it.
>
> especially in sparse networks, most bundle processing is not direct input
> line to output line low latency queue.  Most bundles will be line to
> internal storage or internal storage to output line queue according to what
> contact(s) are in progress.  Also in a good percentage of cases there is
> only one or a very few output lines active at any one time.  Bundles
> travelling across the well-connected Internet will a.s. be wrapped up in IP
> packets anyway as they are today unless we are intending to have a native
> bundle transport in the Internet .
>
> Regards,
> Elwyn
>
>
>
>
>  So my understanding is that Cisco routers will inspect incoming packets
> and switch them from the “hardware” forwarding path to the “software” path
> (which is much slower) if their main headers indicate that they will be
> complex to process.  Maybe we should have that sort of model in mind.  If
> we can fix the structure and maximum size of a “simple” bundle and somehow
> indicate that simplicity in the primary block, then perhaps we can continue
> to provide lots of optional flexibility and simply warn users that taking
> advantage of those options will impose a cost.  Let the users decide.
>
>
>
> Possibly pushing this concept too hard, we might even think up 7 (or 15)
> canonical bundle structures that hardware implementers could design for, so
> that forwarding would need to be switched over to the “software path” only
> in some especially exotic use cases.
>
>
>
> Scott
>
>
>
> *From:* Templin, Fred L [mailto:[email-masked]
> <[email-masked]>]
> *Cc:* Hylton, Alan G. (GRC-LCA0); Amy Alford; Elwyn Davies; [email-masked];
> William Ivancic
> *Subject:* RE: [dtn] DTN WG Virtual Meeting - Thursday December 5, 2014
> (fixed the links )
>
>
>
> Hi Marc,
>
>
>
> *From:* dtn [mailto:[email-masked] <[email-masked]>] *On
> Behalf Of *Marc Blanchet
> *Cc:* Hylton, Alan G. (GRC-LCA0); Amy Alford; Elwyn Davies; [email-masked];
> William Ivancic
> My suspicion is that the most egregious element of “the generally variable
> layout of DTN bundles” is the dictionary.  I agree that fixing the size of
> bit fields at this point seems reasonable.  And I don’t know anything about
> hardware, so if somebody who does know hardware says that SDNVs are hard to
> implement then I’ll listen.  But other aspects of the variable nature of
> bundles don’t seem unusually hardware-hostile to me; IPv6 has extension
> headers, right?
>
>
>
> *From:* dtn [mailto:[email-masked] <[email-masked]>] *On
> Behalf Of *Ivancic, William D. (GRC-LCA0)
> *Sent:* Monday, December 8, 2014 12:38 PM
> *To:* Amy Alford; Elwyn Davies
> *Cc:* Hylton, Alan G. (GRC-LCA0); Burleigh, Scott C (312B); [email-masked]
> *From: *Amy Alford <[email-masked]>
> *Date: *Monday, December 8, 2014 3:28 PM
> *To: *Elwyn Davies <[email-masked]>
> *Cc: *"Burleigh, Scott C (JPL-312B)[Jet Propulsion Laboratory]" <
> [email-masked]>, "[email-masked]" <[email-masked]>
> *Subject: *Re: [dtn] DTN WG Virtual Meeting - Thursday December 5, 2014
> (fixed the links )
>
>
>

---

From: "Burleigh, Scott C (312B)" <[email-masked]>
Date: Wed, 10 Dec 2014 16:27:41 +0000

My understanding of the appeal of hardware assisted processing is that there is interest in using DTN for space flight mission communications but the computers on spacecraft are frequently far less powerful than engineering workstations, yet transmission rates are becoming quite high; performing flight mission DTN in software may in some cases be impracticable.  The concern isn’t so much with routers as with end systems.

Again, I think a mechanism for explicitly cueing the switch between the hardware path (one or more fixed bundle formats) and the software path (the baseline design with lots of variability) seems like a good way to reconcile some communities’ need for low processing overhead with others’ need for very flexible operations.

And I of course agree that numeric node IDs are part of the answer here, but I will as usual point out that there is nothing space-use-case-specific about numeric node IDs, just as there is nothing space-specific about Social Security numbers.

Scott

From: Elwyn Davies [mailto:[email-masked]]
Sent: Tuesday, December 9, 2014 11:06 AM
To: Burleigh, Scott C (312B); Templin, Fred L; Marc Blanchet
Cc: Hylton, Alan G. (GRC-LCA0); Amy Alford; [email-masked]; William Ivancic
Subject: Re: [dtn] DTN WG Virtual Meeting - Thursday December 5, 2014 (fixed the links )

Yes, the "fast path" in all hardware assisted routers today (typically with network processors and often with very fast - and expensive - CAM memory to do longest prefix address lookup) will dump anything that is not a plain vanilla IP packet to the slow path through the control processor using software mechanisms.

If you are going to worry about fast path compatibility, you first have to think about how addresses might be processed.  It is not clear that late binding and fast path processing will be compatible, but that is another question for the addressing box.  Maybe the reduced size numerical node IDs proposed for the space use case would be OK.

On the subject of IPv6 extension headers: Yes, they can be defined BUT the IETF will no longer allow you to standardise hop-by-hop headers that were intended to be processed in each router on the path for exactly the reason that started this thread: the fast path has to recognize any combination of hop-by-hop headers and do whatever is "the right thing" according to that header.  In general routers are not software upgradeable to do arbitrary things that a hop-by-hop header might want and there is every chance that a subset of the routers on the path of your packet with the brand new hop-by-hop header would not recognize the new header because their software is old and at best it will get dumped to slow path and more likely get dropped because the router can't understand it.

However, given all this, I am not sure why we are particularly worried about hardware assisted processing.  DTN is store-carry-forward so, especially in sparse networks, most bundle processing is not direct input line to output line low latency queue.  Most bundles will be line to internal storage or internal storage to output line queue according to what contact(s) are in progress.  Also in a good percentage of cases there is only one or a very few output lines active at any one time.  Bundles travelling across the well-connected Internet will a.s. be wrapped up in IP packets anyway as they are today unless we are intending to have a native bundle transport in the Internet .

Regards,
Elwyn

Scott

Hi Marc,

Thanks – Fred

Marc.

Scott

Amy,

Will

Cheers,
Elwyn

Scott

-----Original Message-----
From: Will Ivancic [mailto:[email-masked]<mailto:[email-masked]>]
Sent: Sunday, December 07, 2014 6:53 AM
To: 'Elwyn Davies'; Burleigh, Scott C (312B); 'Ivancic, William D. (GRC-LCA0)'; [email-masked]<mailto:[email-masked]>
Subject: RE: [dtn] DTN WG Virtual Meeting - Thursday December 5, 2014 (fixed the links )

Will

---

From: "Juan A. Fraire" <[email-masked]>
Date: Wed, 10 Dec 2014 13:53:37 -0300

Exactly Scott. In my opinion, DTN is meant to be used in
infrastructure-less scenarios where powerful computers might no be suitable
such as space or underwater. Therefore, it might be healthy to think DTN
specification while paying attention to potential performance
optimizations.
For instance, current spacecraft communications systems can handle 100s of
Mbps with any standard (i.e. slow) OBC because high datarate transponders
directly read an intelligence-free bitstream from a massive data recorder.
If we want to fly DTN instead, we need to aim at providing at least the
same performance to our agencies for them to ever consider this technology.
Indeed, I think numerical IDs are in this line of thoughts.

Regards,

J.Fraire

On Wed, Dec 10, 2014 at 1:27 PM, Burleigh, Scott C (312B) <
[email-masked]> wrote:

>  My understanding of the appeal of hardware assisted processing is that
> there is interest in using DTN for space flight mission communications but
> the computers on spacecraft are frequently far less powerful than
> engineering workstations, yet transmission rates are becoming quite high;
> performing flight mission DTN in software may in some cases be
> impracticable.  The concern isn’t so much with routers as with end systems.
>
>
>
> Again, I think a mechanism for explicitly cueing the switch between the
> hardware path (one or more fixed bundle formats) and the software path (the
> baseline design with lots of variability) seems like a good way to
> reconcile some communities’ need for low processing overhead with others’
> need for very flexible operations.
>
>
>
> And I of course agree that numeric node IDs are part of the answer here,
> but I will as usual point out that there is nothing space-use-case-specific
> about numeric node IDs, just as there is nothing space-specific about
> Social Security numbers.
>
>
>
> Scott
>
>
>
> *From:* Elwyn Davies [mailto:[email-masked]]
> *Sent:* Tuesday, December 9, 2014 11:06 AM
> *To:* Burleigh, Scott C (312B); Templin, Fred L; Marc Blanchet
> *Cc:* Hylton, Alan G. (GRC-LCA0); Amy Alford; [email-masked]; William
> Ivancic
>