Re: [dtn-interest] DTN BoF Proposal for IETF90

<l.wood@surrey.ac.uk> Sat, 03 May 2014 00:50 UTC

Return-Path: <l.wood@surrey.ac.uk>
X-Original-To: dtn-interest@ietfa.amsl.com
Delivered-To: dtn-interest@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F25851A7023 for <dtn-interest@ietfa.amsl.com>; Fri, 2 May 2014 17:50:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.947
X-Spam-Level:
X-Spam-Status: No, score=-2.947 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, UNRESOLVED_TEMPLATE=1.252] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N2Z-lugxzvIS for <dtn-interest@ietfa.amsl.com>; Fri, 2 May 2014 17:50:52 -0700 (PDT)
Received: from mail1.bemta14.messagelabs.com (mail1.bemta14.messagelabs.com [193.109.254.116]) by ietfa.amsl.com (Postfix) with ESMTP id 676841A701B for <dtn-interest@irtf.org>; Fri, 2 May 2014 17:50:51 -0700 (PDT)
Received: from [193.109.255.147:34813] by server-12.bemta-14.messagelabs.com id D6/E0-27473-86D34635; Sat, 03 May 2014 00:50:48 +0000
X-Env-Sender: l.wood@surrey.ac.uk
X-Msg-Ref: server-16.tower-72.messagelabs.com!1399078247!9672768!1
X-Originating-IP: [131.227.200.31]
X-StarScan-Received:
X-StarScan-Version: 6.11.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9181 invoked from network); 3 May 2014 00:50:47 -0000
Received: from exht011p.surrey.ac.uk (HELO EXHT011P.surrey.ac.uk) (131.227.200.31) by server-16.tower-72.messagelabs.com with AES128-SHA encrypted SMTP; 3 May 2014 00:50:47 -0000
Received: from EXHY012V.surrey.ac.uk (131.227.201.103) by exht011p.surrey.ac.uk (131.227.200.31) with Microsoft SMTP Server (TLS) id 8.3.348.2; Sat, 3 May 2014 01:50:46 +0100
Received: from va3outboundpool.messaging.microsoft.com (131.227.201.241) by EXHY012v.surrey.ac.uk (131.227.201.103) with Microsoft SMTP Server (TLS) id 14.3.174.1; Sat, 3 May 2014 01:50:45 +0100
Received: from mail157-va3-R.bigfish.com (10.7.14.248) by VA3EHSOBE004.bigfish.com (10.7.40.24) with Microsoft SMTP Server id 14.1.225.22; Sat, 3 May 2014 00:50:44 +0000
Received: from mail157-va3 (localhost [127.0.0.1]) by mail157-va3-R.bigfish.com (Postfix) with ESMTP id 8E0C940236 for <dtn-interest@irtf.org.FOPE.CONNECTOR.OVERRIDE>; Sat, 3 May 2014 00:50:44 +0000 (UTC)
X-Forefront-Antispam-Report: CIP:157.56.248.85; KIP:(null); UIP:(null); (null); H:AMSPRD0610HT003.eurprd06.prod.outlook.com; R:internal; EFV:INT
X-SpamScore: -27
X-BigFish: PS-27(zz98dI9371I103dKc85ehd799hdb82hdbb0izz1f42h1ee6h1de0h1d18h1fdah2073h2146h1202h1e76h2189h1d1ah1d2ah21bch21a7h1fc6h208chzz1d7338h1de098h1033IL17326ah8275bh8275dh18c673h1de097h186068h5eeeKz2fh109h2a8h839he5bhf0ah1288h12a5h12bdh137ah1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah1bceh224fh1d0ch1d2eh1d3fh1dfeh1dffh1fe8h1ff5h20f0h2216h22d0h2336h2438h2461h2487h24ach24d7h2516h2545h255eh25cch25f6h2605h268bh26d3h27e2h)
Received-SPF: pass (mail157-va3: domain of surrey.ac.uk designates 157.56.248.85 as permitted sender) client-ip=157.56.248.85; envelope-from=l.wood@surrey.ac.uk; helo=AMSPRD0610HT003.eurprd06.prod.outlook.com ; .outlook.com ;
X-Forefront-Antispam-Report-Untrusted: SFV:NSPM; SFS:(10009001)(428001)(24454002)(243025003)(199002)(189002)(41574002)(377454003)(77982001)(16236675002)(20776003)(64706001)(15975445006)(79102001)(36756003)(19300405004)(46102001)(76482001)(87936001)(2656002)(81542001)(561944002)(80976001)(81342001)(4396001)(83322001)(19580405001)(19580395003)(92566001)(86362001)(101416001)(15202345003)(92726001)(21056001)(99396002)(31966008)(74502001)(80022001)(66066001)(551934002)(54356999)(50986999)(77096999)(85852003)(76176999)(74482001)(74662001)(83072002)(562404015); DIR:OUT; SFP:1101; SCL:1; SRVR:AMSPR06MB437; H:AMSPR06MB439.eurprd06.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; A:1; MX:1; LANG:en;
Received: from mail157-va3 (localhost.localdomain [127.0.0.1]) by mail157-va3 (MessageSwitch) id 1399078240110786_15198; Sat, 3 May 2014 00:50:40 +0000 (UTC)
Received: from VA3EHSMHS030.bigfish.com (unknown [10.7.14.245]) by mail157-va3.bigfish.com (Postfix) with ESMTP id 100DA480047; Sat, 3 May 2014 00:50:40 +0000 (UTC)
Received: from AMSPRD0610HT003.eurprd06.prod.outlook.com (157.56.248.85) by VA3EHSMHS030.bigfish.com (10.7.99.40) with Microsoft SMTP Server (TLS) id 14.16.227.3; Sat, 3 May 2014 00:50:39 +0000
Received: from AMSPR06MB437.eurprd06.prod.outlook.com (10.242.23.11) by AMSPRD0610HT003.eurprd06.prod.outlook.com (10.255.43.38) with Microsoft SMTP Server (TLS) id 14.16.453.0; Sat, 3 May 2014 00:50:38 +0000
Received: from AMSPR06MB439.eurprd06.prod.outlook.com (10.242.23.19) by AMSPR06MB437.eurprd06.prod.outlook.com (10.242.23.11) with Microsoft SMTP Server (TLS) id 15.0.934.12; Sat, 3 May 2014 00:50:36 +0000
Received: from AMSPR06MB439.eurprd06.prod.outlook.com ([10.242.23.19]) by AMSPR06MB439.eurprd06.prod.outlook.com ([10.242.23.19]) with mapi id 15.00.0934.000; Sat, 3 May 2014 00:50:36 +0000
From: l.wood@surrey.ac.uk
To: eric.dot.travis@gmail.com
Thread-Topic: [dtn-interest] DTN BoF Proposal for IETF90
Thread-Index: Ac9jLllZ/BuVVBGESGyzo/WS7FMKUQA7ue50AABbj4AAAzjugAARpscAAFe8hQAAA+OxhQAXg8YAAAorjAQ=
Date: Sat, 03 May 2014 00:50:35 +0000
Message-ID: <1399078235070.7092@surrey.ac.uk>
References: <CAKovV0yoYztDz=6SVw_F2b5S-2OTay3CawgbtYFh=oT53vteAA@mail.gmail.com> <CF866276.161F8%william.d.ivancic@nasa.gov> <CAKovV0zTb7tMLkhUcmqXy=VBdpkovWEfag36TCwBa4CZHvacfg@mail.gmail.com> <1399019890507.11208@surrey.ac.uk>, <CAKovV0yds5EMtLsXk3CTUDZP9TKuL8ce42naJ72rdL5VfhcTHQ@mail.gmail.com>
In-Reply-To: <CAKovV0yds5EMtLsXk3CTUDZP9TKuL8ce42naJ72rdL5VfhcTHQ@mail.gmail.com>
Accept-Language: en-AU, en-US
Content-Language: en-AU
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [122.200.59.254]
x-forefront-prvs: 0200DDA8BE
Content-Type: multipart/alternative; boundary="_000_13990782350707092surreyacuk_"
MIME-Version: 1.0
X-OrganizationHeadersPreserved: AMSPR06MB437.eurprd06.prod.outlook.com
X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn%
X-FOPE-CONNECTOR: Id%13190$Dn%GMAIL.COM$RO%2$TLS%5$FQDN%email365.surrey.ac.uk$TlsDn%*.surrey.ac.uk
X-FOPE-CONNECTOR: Id%13190$Dn%IRTF.ORG$RO%2$TLS%5$FQDN%email365.surrey.ac.uk$TlsDn%*.surrey.ac.uk
X-CrossPremisesHeadersFiltered: EXHY012v.surrey.ac.uk
Archived-At: http://mailarchive.ietf.org/arch/msg/dtn-interest/XOy9c2oHTttrhWfAw0LBKwe2w4Y
Cc: dtn-interest@irtf.org
Subject: Re: [dtn-interest] DTN BoF Proposal for IETF90
X-BeenThere: dtn-interest@irtf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "The Delay-Tolerant Networking Research Group \(DTNRG\) - Announce." <dtn-interest.irtf.org>
List-Unsubscribe: <https://www.irtf.org/mailman/options/dtn-interest>, <mailto:dtn-interest-request@irtf.org?subject=unsubscribe>
List-Archive: <http://www.irtf.org/mail-archive/web/dtn-interest/>
List-Post: <mailto:dtn-interest@irtf.org>
List-Help: <mailto:dtn-interest-request@irtf.org?subject=help>
List-Subscribe: <https://www.irtf.org/mailman/listinfo/dtn-interest>, <mailto:dtn-interest-request@irtf.org?subject=subscribe>
X-List-Received-Date: Sat, 03 May 2014 00:50:57 -0000

" I imagine that CCSDS is "trying to standardize the thing" because some  member agencies are interested in using it and want to have an expectation of interoperable cross-support service. "


A more conservative estimate would say that part of one member agency is interested in using it.


" I haven't paid attention to CCSDS activities in over a decade,"


well, yes.


"a push within part NASA to "standardize" ethernet., a similar push to "standardize" HDLC."


HDLC is ISO 13239. CCSDS is effectively an ISO subgroup (ISO TC20/SC13), and it's always been interesting how reluctant CCSDS is to adopt this ISO standard or have it work with its own nominally-ISO standards. But then, isn't the US still using footpounds rather than that ISO metric stuff? And CCSDS is US-driven. When I think of the bundle protocol being used for DTN mules I think of furlongs per fortnight.


Avionics ethernet falls under AFDX Ethernet and under ARINC<http://en.wikipedia.org/wiki/ARINC> Specification 664 Part 7 - no NASA involvement there either.


A better analogy is with SCPS, the push within NASA to standardise TCP/IP, while 'improving' it enough to make it incompatible. But really, you're talking about adoption; getting new technology onboard space missions is just plain hard, whether it's a standard or not.


I regret telling Adrian to leverage spacecraft clocks for expiry times while I was secretary of the IPN.



Lloyd Wood
http://sat-net.com/L.Wood/dtn
________________________________
From: Eric Travis <eric.dot.travis@gmail.com>
Sent: Saturday, 3 May 2014 5:43 AM
To: Wood L Dr (Electronic Eng)
Cc: dtn-interest@irtf.org
Subject: Re: [dtn-interest] DTN BoF Proposal for IETF90

Lloyd,

Wonderful to hear from you.  I'd been expecting your reply.

I do hope you get your game back soon, as you merely phoned in this effort.


No?


http://public.ccsds.org/publications/documents/SO2002/SPACEOPS02_P_T5_22.PDF

No.

You typed "CFDP IPN" into a search engine and this came up (4th in result list for me)

This paper was new to me, so thanks!

Did you actually read Scott's paper?

Read the text that you quoted below again, heck read the whole paper - or start at page 4.

So, still No.

CFDP will in effect serve as a
prototype for the future Interplanetary Internet
(IPN) as envisioned by the IPN Study team: it en-
compasses a subset of the anticipated functionality of
the IPN, and it implements several key IPN design
concepts including store-and-forward operation with
deferred transmission and
concurrent transactions.

-- Burleigh,
OPERATING CFDP IN THE INTERPLANETARY INTERNET


SpaceOps 2002, I believe.

Doesn't support your assertion,  I know.

So, yes - it really is No.



"Much of Bundling always been space centric":


 which would be why CCSDS is trying to standardise the thing.

 I imagine that CCSDS is "trying to standardize the thing" because some  member agencies are interested in using it and want to have an expectation of interoperable cross-support service.  I haven't paid attention to CCSDS activities in over a decade, but remember there was a push within part NASA to "standardize" ethernet., a similar push to "standardize" HDLC. I also know there was a working group for standardizing the encapsulating of IP datagrams in in CCSDS frames.  By your argument, the motivation was because ethernet, HDLC and IPv4 are all "space centric".

"The defining characteristics underlying the IPN was the assumption that the problem space could *not* depend  on ubiquitous infrastructure (power, communications) "

ubiquitous clocks were in there from the start. ubiquitous perfect comms and storage reliability was assumed.

Finally! - you are absolutely correct… unless you are referring to the IPN rather than DTN.

Ubiquitous clocks:  As I stated in my previous message, the vision was that one brings the infrastructure with them.  If you need synchronized clocks you bring it with you.  Spacecraft tend to have excellent clocks - within the IPN time was envisioned to be provided as a network service (with proximate spacecraft serving as the local timebase).  If you were deploying in a cave and needed synchronized time for operations, you bring that infrastructure with you. Expiration times in bundles are even *more* beyond the scope of this thread, so if you wanted to present them as proof of your position, you would still be WRONG.

Ubiquitous perfect comms and storage reliability assumed: Wrong again.  I'm getting tired, so - Mandatory integrity checking was lost in the transition from IPN to DTN (it had been rolled into mutual suspicion of nodes).

Now,  am I try to correct you regarding the origins and assumptions of underlying Saratoga?
Alternatively, I've been having some questions about my 5th birthday party that you could probably resolve...


No bile, little obvious sarcasm, nothing burying an intelligent insight or observation.

Simply not your best effort.

Do feel better Lloyd.

Regards,

Eric
eric.dot.travis@gmail.com<mailto:eric.dot.travis@gmail.com>



On Fri, May 2, 2014 at 4:38 AM, <l.wood@surrey.ac.uk<mailto:l.wood@surrey.ac.uk>> wrote:

No?


http://public.ccsds.org/publications/documents/SO2002/SPACEOPS02_P_T5_22.PDF


CFDP will in effect serve as a
prototype for the future Interplanetary Internet
(IPN) as envisioned by the IPN Study team: it en-
compasses a subset of the anticipated functionality of
the IPN, and it implements several key IPN design
concepts including store-and-forward operation with
deferred transmission and
concurrent transactions.

-- Burleigh,
OPERATING CFDP IN THE INTERPLANETARY INTERNET


SpaceOps 2002, I believe.


"Much of Bundling always been space centric":


 which would be why CCSDS is trying to standardise the thing.


"The defining characteristics underlying the IPN was the assumption that the problem space could *not* depend  on ubiquitous infrastructure (power, communications) "


ubiquitous clocks were in there from the start. ubiquitous perfect comms and storage reliability was assumed.


Lloyd Wood
http://sat-net.com/L.Wood/dtn
________________________________
From: dtn-interest <dtn-interest-bounces@irtf.org<mailto:dtn-interest-bounces@irtf.org>> on behalf of Eric Travis <eric.dot.travis@gmail.com<mailto:eric.dot.travis@gmail.com>>
Sent: Friday, 2 May 2014 4:38 PM
To: Ivancic, William D. (GRC-RHN0)
Cc: dtn-interest@irtf.org<mailto:dtn-interest@irtf.org>

Subject: Re: [dtn-interest] DTN BoF Proposal for IETF90

Will,

I'm a bit confused - which has caused me to pause prior to responding.

A few days ago in this thread, you expressed a concern about scalability:

Also, if we are talking large scale deployments, we really need to address
scalability.  To start with, I know some where investigating use of DTN
for thousands to tens of thousands of units.
Then in advocating an example for the need for bundle authentication mechanisms, you espoused possibly the least
scalable *policy* for using authentication.

In response to my subsequent blathering (not recopied, but available below), you reply:

It seems like this assumes a closed system and thus, scaling is not all that much of a consideration relative to a global or universal deployment.

However, your "I'm not about to let just anyone use my truck" example that led to my response was hardly advocating an "open" access policy... So, I suppose I am to take the quoted text to mean that there is no scalability issue with authentication?

I simply don't understand (nor can I agree to) for "closed" networks/systems, scaling is not all that much of a consideration relative to a global or universal deployment).

Hence, I am confused and curious, but more than willing to simply agree to disagree - with whatever happens to be the argument.
OK, so we're done with that.


Transitioning to the non-sequitur part of your message:

Much of Bundling has, IMHO, always been very space centric.   Understandably so, as it did start as Interplanetary Network (IPN) with origins in CFDP.
http://public.ccsds.org/publications/archive/720x1g3.pdf
http://public.ccsds.org/publications/documents/SO2002/SPACEOPS02_P_T5_22.PDF

No.

and

No.


Addressing the Second No first - IPN/Bundling did NOT have its origins with CFDP.

You meant that  the Licklider Transmission Protocol (LTP) has its origins in CFDP. As I remember, LTP was influenced by and ultimately can (/does?) replace the "lower half" of CFDP. I *think* BP over LTP can be used in place of CFDP, but wouldn't trust that equivalence
to be correct.

Certainly CFDP experience influenced at least one of the IPN team members, but within the group, larger influences on the conceptual development of Bundling included SMTP, NNTP, UUCP - as well as the evolution of the US Postal Service (the Pony Express dominated discussions in the very earliest meetings).

http://www.ietf.org/rfc/rfc2821.txt
http://www.ietf.org/rfc/rfc3977.txt
https://www.ietf.org/rfc/rfc976
https://www.usps.com

All of which can be considered space centric.



Leading to the First No - "Much of Bundling always been space centric":

IPN leaf nodes (in situ networks) performing geological surveys while rolling around on a distant (extra-terrestrial) rock or floating atop the Bering Sea were considered equally valid and part of the same problem space.  If you mean to equate "space centric" with "not directly/permanently connected with the terrestrial internet", then your assumption is correct (IMHO).

(Speaking only for *myself*, not anyone else involved with the IPN study)

The defining characteristics underlying the IPN was the assumption that the problem space could *not* depend  on ubiquitous infrastructure (power, communications) - whatever infrastructure was required (including time synchronization) was to be provided
by the network itself. Nor could one assume the ultimate endpoints of communications would be supporting identical/pairwise-compatible communications stacks.   (At one point, there were Ten Commandments regarding IPN assumptions, but the above works for this discussion)

The concept did indeed start with the desire to lay the groundwork for supporting the eventual deployment  of IP-based networks as part of the exploration of the Solar System - so I concede that is a "space centric" goal.

The underlying "Interplanetary" meme provided a non-threatening backdrop to consider different ways of doing things.  This is analogous to the way Science Fiction has been used as a non-threatening means for exploring social issues.

The context for the IPN (and bundling) could just have easily been a terrestrial environment where nations start deploying national internets, each with their own naming/addressing systems and some with home-grown networking stacks (network and transport protocols).  Anticipating the deploying chunks of the Internet on and around remote rocks and snowballs was a much more fun/attractive playground.

Fanciful > Distopian.

There has never been anything in bundling mechanisms (IPN or DTN) that was "space centric". Space applicable, but not space centric.


But, once this hit DTRNG, I think the hope was to make this more universal, which opened up a complete new user space and expectations.  However, to date, the terrestrial users have not found the protocol, as is, very deployable.  Space is a much smaller and much simpler deployment environment.  In many ways, Space  is very small and extremely predictable.

Strangely, my feeling has been that, over time, DTN became MORE "space centric" than IPN.   Opportunistic connectivity seemed to be deprecated for deterministic connectivity, communications & storage components are considered to be more fault-tolerant and there seemed to be an increased reliance of infrastructure (universal clock synchronization via GPS or NTP). Consideration has seemed to favor deployments into rather controlled environments. Publication of RFC 5050 seemed to serve as a lock on Bundling development rather than being a stable checkpoint.  These are all simply my perceptions, but over time DTN tended to get less interesting (to me).

Actually, space is *very* large, but the space exploration environment is a lot better curated than a random terrestrial deployment. When deploying in the space exploration environment one is able to leverage off of a LOT of engineering and coordination.  The fact that you depict space a "simpler deployment environment" is a terrific illustration of this.

I'm far from the biggest fan of RFC-5050, but could someone please articulate what it is about the "protocol" that terrestrial users are finding "not very deployable"?   Once upon a time, I put up a few DTN2 nodes and didn't find it any more frustrating than deploying Apache or XMPP...



Regards,

Eric
eric.dot.travis@gmail.com<mailto:eric.dot.travis@gmail.com>


On Wed, Apr 30, 2014 at 8:46 AM, Ivancic, William D. (GRC-RHN0) <william.d.ivancic@nasa.gov<mailto:william.d.ivancic@nasa.gov>> wrote:
In Line

From: Eric Travis <eric.dot.travis@gmail.com<mailto:eric.dot.travis@gmail.com>>
Date: Wednesday, April 30, 2014 12:20 AM
To: William Ivancic <william.d.ivancic@nasa.gov<mailto:william.d.ivancic@nasa.gov>>
Cc: "l.wood@surrey.ac.uk<mailto:l.wood@surrey.ac.uk>" <l.wood@surrey.ac.uk<mailto:l.wood@surrey.ac.uk>>, "stephen.farrell@cs.tcd.ie<mailto:stephen.farrell@cs.tcd.ie>" <stephen.farrell@cs.tcd.ie<mailto:stephen.farrell@cs.tcd.ie>>, "Burleigh, Scott C (JPL-312G)[Jet Propulsion Laboratory]" <scott.c.burleigh@jpl.nasa.gov<mailto:scott.c.burleigh@jpl.nasa.gov>>, "dtn-interest@irtf.org<mailto:dtn-interest@irtf.org>" <dtn-interest@irtf.org<mailto:dtn-interest@irtf.org>>

Subject: Re: [dtn-interest] DTN BoF Proposal for IETF90


Will,

Are you suggesting that the (originating) sender should be validated at each
transfer point (from Bob's truck to my truck to your truck)?

Not necessarily every transfer point, just transfer points that care.


If this is even possible,
it certainly won't scale.

Nor is it enforceable: What if Stephen enters into a secret side agreement with Lloyd to encapsulate bundles?

If they have such an agreement, I don't know that I care.


Way back in the days of the IPN (presumably back in the time "before
gaining experience with reality" - nod to Lloyd), we used to talk about
admissions control...  The bundle sender was to be verified at the entry
bundle portal. Only authorized sources could submit bundles.   As bundle
nodes were to be "mutually suspicious" [1], the interacting bundle nodes would
validate each other (at each contact episode) prior to exchanging bundles,
but  bundles would travel between nodes w/o requiring subsequent individual
source verifications (though there was to be a mandatory integrity check to verify
a content of the bundle was not altered by the intermediate "sending" node).

It seems like this assumes a closed system and thus, scaling is not all that much of a consideration relative to a global or universal deployment.
Much of Bundling has, IMHO, always been very space centric.   Understandably so, as it did start as Interplanetary Network (IPN) with origins in CFDP.
http://public.ccsds.org/publications/archive/720x1g3.pdf
http://public.ccsds.org/publications/documents/SO2002/SPACEOPS02_P_T5_22.PDF


But, once this hit DTRNG, I think the hope was to make this more universal, which opened up a complete new user space and expectations.  However, to date, the terrestrial users have not found the protocol, as is, very deployable.  Space is a much smaller and much simpler deployment environment.  In many ways, Space  is very small and extremely predictable.


Once the bundle was "in the system", there was no need to validate the source
of bundles in transit.

Rather than "not letting just anybody use your truck", you don't let just any
other truck driver offload it's contents into your truck.  Truck drivers are not
permitted to accept freight from unauthorized customers.

Thus, assumes a closed network.  No?






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




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