Subject: [dtn-interest] more on the end-to-end principle

From: "Burleigh, Scott C (312G)" <[email-masked]>
Date: Wed, 7 May 2014 16:44:48 +0000

Hi, Patrick.  Without speculating on what might be the major unsolved problems in networking, I’ll comment briefly on the DTN protocols’ alignment with the end-to-end principle.
It has been occasionally asserted on this list that the design of the DTN protocols ignores the “end-to-end principle” that has served the Internet very well for several decades.  That erroneous assertion has been repeatedly refuted, without evident effect.  I’ll try one more time.
On the contrary, the DTN design has borne the end-to-end argument in mind from the beginning and applies it literally, with considerable care.  Salzer, Reed, and Clark, in “End-To-End Arguments In System Design” (ACM Transactions in Computer Systems 2(4), November 1984, pages 277-288), write:
[Consider] …a list of functions each of which might be implemented in any of several ways: by the communication subsystem, by its client, as a joint venture, or perhaps redundantly, each doing its own version. In reasoning about this choice, the requirements of the application provide the basis for a class of arguments, which go as follows:
The function in question can completely and correctly be implemented only with the knowledge and help of the application standing at the end points of the communication system. Therefore, providing that questioned function as a feature of the communication system itself is not possible. (Sometimes an incomplete version of the function provided by the communication system may be useful as a performance enhancement.)
We call this line of reasoning against low-level function implementation the "end-to-end argument."
In the case of delay-tolerant networking, there may never be contemporaneous end-to-end connectivity from the source to the destination.  So while the ultimate responsibility for retransmitting data that are lost due to transmission failure assuredly remains with the source (the end), end-to-end retransmission may take so long that unacceptable delivery latency is introduced.  So we retransmit within the network to make performance acceptable.  We implement in the communication system an incomplete version of the function to enhance performance, while also providing simple mechanisms to support end-to-end retransmission at the application layer (at the ends).
Ultimate responsibility for protection of application data integrity likewise remains with the source and destination.  In DTN we provide a mechanism for end-to-end application data integrity protection, the Payload Integrity Block.  (One might argue that this mechanism is deficient, and that is certainly a valid topic for discussion.  But that claimed deficiency doesn’t demonstrate that the end-to-end principle was ignored.)  But again, end-to-end application data integrity protection in DTN – while necessary – is not sufficient.  DTN communication links may be so limited in bandwidth that the propagation of corrupt or inauthentic data – e.g., a DOS attack – would have a significant impact on network performance, by wasting bandwidth needed for the transmission of authentic data; data integrity failures must be detected as early as possible so that corrupt data can be discarded immediately.   So again we implement within the communication system an incomplete version of the function to enhance performance: the hop-by-hop Bundle Authentication Block, for early detection of data corruption.
Salzer, Reed, and Clark were themselves similarly pragmatic about application of the argument they had defined:
Frequently, the performance tradeoff is quite complex. Consider again the careful file transfer on an unreliable network. The usual technique for increasing packet reliability is some sort of per-packet error check with a retry protocol. This mechanism can be  implemented either in the communication subsystem or in the careful file transfer application. For example, the receiver in the careful file transfer can periodically compute the checksum of the portion of the file thus far received and transmit this back to the sender. The sender can then restart by retransmitting any portion that arrived in error.
The end-to-end argument does not tell us where to put the early checks, since either layer can do this performance-enhancement job. Placing the early retry protocol in the file transfer application simplifies the communication system, but may increase overall cost, since the communication system is shared by other applications and each application must now provide its own reliability enhancement. Placing the early retry protocol in the  communication system may be more efficient, since it may be performed inside the network on a hop-by-hop basis, reducing the delay involved in correcting a failure. At the same time, there may be some application that finds the cost of the enhancement is not worth the result but it now has no choice in the matter. A great deal of information about system implementation is needed to make this choice intelligently.
The end-to-end argument was never intended to be dogma; it was intended to improve the engineering of networks.  The DTN architecture fully honors that intent, and always has.
Scott

From: dtn-interest [mailto:[email-masked]] On Behalf Of Gelard Patrick
Sent: Wednesday, May 07, 2014 1:29 AM
To: [email-masked]
Subject: Re: [dtn-interest] DTN BoF Proposal for IETF90

Dear all,

>> Rediscovering the ramifications of the end-to-end principle cannot really be considered research at this point
Is it a rediscovering of end-to-end principle variant or the need of new definition of end-to-end concept to take in account new Delay and  Disruption constraint ?

Is that Delay-  and  Disruption-Tolerant  Networking can continue to be base on the principle of « Intelligence is at the end » : Network architecture must be as simple as possible – don’t bring in infrastructure specific optimizations for any particular purpose ? A "dumb" network with "smart" terminals ?

Modern physic try to build « A theory of everything » to take in account major unsolved problems in physics<http://en.wikipedia.org/wiki/Unsolved_problems_in_physics>. What are the major unsolved problem in Networking ?

Bests regard
Patrick
end-to-end principle http://en.wikipedia.org/wiki/End-to-end_principle

De : dtn-interest [mailto:[email-masked]] De la part de [email-masked]<mailto:[email-masked]>
Envoyé : mercredi 7 mai 2014 05:56
À : [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Objet : Re: [dtn-interest] DTN BoF Proposal for IETF90

"Although DTN has clearly research issues to be addressed"

I wouldn't describe these as research issues, but as basic engineering issues. Rediscovering the ramifications of the end-to-end principle cannot really be considered research at this point.

"optimizing DTN for terrestrial or space environment only may cancel the original concept of interoperability of diverse environments."

We have previously asked whether interoperability of diverse environments is warranted and worthwhile:

Lloyd Wood, Peter Holliday, Daniel Floreani and Wesley M. Eddy,

'Sharing the dream: The consensual networking hallucination offered

by the Bundle Protocol', peer-reviewed conference paper, Workshop on

the Emergence of Delay-/Disruption-Tolerant Networks (E-DTN),

part of the International Conference on Ultra Modern Telecommunication

(ICUMT), St. Petersburg, Russia, 14 October 2009.  2 pages.

http://dx.doi.org/10.1109/ICUMT.2009.5345655
http://personal.ee.surrey.ac.uk/Personal/L.Wood/publications/index.html#e-dtn-position

figure 1 is particularly helpful in thinking about this dichotomy of environments.
Lloyd Wood
http://about.me/lloydwood
________________________________
From: dtn-interest <[email-masked]<mailto:[email-masked]>> on behalf of Vassilios Tsaoussidis <[email-masked]<mailto:[email-masked]>>
Sent: Wednesday, 7 May 2014 11:47 AM
To: [email-masked]<mailto:[email-masked]>
Subject: Re: [dtn-interest] DTN BoF Proposal for IETF90

I am also in favor of Fred's proposal. Although DTN has clearly research issues to be addressed, the level of maturity of BP along with the community's clear direction towards internet for everywhere, everything and everyone calls for IETF standardization actions. I am also in favor of forming a single group - to which I intend to participate; dichotomies typically cause more problems than they solve. Also, optimizing DTN for terrestrial or space environment only may cancel the original concept of interoperability of diverse environments.

Vassilis Tsaoussidis

Στις 2014-05-07 03:18, ccaini έγραψε:

Dear Fred,

      if the vitality of a research group is denoted by the number of mail

exchanges on the group mailing list, I would say that your proposal has

really brought new life to it!

I am grateful for this.

In my opinion, it was high time that somebody proposed to move DTN BP from

pure research to engineering standardization also for non Interplanetary

applications.

I say this not because I think that BP is perfect and there is no need to

further research, or just to include some of the features that at present

are lacking in future RFCs (e.g. I am in favor of end-to-end CRC check,

which is one of Wood's favorite arguments, with good reasons), but because

without true applications in mind, without the active participation  of big

companies, like Boeing, the DTN appealing outside of Interplanetary

applications seems to me destined to slowly fade out.

I suppose that the prospect of having a DTN standardized protocol

supported by a big company can help in sustaining and rising the interest

of Industry on DTN, which is essential to develop applications that are not

just mere demos; applications that can show all the potential of the DTN

concept and that can make the difference with present ones. This would also

help in keeping alive and possibly reinvigorating DTN more open research

too.

Of course, IETF standardizations should be coordinated with CCSDS

standardization for space applications, in order to maintain a unique DTN

umbrella for both (i.e. some form of close interoperability).

Yours,

    Carlo Caini

(University of Bologna)

On Tue, 6 May 2014 15:30:00 +0000, "Mehta, Devanshu - 0665 - MITLL"

<[email-masked]<mailto:[email-masked]>> wrote:
In fact, a "blank sheet" dtnrg may reinvigorate some of the more silent members of the group. Devanshu ----- Original Message ----- From: Burleigh, Scott C (312G) [mailto:[email-masked]<mailto:[email-masked]>] Sent: Monday, May 05, 2014 08:00 PM Eastern Standard Time To: Marc Blanchet <[email-masked]<mailto:[email-masked]>> Cc: [email-masked]<mailto:[email-masked]> <[email-masked]<mailto:[email-masked]>> Subject: Re: [dtn-interest] DTN BoF Proposal for IETF90 Marc, certainly you are correct that taking both paths concurrently

would
amount to twice as much work, more or less. But we are all individuals, all free agents (modulo the interests of our funding sources, for those

of
us whose participation is funded). It's not as if there is a common

pool
of people bandwidth that we can direct to work on one project or

another:
those of us who are interested in one of these projects will work on it, and those who are not probably won't. I don't think excluding one of

them
would much improve the effort that gets devoted to the other; rather, I think including both could accomplish more in total. Scott -----Original Message----- From: Marc Blanchet [mailto:[email-masked]<mailto:[email-masked]>] Sent: Monday, May 05, 2014 1:17 PM To: Burleigh, Scott C (312G) Cc: [email-masked]<mailto:[email-masked]> Subject: Re: [dtn-interest] DTN BoF Proposal for IETF90 Le 2014-05-05 à 12:52, Burleigh, Scott C (312G) <[email-masked]<mailto:[email-masked]>> a écrit :
How about doing both? My understanding of Boeing's interest is that they are looking for standards to support fairly near-term commercialization of the RFC 5050-based technology that we've all gotten a good deal of experience with over the past few years. In that context, "fix 5050/BP" seems

like
a good fit for the proposed working group. At the same time, taking up the last decade's worth of insight and knowledge and starting over again from a blank sheet of paper seems

like
exactly the right sort of thing for the DTN Research Group to take on.
on "paper", I agree. But I have concerns on people bandwidth to work in two working groups. Even the current one has not met for quite some

time.
So instead of starting 2, we may want to try to just (re-)start one... Marc.
Scott -----Original Message----- From: dtn-interest [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Kevin Fall Sent: Monday, May 05, 2014 12:03 PM To: Templin, Fred L Cc: [email-masked]<mailto:[email-masked]> Subject: Re: [dtn-interest] DTN BoF Proposal for IETF90 I can see a couple of ways you might go forward. If you start off as a "fix 5050/BP" you will encounter disagreement as to what are problems

and
what are not. This is evident from the various exchanges over the

years.
Alternatively, you can start somewhat higher level with the notion that the area of challenged/DTN/DIL networks is to be addressed with a standard protocol (set), that there is now sufficient insight and knowledge thanks to DTNRG, and the field is open. There may be

different
design goals potentially (e.g., some web compatibility or whatnot)

which
was/were not a particular driving goal for DTNRG or BP. - Kevin On Mon, May 5, 2014 at 11:02 AM, Templin, Fred L <[email-masked]<mailto:[email-masked]>> wrote:
Hi Lloyd, I have to say that I mostly agree with Stephen. IMHO, "Bundle of Problems" is a very useful document and still applies today, but I see it as an actionable problem statement and not an end-of-the-road pronouncement. I believe most of the BoP problems can be addressed in an RFC5050(bis) and we would tackle this in the initial working group

work
items. Thanks - Fred [email-masked]<mailto:[email-masked]>
-----Original Message----- From: dtn-interest [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of [email-masked]<mailto:[email-masked]> Sent: Monday, May 05, 2014 12:13 AM To: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]> Subject: Re: [dtn-interest] DTN BoF Proposal for IETF90 Stephen, I would discourage others from using or building on RFC5050, based on our experience in testing the Bundle Protocol in space [1], analysing the protocol's failings [2], and a variety of previously suggested fixes and drafts in this RG that never went anywhere, which aren't published. That's our engineering judgement on RFC5050 as it stands, and many long-time readers will be familiar with our arguments. But, as far as discussing the proposed WG and a modified RFC5050bis goes: Any protocol is simply an artefact that is an outcome of a process by people. It's reasonable to have doubts about the same pool of people producing anything better in a similar process. If there's a new crowd from Boeing et al with relevant expertise and funding/resources/time, that may help. (Or not, depending on the learning curve.) Will the putative IETF WG be as wholly focused on, say, security? I don't see how having a set of milestones magically fixes things that years in this research group, with discussion between the interested, did not. I don't see how an RG with failing output and limited adoption can be transformed into a WG with successful output and widespread (even terrestrial?) adoption, and I have never seen that done. (RGs have transformed and mutated into other RGs, with rather varying success.) How can a WG with the mandate 'fix the bundle protocol' succeed? Is it just being set up to fail? Should it therefore not be set up at all? [1] Will Ivancic, Wesley M. Eddy, Dave Stewart, Lloyd Wood, James Northam and Chris Jackson, 'Experience with delay-tolerant networking from orbit', peer-reviewed journal paper, International Journal of Satellite Communications and Networking, special issue for best papers of the Fourth Advanced Satellite Mobile Systems Conference (ASMS 2008), vol. 28, issues 5-6, pp. 335-351, September-December 2010. http://dx.doi.org/10.1002/sat.966 http://personal.ee.surrey.ac.uk/Personal/L.Wood/publications/ijscn-a s ms-bundle-paper-submitted.pdf [2] Lloyd Wood, Wesley M. Eddy and Peter Holliday, 'A Bundle of Problems', peer-reviewed conference paper, IEEE Aerospace Conference, Big Sky, Montana, March 2009. 16 pages. http://dx.doi.org/10.1109/AERO.2009.4839384 http://personal.ee.surrey.ac.uk/Personal/L.Wood/publications/wood-ie e e-aerospace-2009-bundle- problems.pdf Lloyd Wood http://sat-net.com/L.Wood/dtn that was a Star Wars reference, btw. May the 4th: may the force... ________________________________________ From: Stephen Farrell <[email-masked]<mailto:[email-masked]>> Sent: Monday, 5 May 2014 1:46 AM To: Wood L Dr (Electronic Eng); [email-masked]<mailto:[email-masked]> Subject: Re: [dtn-interest] DTN BoF Proposal for IETF90 Lloyd, On 04/05/14 09:19, [email-masked]<mailto:[email-masked]>wrote:
I have a bad feeling about this.
FWIW, my impression is that you'd have a bad feeling about anything related to rfc5050 regardless. IMO, it'd be quite reasonable for people to disregard quite a bit of what you say on that basis, i.e. that you appear to be interested in being destructively critical. That's a pity, since there are things to be improved/fixed for which you have argued, and with which others agree. Its even more a pity as it somewhat poisons the discussion, so I'd ask that if you can, please you try to put aside your distaste for rfc5050 and your annoyance at dtnrg history and try constructively discuss the proposed IETF wg. S. _______________________________________________ dtn-interest mailing list [email-masked]<mailto:[email-masked]> https://www.irtf.org/mailman/listinfo/dtn-interest
_______________________________________________ dtn-interest mailing list [email-masked]<mailto:[email-masked]> https://www.irtf.org/mailman/listinfo/dtn-interest
_______________________________________________ dtn-interest mailing list [email-masked]<mailto:[email-masked]> https://www.irtf.org/mailman/listinfo/dtn-interest _______________________________________________ dtn-interest mailing list [email-masked]<mailto:[email-masked]> https://www.irtf.org/mailman/listinfo/dtn-interest
_______________________________________________ dtn-interest mailing list [email-masked]<mailto:[email-masked]> https://www.irtf.org/mailman/listinfo/dtn-interest _______________________________________________ dtn-interest mailing list [email-masked]<mailto:[email-masked]> https://www.irtf.org/mailman/listinfo/dtn-interest

_______________________________________________

dtn-interest mailing list

[email-masked]<mailto:[email-masked]>

https://www.irtf.org/mailman/listinfo/dtn-interest

---

From: <[email-masked]>
Date: Wed, 7 May 2014 22:56:55 +0000

RFC5050, published 2007, was intended for the most challenged, difficult, errored networks we have. It has nothing to check either its payload or its own headers for delivery; custody transfer is a cheery 'hey, I got _something_ from you! Well, probably you. Is it exactly what probably-you sent? Gee, how should I know? What do you mean, the network's not perfectly reliable? Hello?' As a control loop, it's not much. It's indeed incomplete. It ignores the end-to-end principle.

Scott's appeal is to RFC6257, published 2011, where the optional security protocol fills in the error detection gap by happy accident; error detection and rejection is a side-effect of implementing security against attackers. And even then, depending on canonicalisation, its coverage can be incomplete. But this makes the security protocol mandatory for use, because how else can errors in payload and in the bundle protocol's own headers be checked for? At all?

The end-to-end argument is about ensuring reliability, and where reliability checks must be placed, at endpoints, to ensure reliable delivery (the end-to-end piece) , but also about where they can also be placed, along the way, to increase performance. Saying 'well, we can leave it up the applications as the ultimate endpoints, in accordance with the end-to-end principle' comes with high retransmission and performance costs. Fig 1 of our Bundle of Problems paper, published 2009, has demonstration of this; with hop by hop delivery in a disconnected network, early checking for errors and early resends make sense. RFC5050 doesn't do that.

I don't think Saltzer et al's papers are dogma, which is why I'm not quoting them. (As an English major, Scott's more used to arguing from the text.) But they do expose and illuminate the underlying engineering tradeoffs that we've come to call the end-to-end principle. And in a challenging environment, every node needs to play some part in ensuring overall reliability, for the benefit of the traffic, network, endpoints and users.

Lloyd Wood
<http://sat-net.com/L.Wood/dtn/bundle.html>http://sat-net.com/L.Wood/dtn/bundle.html

________________________________
From: dtn-interest <[email-masked]> on behalf of Burleigh, Scott C (312G) <[email-masked]>
Sent: Thursday, 8 May 2014 2:44 AM
To: [email-masked]
Subject: [dtn-interest] more on the end-to-end principle

Dear all,

Bests regard
Patrick

Vassilis Tsaoussidis

Dear Fred,

I am grateful for this.

applications.

too.

Yours,

    Carlo Caini

(University of Bologna)

would

of

pool

another:

them

like

like

time.

and

years.

different

which

work

---

From: "Templin, Fred L" <[email-masked]>
Date: Thu, 8 May 2014 01:27:06 +0000

Hi Lloyd,

We have both RFC5050(bis) and Streamlined Bundle Security Protocol as first-round
proposed work items on the draft charter. They are currently separate documents,
and it has been suggested that they be combined but IMHO I don’t think it matters
one way or the other.

Thanks - Fred

From: dtn-interest [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Wednesday, May 07, 2014 3:57 PM
To: [email-masked]; [email-masked]
Subject: Re: [dtn-interest] more on the end-to-end principle

Lloyd Wood
http://sat-net.com/L.Wood/dtn/bundle.html
________________________________
From: dtn-interest <[email-masked]<mailto:[email-masked]>> on behalf of Burleigh, Scott C (312G) <[email-masked]<mailto:[email-masked]>>
Sent: Thursday, 8 May 2014 2:44 AM
To: [email-masked]<mailto:[email-masked]>
Subject: [dtn-interest] more on the end-to-end principle

Dear all,

Bests regard
Patrick

Vassilis Tsaoussidis

Dear Fred,

I am grateful for this.

applications.

too.

Yours,

    Carlo Caini

(University of Bologna)

would

of

pool

another:

them

like

like

time.

and

years.

different

which

work

---

From: Vassilios Tsaoussidis <[email-masked]>
Date: Thu, 08 May 2014 12:29:03 +0800

Fred, Lloyd and all, 

I don't think BP violates the end-to-end argument; instead, it can be
supportive. However, I think it is falsely claimed in RFC 5050 that BP
is an end-to-end protocol. It could be considered, under circumstances,
_end-to-end with sliding end_, which, in my opinion, is a suitable
architecture when the topology changes dynamically. I recall myself
making this argument a few years back at the early CCSDS discussions
about the Bundle Protocol and in particular, highlighting the case of
the "missing bundle" when the network is partitioned and a bundle is
isolated in between. See more arguments here: 

 	* Giorgos Papastergiou, Christos V. Samaras and Vassilis Tsaoussidis,
"WHERE DOES TRANSPORT LAYER FIT INTO SPACE DTN ARCHITECTURE?" [13], 5th
Advance Satellite Multimedia Systems Conference and 11th Signal
Processing for Space Communications Workshop, ASMS-SPSC 2010, 13-15
September 2010, Cagliari, Italy

http://www.spice-center.org/files/publications/asms-spsc-2010.pdf 

Clearly, end-to-end arguments are valid when _there is_ end-to-end path.
In challenged environments end-to-end paths do not necessarily
correspond to source-destination paths, that's why I understand that all
valid end-to-end arguments need to apply to the adaptive nature of the
_current_ end-to-end path, not to the original source-destination
paradigm. I think BP does not prohibit this potential and hence it does
not violate the end-to-end argument. Supportively, DTPC for example,
addresses end-to-end functions on top of BP. See Motivation and
Background Section in 

 G. Papastergiou, I. Alexiadis, S. Burleigh and V. Tsaoussidis, "Delay
Tolerant Payload Conditioning Protocol [14]", Computer Networks, vol.
59, pp.244-263, February 2014 

http://www.sciencedirect.com/science/article/pii/S1389128613003745 [14] 

Finally, I don't think end-to-end functions are application's
responsibility but instead have to be included in the protocol stack -
nodes in between should be aware and act, occasionally, as ends
themselves. 

I think such issues need to be clarified in IETF and hence I strongly
support the proposal to enter IETF DTN BoF at the next meeting. And, I
understand, the discussion in this BoF has started already.. 

Vassilis 

Στις 2014-05-08 09:27, Templin, Fred L έγραψε: 

> and it has been suggested that they be combined but IMHO I don't think it matters 
> 
> one way or the other. 
> 
> Thanks - Fred 
> 
> FROM: dtn-interest [mailto:[email-masked]] ON BEHALF OF [email-masked]
> SENT: Wednesday, May 07, 2014 3:57 PM
> TO: [email-masked]; [email-masked]
> SUBJECT: Re: [dtn-interest] more on the end-to-end principle 
> 
> http://sat-net.com/L.Wood/dtn/bundle.html [2] 
> 
> -------------------------
> 
> FROM: dtn-interest <[email-masked]> on behalf of Burleigh, Scott C (312G) <[email-masked]>
> SENT: Thursday, 8 May 2014 2:44 AM
> TO: [email-masked]
> SUBJECT: [dtn-interest] more on the end-to-end principle 
> 
> Hi, Patrick. Without speculating on what might be the major unsolved problems in networking, I'll comment briefly on the DTN protocols' alignment with the end-to-end principle. 
> 
> It has been occasionally asserted on this list that the design of the DTN protocols ignores the "end-to-end principle" that has served the Internet very well for several decades. That erroneous assertion has been repeatedly refuted, without evident effect. I'll try one more time. 
> 
> On the contrary, the DTN design has borne the end-to-end argument in mind from the beginning and applies it literally, with considerable care. Salzer, Reed, and Clark, in "End-To-End Arguments In System Design" (ACM Transactions in Computer Systems 2(4), November 1984, pages 277-288), write: 
> 
> [Consider] …_a list of functions each of which might be implemented in any of several ways: by the communication subsystem, by its client, as a joint venture, or perhaps redundantly, each doing its own version. In reasoning about this choice, the requirements of the application provide the basis for a class of arguments, which go as follows:_ 
> 
> _The function in question can completely and correctly be implemented only with the knowledge and help of the application standing at the end points of the communication system. Therefore, providing that questioned function as a feature of the communication system itself is not possible. (Sometimes an incomplete version of the function provided by the communication system may be useful as a performance enhancement.)_ 
> 
> _We call this line of reasoning against low-level function implementation the "end-to-end argument."_ 
> 
> Ultimate responsibility for protection of application data integrity likewise remains with the source and destination. In DTN we provide a mechanism for end-to-end application data integrity protection, the Payload Integrity Block. (One might argue that this mechanism is deficient, and that is certainly a valid topic for discussion. But that claimed deficiency doesn't demonstrate that the end-to-end principle was ignored.) But again, end-to-end application data integrity protection in DTN - while necessary - is not sufficient. DTN communication links may be so limited in bandwidth that the propagation of corrupt or inauthentic data - e.g., a DOS attack - would have a significant impact on network performance, by wasting bandwidth needed for the transmission of authentic data; data integrity failures must be detected as early as possible so that corrupt data can be discarded immediately. So again we implement within the communication system an incomplete version of the function to
enhance performance: the hop-by-hop Bundle Authentication Block, for early detection of data corruption. 
> _Frequently, the performance tradeoff is quite complex. Consider again the careful file transfer on an unreliable network. The usual technique for increasing packet reliability is some sort of per-packet error check with a retry protocol. This mechanism can be implemented either in the communication subsystem or in the careful file transfer application. For example, the receiver in the careful file transfer can periodically compute the checksum of the portion of the file thus far received and transmit this back to the sender. The sender can then restart by retransmitting any portion that arrived in error._ 
> 
> _The end-to-end argument does not tell us where to put the early checks, since either layer can do this performance-enhancement job. Placing the early retry protocol in the file transfer application simplifies the communication system, but may increase overall cost, since the communication system is shared by other applications and each application must now provide its own reliability enhancement. Placing the early retry protocol in the communication system may be more efficient, since it may be performed inside the network on a hop-by-hop basis, reducing the delay involved in correcting a failure. At the same time, there may be some application that finds the cost of the enhancement is not worth the result but it now has no choice in the matter. A great deal of information about system implementation is needed to make this choice intelligently._ 
> 
> FROM: dtn-interest [mailto:[email-masked]] ON BEHALF OF Gelard Patrick
> SENT: Wednesday, May 07, 2014 1:29 AM
> TO: [email-masked]
> SUBJECT: Re: [dtn-interest] DTN BoF Proposal for IETF90 
> 
> Dear all, 
> 
> Is that Delay- and Disruption-Tolerant Networking can continue to be base on the principle of « Intelligence is at the end » : Network architecture must be as simple as possible - don't bring in infrastructure specific optimizations for any particular purpose ? A "dumb" network with "smart" terminals ? 
> 
> Modern physic try to build « A theory of everything » to take in account major unsolved problems in physics [3]. What are the major unsolved problem in Networking ? 
> 
> Bests regard 
> 
> Patrick 
> 
> end-to-end principle http://en.wikipedia.org/wiki/End-to-end_principle [4] 
> 
> DE : dtn-interest [mailto:[email-masked]] DE LA PART DE [email-masked]
> ENVOYÉ : mercredi 7 mai 2014 05:56
> À : [email-masked]; [email-masked]
> OBJET : Re: [dtn-interest] DTN BoF Proposal for IETF90 
> 
> http://dx.doi.org/10.1109/ICUMT.2009.5345655 [1]
> 
> http://personal.ee.surrey.ac.uk/Personal/L.Wood/publications/index.html#e-dtn-position [5]
> 
> http://about.me/lloydwood [6] 
> 
> -------------------------
> 
> FROM: dtn-interest <[email-masked]> on behalf of Vassilios Tsaoussidis <[email-masked]>
> SENT: Wednesday, 7 May 2014 11:47 AM
> TO: [email-masked]
> SUBJECT: Re: [dtn-interest] DTN BoF Proposal for IETF90 
> 
> <[email-masked]> wrote:
> 
> In fact, a "blank sheet" dtnrg may reinvigorate some of the more silent members of the group. Devanshu ----- Original Message ----- From: Burleigh, Scott C (312G) [mailto:[email-masked]] Sent: Monday, May 05, 2014 08:00 PM Eastern Standard Time To: Marc Blanchet <[email-masked]> Cc: [email-masked] <[email-masked]> Subject: Re: [dtn-interest] DTN BoF Proposal for IETF90 Marc, certainly you are correct that taking both paths concurrently 
> 
> would
> 
> would much improve the effort that gets devoted to the other; rather, I think including both could accomplish more in total. Scott -----Original Message----- From: Marc Blanchet [mailto:[email-masked]] Sent: Monday, May 05, 2014 1:17 PM To: Burleigh, Scott C (312G) Cc: [email-masked] Subject: Re: [dtn-interest] DTN BoF Proposal for IETF90 Le 2014-05-05 à 12:52, Burleigh, Scott C (312G) <[email-masked]> a écrit : 
> 

like

time.

> Scott -----Original Message----- From: dtn-interest [mailto:[email-masked]] On Behalf Of Kevin Fall Sent: Monday, May 05, 2014 12:03 PM To: Templin, Fred L Cc: [email-masked] Subject: Re: [dtn-interest] DTN BoF Proposal for IETF90 I can see a couple of ways you might go forward. If you start off as a "fix 5050/BP" you will encounter disagreement as to what are problems

and

years.

different

which

>> was/were not a particular driving goal for DTNRG or BP. - Kevin On Mon, May 5, 2014 at 11:02 AM, Templin, Fred L <[email-masked]> wrote: 
>> 

work

> items. Thanks - Fred [email-masked] 
> 
> -----Original Message----- From: dtn-interest [mailto:[email-masked]] On Behalf Of [email-masked] Sent: Monday, May 05, 2014 12:13 AM To: [email-masked]; [email-masked] Subject: Re: [dtn-interest] DTN BoF Proposal for IETF90 Stephen, I would discourage others from using or building on RFC5050, based on our experience in testing the Bundle Protocol in space [1], analysing the protocol's failings [2], and a variety of previously suggested fixes and drafts in this RG that never went anywhere, which aren't published. That's our engineering judgement on RFC5050 as it stands, and many long-time readers will be familiar with our arguments. But, as far as discussing the proposed WG and a modified RFC5050bis goes: Any protocol is simply an artefact that is an outcome of a process by people. It's reasonable to have doubts about the same pool of people producing anything better in a similar process. If there's a new crowd from Boeing et al with relevant
expertise and funding/resources/time, that may help. (Or not, depending on the learning curve.) Will the putative IETF WG be as wholly focused on, say, security? I don't see how having a set of milestones magically fixes things that years in this research group, with discussion between the interested, did not. I don't see how an RG with failing output and limited adoption can be transformed into a WG with successful output and widespread (even terrestrial?) adoption, and I have never seen that done. (RGs have transformed and mutated into other RGs, with rather varying success.) How can a WG with the mandate 'fix the bundle protocol' succeed? Is it just being set up to fail? Should it therefore not be set up at all? [1] Will Ivancic, Wesley M. Eddy, Dave Stewart, Lloyd Wood, James Northam and Chris Jackson, 'Experience with delay-tolerant networking from orbit', peer-reviewed journal paper, International Journal of Satellite Communications and Networking, special issue for best papers
of the Fourth Advanced Satellite Mobile Systems Conference (ASMS 2008), vol. 28, issues 5-6, pp. 335-351, September-December 2010. http://dx.doi.org/10.1002/sat.966 [7] http://personal.ee.surrey.ac.uk/Personal/L.Wood/publications/ijscn-a [8] s ms-bundle-paper-submitted.pdf [2] Lloyd Wood, Wesley M. Eddy and Peter Holliday, 'A Bundle of Problems', peer-reviewed conference paper, IEEE Aerospace Conference, Big Sky, Montana, March 2009. 16 pages. http://dx.doi.org/10.1109/AERO.2009.4839384 [9] http://personal.ee.surrey.ac.uk/Personal/L.Wood/publications/wood-ie [10] e e-aerospace-2009-bundle- problems.pdf Lloyd Wood http://sat-net.com/L.Wood/dtn [11] that was a Star Wars reference, btw. May the 4th: may the force... ________________________________________ From: Stephen Farrell <[email-masked]> Sent: Monday, 5 May 2014 1:46 AM To: Wood L Dr (Electronic Eng); [email-masked] Subject: Re: [dtn-interest] DTN BoF Proposal for IETF90 Lloyd, On 04/05/14 09:19,
[email-masked]: 
> FWIW, my impression is that you'd have a bad feeling about anything related to rfc5050 regardless. IMO, it'd be quite reasonable for people to disregard quite a bit of what you say on that basis, i.e. that you appear to be interested in being destructively critical. That's a pity, since there are things to be improved/fixed for which you have argued, and with which others agree. Its even more a pity as it somewhat poisons the discussion, so I'd ask that if you can, please you try to put aside your distaste for rfc5050 and your annoyance at dtnrg history and try constructively discuss the proposed IETF wg. S. _______________________________________________ dtn-interest mailing list [email-masked] https://www.irtf.org/mailman/listinfo/dtn-interest [12] 
> 
> _______________________________________________ dtn-interest mailing list [email-masked] https://www.irtf.org/mailman/listinfo/dtn-interest [12] 
> 
> _______________________________________________ dtn-interest mailing list [email-masked] https://www.irtf.org/mailman/listinfo/dtn-interest [12] _______________________________________________ dtn-interest mailing list [email-masked] https://www.irtf.org/mailman/listinfo/dtn-interest [12]

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

[email-masked]

https://www.irtf.org/mailman/listinfo/dtn-interest [12]

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

Links:
------
[1] http://dx.doi.org/10.1109/ICUMT.2009.5345655
[2] http://sat-net.com/L.Wood/dtn/bundle.html
[3] http://en.wikipedia.org/wiki/Unsolved_problems_in_physics
[4] http://en.wikipedia.org/wiki/End-to-end_principle
[5]
http://personal.ee.surrey.ac.uk/Personal/L.Wood/publications/index.html#e-dtn-position
[6] http://about.me/lloydwood
[7] http://dx.doi.org/10.1002/sat.966
[8] http://personal.ee.surrey.ac.uk/Personal/L.Wood/publications/ijscn-a
[9] http://dx.doi.org/10.1109/AERO.2009.4839384
[10]
http://personal.ee.surrey.ac.uk/Personal/L.Wood/publications/wood-ie
[11] http://sat-net.com/L.Wood/dtn
[12] https://www.irtf.org/mailman/listinfo/dtn-interest
[13] http://www.spice-center.org/files/publications/asms-spsc-2010.pdf
[14] http://www.sciencedirect.com/science/article/pii/S1389128613003745

---

From: Eric Travis <[email-masked]>
Date: Thu, 8 May 2014 01:42:55 -0400

Scott,

Great discussion.

I think we might be one step closer to mutual understanding (and hopefully
closure) of how to increase the general utility of the Bundle Protocol.

So while the ultimate responsibility for retransmitting data that are lost
> due to transmission failure assuredly remains with the source (the end),
> end-to-end retransmission may take so long that unacceptable delivery
> latency is introduced.  So we retransmit within the network to make
> performance acceptable.  We implement in the communication system an
> incomplete version of the function to enhance performance, while also
> providing simple mechanisms to support end-to-end retransmission at the
> application layer (at the ends).
>

As the failure mode of concern is corruption as data is locally copied
between bundle agent and convergence layer,  I would substitute "corrupted"
for "lost due to transmission failure", but the thought remains the same...

Given that the end-to-end path for a bundle is a sequence of one or more
*end-to-end* transfers between CL entities, and the bundle agents are the
"ends" of these transfers - might it not be prudent for to support
application layer retransmission (at the ends - bundle agent to bundle
agent) for these transfers too?

Regards,

Eric
[email-masked]

On Wed, May 7, 2014 at 12:44 PM, Burleigh, Scott C (312G) <
[email-masked]> wrote:

>  Hi, Patrick.  Without speculating on what might be the major unsolved
> problems in networking, I’ll comment briefly on the DTN protocols’
> alignment with the end-to-end principle.
>
> It has been occasionally asserted on this list that the design of the DTN
> protocols ignores the “end-to-end principle” that has served the Internet
> very well for several decades.  That erroneous assertion has been
> repeatedly refuted, without evident effect.  I’ll try one more time.
>
> On the contrary, the DTN design has borne the end-to-end argument in mind
> from the beginning and applies it literally, with considerable care.
> Salzer, Reed, and Clark, in “End-To-End Arguments In System Design” (ACM
> Transactions in Computer Systems 2(4), November 1984, pages 277-288), write:
>
> [Consider] …*a list of functions each of which might be implemented in
> any of several ways: by the communication subsystem, by its client, as a
> joint venture, or perhaps redundantly, each doing its own version. In
> reasoning about this choice, the requirements of the application provide
> the basis for a class of arguments, which go as follows:*
>
> *The function in question can completely and correctly be implemented only
> with the knowledge and help of the application standing at the end points
> of the communication system. Therefore, providing that questioned function
> as a feature of the communication system itself is not possible. (Sometimes
> an incomplete version of the function provided by the communication system
> may be useful as a performance enhancement.)*
>
> *We call this line of reasoning against low-level function implementation
> the "end-to-end argument."*
>
> In the case of delay-tolerant networking, there may never be
> contemporaneous end-to-end connectivity from the source to the
> destination.  So while the ultimate responsibility for retransmitting data
> that are lost due to transmission failure assuredly remains with the source
> (the end), end-to-end retransmission may take so long that unacceptable
> delivery latency is introduced.  So we retransmit within the network to
> make performance acceptable.  We implement in the communication system an
> incomplete version of the function to enhance performance, while also
> providing simple mechanisms to support end-to-end retransmission at the
> application layer (at the ends).
>
> Ultimate responsibility for protection of application data integrity
> likewise remains with the source and destination.  In DTN we provide a
> mechanism for end-to-end application data integrity protection, the Payload
> Integrity Block.  (One might argue that this mechanism is deficient, and
> that is certainly a valid topic for discussion.  But that claimed
> deficiency doesn’t demonstrate that the end-to-end principle was ignored.)
> But again, end-to-end application data integrity protection in DTN – while
> necessary – is not sufficient.  DTN communication links may be so limited
> in bandwidth that the propagation of corrupt or inauthentic data – e.g., a
> DOS attack – would have a significant impact on network performance, by
> wasting bandwidth needed for the transmission of authentic data; data
> integrity failures must be detected as early as possible so that corrupt
> data can be discarded immediately.   So again we implement within the
> communication system an incomplete version of the function to enhance
> performance: the hop-by-hop Bundle Authentication Block, for early
> detection of data corruption.
>
> Salzer, Reed, and Clark were themselves similarly pragmatic about
> application of the argument they had defined:
>
> *Frequently, the performance tradeoff is quite complex. Consider again the
> careful file transfer on an unreliable network. The usual technique for
> increasing packet reliability is some sort of per-packet error check with a
> retry protocol. This mechanism can be  implemented either in the
> communication subsystem or in the careful file transfer application. For
> example, the receiver in the careful file transfer can periodically compute
> the checksum of the portion of the file thus far received and transmit this
> back to the sender. The sender can then restart by retransmitting any
> portion that arrived in error.*
>
> *The end-to-end argument does not tell us where to put the early checks,
> since either layer can do this performance-enhancement job. Placing the
> early retry protocol in the file transfer application simplifies the
> communication system, but may increase overall cost, since the
> communication system is shared by other applications and each application
> must now provide its own reliability enhancement. Placing the early retry
> protocol in the  communication system may be more efficient, since it may
> be performed inside the network on a hop-by-hop basis, reducing the delay
> involved in correcting a failure. At the same time, there may be some
> application that finds the cost of the enhancement is not worth the result
> but it now has no choice in the matter. A great deal of information about
> system implementation is needed to make this choice intelligently.*
>
> The end-to-end argument was never intended to be dogma; it was intended to
> improve the engineering of networks.  The DTN architecture fully honors
> that intent, and always has.
>
> Scott
>
>
>
>
>
> *From:* dtn-interest [mailto:[email-masked]] *On Behalf Of
> *Gelard Patrick
> *Sent:* Wednesday, May 07, 2014 1:29 AM
> *To:* [email-masked]
> *Subject:* Re: [dtn-interest] DTN BoF Proposal for IETF90
>
>
>
> Dear all,
>
>
>
> >> Rediscovering the ramifications of the end-to-end principle cannot
> really be considered research at this point
>
> Is it a rediscovering of end-to-end principle variant or the need of new
> definition of end-to-end concept to take in account new Delay and
>  Disruption constraint ?
>
>
>
> Is that Delay-  and  Disruption-Tolerant  Networking can continue to be
> base on the principle of « Intelligence is at the end » : Network
> architecture must be as simple as possible – don’t bring in infrastructure
> specific optimizations for any particular purpose ? A "dumb" network with
> "smart" terminals ?
>
>
>
> Modern physic try to build « A theory of everything » to take in account
> major unsolved problems in physics<http://en.wikipedia.org/wiki/Unsolved_problems_in_physics>.
> What are the major unsolved problem in Networking ?
>
>
>
> Bests regard
>
> Patrick
>
> *De :* dtn-interest [mailto:[email-masked]<[email-masked]>]
> *De la part de* [email-masked]
> *Envoyé :* mercredi 7 mai 2014 05:56
> *À :* [email-masked]; [email-masked]
> *Objet :* Re: [dtn-interest] DTN BoF Proposal for IETF90
>
>
>
> I wouldn't describe these as research issues, but as basic engineering
> issues. Rediscovering the ramifications of the end-to-end principle cannot
> really be considered research at this point.
>
>
>
> "optimizing DTN for terrestrial or space environment only may cancel the
> original concept of interoperability of diverse environments."
>
>
>
>    ------------------------------
>
> *From:* dtn-interest <[email-masked]> on behalf of
> Vassilios Tsaoussidis <[email-masked]>
> *Sent:* Wednesday, 7 May 2014 11:47 AM
> *To:* [email-masked]
> *Subject:* Re: [dtn-interest] DTN BoF Proposal for IETF90
>
>
>
> I am also in favor of Fred's proposal. Although DTN has clearly research
> issues to be addressed, the level of maturity of BP along with the
> community's clear direction towards internet for everywhere, everything and
> everyone calls for IETF standardization actions. I am also in favor of
> forming a single group - to which I intend to participate; dichotomies
> typically cause more problems than they solve. Also, optimizing DTN for
> terrestrial or space environment only may cancel the original concept of
> interoperability of diverse environments.
>
>
>
> Vassilis Tsaoussidis
>
>
>
>
>
>  In fact, a "blank sheet" dtnrg may reinvigorate some of the more silent
> members of the group. Devanshu ----- Original Message ----- From: Burleigh,
> Scott C (312G) [mailto:[email-masked]] Sent: Monday, May
> 05, 2014 08:00 PM Eastern Standard Time To: Marc Blanchet <
> [email-masked]> Cc: [email-masked] <
> [email-masked]> Subject: Re: [dtn-interest] DTN BoF Proposal for
> IETF90 Marc, certainly you are correct that taking both paths concurrently
>
> would
>
>  amount to twice as much work, more or less. But we are all individuals,
> all free agents (modulo the interests of our funding sources, for those
>
> of
>
>  those of us who are interested in one of these projects will work on it,
> and those who are not probably won't. I don't think excluding one of
>
> them
>
>  would much improve the effort that gets devoted to the other; rather, I
> think including both could accomplish more in total. Scott -----Original
> Message----- From: Marc Blanchet [mailto:[email-masked]] Sent:
> Monday, May 05, 2014 1:17 PM To: Burleigh, Scott C (312G) Cc:
> [email-masked] Subject: Re: [dtn-interest] DTN BoF Proposal for
> IETF90 Le 2014-05-05 à 12:52, Burleigh, Scott C (312G) <
> [email-masked]> a écrit :
>
> How about doing both? My understanding of Boeing's interest is that they
> are looking for standards to support fairly near-term commercialization of
> the RFC 5050-based technology that we've all gotten a good deal of
> experience with over the past few years. In that context, "fix 5050/BP"
> seems
>
> like
>
>  a good fit for the proposed working group. At the same time, taking up
> the last decade's worth of insight and knowledge and starting over again
> from a blank sheet of paper seems
>
>  like
>
> on "paper", I agree. But I have concerns on people bandwidth to work in
> two working groups. Even the current one has not met for quite some
>
> time.
>
> Scott -----Original Message----- From: dtn-interest [mailto:
> [email-masked]] On Behalf Of Kevin Fall Sent: Monday, May
> 05, 2014 12:03 PM To: Templin, Fred L Cc: [email-masked] Subject:
> Re: [dtn-interest] DTN BoF Proposal for IETF90 I can see a couple of ways
> you might go forward. If you start off as a "fix 5050/BP" you will
> encounter disagreement as to what are problems
>
> and
>
>  Alternatively, you can start somewhat higher level with the notion that
> the area of challenged/DTN/DIL networks is to be addressed with a standard
> protocol (set), that there is now sufficient insight and knowledge thanks
> to DTNRG, and the field is open. There may be
>
>  different
>
>  was/were not a particular driving goal for DTNRG or BP. - Kevin On Mon,
> May 5, 2014 at 11:02 AM, Templin, Fred L <[email-masked]>
> wrote:
>
> Hi Lloyd, I have to say that I mostly agree with Stephen. IMHO, "Bundle of
> Problems" is a very useful document and still applies today, but I see it
> as an actionable problem statement and not an end-of-the-road
> pronouncement. I believe most of the BoP problems can be addressed in an
> RFC5050(bis) and we would tackle this in the initial working group
>
>  work
>
> -----Original Message----- From: dtn-interest [mailto:
> [email-masked]] On Behalf Of [email-masked] Sent:
> Monday, May 05, 2014 12:13 AM To: [email-masked];
> [email-masked] Subject: Re: [dtn-interest] DTN BoF Proposal for
> IETF90 Stephen, I would discourage others from using or building on
> RFC5050, based on our experience in testing the Bundle Protocol in space
> [1], analysing the protocol's failings [2], and a variety of previously
> suggested fixes and drafts in this RG that never went anywhere, which
> aren't published. That's our engineering judgement on RFC5050 as it stands,
> and many long-time readers will be familiar with our arguments. But, as far
> as discussing the proposed WG and a modified RFC5050bis goes: Any protocol
> is simply an artefact that is an outcome of a process by people. It's
> reasonable to have doubts about the same pool of people producing anything
> better in a similar process. If there's a new crowd from Boeing et al with
> relevant expertise and funding/resources/time, that may help. (Or not,
> depending on the learning curve.) Will the putative IETF WG be as wholly
> focused on, say, security? I don't see how having a set of milestones
> magically fixes things that years in this research group, with discussion
> between the interested, did not. I don't see how an RG with failing output
> and limited adoption can be transformed into a WG with successful output
> and widespread (even terrestrial?) adoption, and I have never seen that
> done. (RGs have transformed and mutated into other RGs, with rather varying
> success.) How can a WG with the mandate 'fix the bundle protocol' succeed?
> Is it just being set up to fail? Should it therefore not be set up at all?
> [1] Will Ivancic, Wesley M. Eddy, Dave Stewart, Lloyd Wood, James Northam
> and Chris Jackson, 'Experience with delay-tolerant networking from orbit',
> peer-reviewed journal paper, International Journal of Satellite
> Communications and Networking, special issue for best papers of the Fourth
> Advanced Satellite Mobile Systems Conference (ASMS 2008), vol. 28, issues
> 5-6, pp. 335-351, September-December 2010.
> http://dx.doi.org/10.1002/sat.966
> http://personal.ee.surrey.ac.uk/Personal/L.Wood/publications/ijscn-a s
> ms-bundle-paper-submitted.pdf [2] Lloyd Wood, Wesley M. Eddy and Peter
> Holliday, 'A Bundle of Problems', peer-reviewed conference paper, IEEE
> Aerospace Conference, Big Sky, Montana, March 2009. 16 pages.
> http://dx.doi.org/10.1109/AERO.2009.4839384
> http://personal.ee.surrey.ac.uk/Personal/L.Wood/publications/wood-ie e
> e-aerospace-2009-bundle- problems.pdf Lloyd Wood
> http://sat-net.com/L.Wood/dtn that was a Star Wars reference, btw. May
> the 4th: may the force... ________________________________________ From:
> Stephen Farrell <[email-masked]> Sent: Monday, 5 May 2014 1:46
> AM To: Wood L Dr (Electronic Eng); [email-masked] Subject: Re:
> [dtn-interest] DTN BoF Proposal for IETF90 Lloyd, On 04/05/14 09:19,
> FWIW, my impression is that you'd have a bad feeling about anything
> related to rfc5050 regardless. IMO, it'd be quite reasonable for people to
> disregard quite a bit of what you say on that basis, i.e. that you appear
> to be interested in being destructively critical. That's a pity, since
> there are things to be improved/fixed for which you have argued, and with
> which others agree. Its even more a pity as it somewhat poisons the
> discussion, so I'd ask that if you can, please you try to put aside your
> distaste for rfc5050 and your annoyance at dtnrg history and try
> constructively discuss the proposed IETF wg. S.
> _______________________________________________ dtn-interest mailing list
> [email-masked] https://www.irtf.org/mailman/listinfo/dtn-interest
>
> _______________________________________________ dtn-interest mailing list
> [email-masked] https://www.irtf.org/mailman/listinfo/dtn-interest
>
> _______________________________________________ dtn-interest mailing list
> [email-masked] https://www.irtf.org/mailman/listinfo/dtn-interest_______________________________________________ dtn-interest mailing list
> [email-masked] https://www.irtf.org/mailman/listinfo/dtn-interest
>
> _______________________________________________ dtn-interest mailing list
> [email-masked] https://www.irtf.org/mailman/listinfo/dtn-interest_______________________________________________ dtn-interest mailing list
> [email-masked] https://www.irtf.org/mailman/listinfo/dtn-interest
>

-- 

*The problem with the world is that the intelligent people are full of
doubts, while the stupid ones are full of confidence.*

*
- Charles Bukowski*

---

From: "Burleigh, Scott C (312G)" <[email-masked]>
Date: Thu, 8 May 2014 06:30:19 +0000

Eric, excellent point about where the ends are.  Sure, from the perspective of the convergence layer, the overlying BP agents are the “applications” and the CL endpoints are the “ends”.

More generally, I think the concept of “the ends” is only meaningful in the context of a given layer of the stack.  We typically think of email as an application, but the real “ends” of an email exchange are the human sending the email and the human who reads it when it arrives – if the mail gets mangled somewhere, the human sender is the last-resort retransmission agent.  The email layer below the human sending-an-email layer is typically three consecutive (possibly time-disjoint) contiguous “end-to-end” paths at the application layer: from the SMTP client to the SMTP server, from the SMTP server to a POP server, from the POP server to the POP client.

As I think Salzer, Reed, and Clark were saying, the end-to-end argument is a tool for reasoning about where in the network – at each layer – to locate network functions.  The tool assists thought, it doesn’t replace it.

On your earlier point, the data loss I was talking about was actually between network nodes, not between layers (bundle vs convergence) in the stack at a single node, and I was thinking of R/F noise or IP (for example) congestion loss; that’s why I said “lost due to transmission failure”.  But you’re right, corruption of data as it crossed layer boundaries within a single stack would have the same effect and require the same remedy – just one layer higher.

While I think of it, I also think Vassilis was correct when he wrote that BP is not really an “end-to-end” protocol, any more than IP is: because the data pops up to the bundle/network layer at each router, it sure looks like it’s terminated (and then restarted) at each router.

Scott

From: Eric Travis [mailto:[email-masked]]
Sent: Wednesday, May 07, 2014 10:43 PM
To: Burleigh, Scott C (312G)
Cc: [email-masked]
Subject: Re: [dtn-interest] more on the end-to-end principle

Scott,
Great discussion.

I think we might be one step closer to mutual understanding (and hopefully closure) of how to increase the general utility of the Bundle Protocol.
So while the ultimate responsibility for retransmitting data that are lost due to transmission failure assuredly remains with the source (the end), end-to-end retransmission may take so long that unacceptable delivery latency is introduced.  So we retransmit within the network to make performance acceptable.  We implement in the communication system an incomplete version of the function to enhance performance, while also providing simple mechanisms to support end-to-end retransmission at the application layer (at the ends).

As the failure mode of concern is corruption as data is locally copied between bundle agent and convergence layer,  I would substitute "corrupted" for "lost due to transmission failure", but the thought remains the same...

Given that the end-to-end path for a bundle is a sequence of one or more *end-to-end* transfers between CL entities, and the bundle agents are the "ends" of these transfers - might it not be prudent for to support application layer retransmission (at the ends - bundle agent to bundle agent) for these transfers too?
Regards,
Eric
[email-masked]<mailto:[email-masked]>

On Wed, May 7, 2014 at 12:44 PM, Burleigh, Scott C (312G) <[email-masked]<mailto:[email-masked]>> wrote:

From: dtn-interest [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Gelard Patrick
Sent: Wednesday, May 07, 2014 1:29 AM
To: [email-masked]<mailto:[email-masked]>
Subject: Re: [dtn-interest] DTN BoF Proposal for IETF90

Dear all,

Bests regard
Patrick

Vassilis Tsaoussidis

Dear Fred,

I am grateful for this.

applications.

too.

Yours,

    Carlo Caini

(University of Bologna)

would

of

pool

another:

them

like

like

time.

and

years.

different

which

work

--
The problem with the world is that the intelligent people are full of doubts,
while the stupid ones are full of confidence.
                                                                                  - Charles Bukowski