>>
>>> Just as there is no need for "reliability" at the base of the network, =
>>
>>> there is no need for "location" at the base.
>>
>>------_=_NextPart_001_01C9540E.AB036396
>>Content-Type: text/html;
>> charset="iso-8859-1"
>>Content-Transfer-Encoding: quoted-printable
>>
>>
>>
>>
>>>charset=3Diso-8859-1">
>>>6.5.7653.38">
>>RE: [e2e] a means to an end
>>
>>
>>
>>
>>David,
>>
>>Interesting that he thrust of current IRTF delay-tolerant
>>networking work has effectively turned your statement below
>>on its head, in believing that there is no need for reliability
>>at the top of the network, and no need for location at the top
>>of the network, either.
>>
>>How the network base assures sufficient reliability and assures
>>that endpoint identifiers map to something meaningful would seem
>>to be open problems...
>>
>>L.
>>
>><>HREF=3D"http://www.ee.surrey.ac.uk/Personal/L.Wood/">http://www.ee.surrey=
>>.ac.uk/Personal/L.Wood/><L.Wood at surrey.ac.uk>
>>
>>> Just as there is no need for "reliability" at the base of =
>>the network,
>>> there is no need for "location" at the base.
>>
>>
>>
>>
>>
>>------_=_NextPart_001_01C9540E.AB036396--
cheers
jon
From L.Wood at surrey.ac.uk Tue Dec 2 03:34:56 2008
From: L.Wood at surrey.ac.uk (Lloyd Wood)
Date: Tue, 2 Dec 2008 11:34:56 +0000
Subject: [e2e] a means to an end
In-Reply-To: <49347FD1.6040602@reed.com>
References: <20081201180820.C89C828E155@aland.bbn.com>
<49342B8B.9000801@reed.com>
<4835AFD53A246A40A3B8DA85D658C4BE7B0D7D@EVS-EC1-NODE4.surrey.ac.uk>
<49347FD1.6040602@reed.com>
Message-ID: <382FAE85-DBD0-4AD1-8F01-9AF8F3F45F6A@surrey.ac.uk>
The DTNRG bundle architecture has some recursion in it - nesting of
bundle security blocks to give security in the network, and the
concept of security gateways which effectively do tunnelling by
nesting these blocks. These have had to be reused for reliability and
to enable better performance from the network (allowing nodes check
outer reliability blocks for early resends of corrupted bundles). The
behaviour sans any of these is no reliability or self-checking (of
headers, even)/no security/slow network performance as the minimum.
But there's also layering - the assumption that bundling sits on top
of a network-specific "convergence layer" to traverse each local
subnet (but is somehow unaffected by the properties of said
convergence layers. The desired properties of the convergence layers
are unspecified.)
On induction: what the base case is, and where in layers, is
interesting. Other than 'you can't start in the middle,' it's hard to
say anything concrete about it, given that the computing principle of
'anything can be achieved with a level of indirection' counters
logical induction and following clear properties or behaviour up or
down the stack. The end-to-end principle says the induction of layers
of an unreliable network stack leading to unreliability can be
countered at the topmost layer where reliability is assured e2e as a
level of indirection. Performance is a system behaviour, though, and
visible as an effect of the behaviour of all layers. Naming is
usually handled as indirection at every layer; looking at it through
induction doesn't shed any light.
John Day's _Patterns in Network Architecture_ is big on recursion. I
suppose one could argue that, with layering and indirection, you can
fool most of the others most of the time; when relying on indirection
in a recursive setup, you're only fooling yourself -- so the recursive
architecture has to be better-thought-out.
On 2 Dec 2008, at 00:22, David P. Reed wrote:
> Two thoughts:
>
> Any layering builds from something ... so it's interesting what
> you posit as the base case from which the mathematical induction
> follows.
>
> There is an alternative to layering: constructing a system that
> recurses or contains a looped-back-upon-itself dependency, in which
> case, the resulting behavior can be characterized by the least-fixed-
> point (LFP, result of the Y combinator, or some other formulation)
> of the functional recursion.
>
> I realize these are abstract mathematical concepts, not always
> taught to the kids these days. HTML and Python are thought to be
> verging on too difficult.
>
> Regarding the IRTF DTN stuff: is the system layered or based on a
> least fixed point?
>
>
> L.Wood at surrey.ac.uk wrote:
>>
>> David,
>>
>> Interesting that he thrust of current IRTF delay-tolerant
>> networking work has effectively turned your statement below
>> on its head, in believing that there is no need for reliability
>> at the top of the network, and no need for location at the top
>> of the network, either.
>>
>> How the network base assures sufficient reliability and assures
>> that endpoint identifiers map to something meaningful would seem
>> to be open problems...
>>
>> L.
>>
>>
>>
>> > Just as there is no need for "reliability" at the base of the
>> network,
>> > there is no need for "location" at the base.
>>
DTN work: http://info.ee.surrey.ac.uk/Personal/L.Wood/saratoga/
From dpreed at reed.com Tue Dec 2 10:08:35 2008
From: dpreed at reed.com (David P. Reed)
Date: Tue, 02 Dec 2008 13:08:35 -0500
Subject: [e2e] a means to an end
In-Reply-To: <88634386-C2A3-46D3-8B3B-1B728A9AD0BE@cs.cmu.edu>
References: <20081201165329.6954028E161@aland.bbn.com>
<88634386-C2A3-46D3-8B3B-1B728A9AD0BE@cs.cmu.edu>
Message-ID: <493579A3.6030707@reed.com>
Objects != information. No need to objectify information anymore than
need to objectify women. :-)
Regarding flooding - the alternatives not so black and white as you make
them out to be.
Search can scale rather dramatically, under the same conditions that
routing can scale: when things don't move.
The difference is that search doesn't require that the pre-condition of
static placement be satisfied... a good search strategy adapts its work
effort to conditions.
Instead of flood first, one could do depth-based search from a landmark
near the last appearance known, if given a network that is relatively
static, where things move slowly.
Algorithms are great things. They can be designed to adapt, while still
doing well in simple cases.
So "flooding" seems just a straw man argument made by those who don't
want to consider adaptive algorithms.
David Andersen wrote:
> Interesting discussion. I sense something fundamental here in the
> needles vs. haystack side of things: one can find hay easily without
> needing to embed location at all, b/c you can flood to find it and
> expect to find it soon. For scalability, though, needles need some
> well-defined rendezvous point.
>
> That rendezvous point eventually needs to map to a physical
> realization that stores, at minimum, a mapping that tells you where to
> get the data you're interested in. Or could store the data itself.
>
> This is, of course, assuming that the # of data objects in the
> universe is substantially larger than the # of globally, independently
> routable objects in the universe. Which is probably a reasonable
> assumption for the medium term.
>
> -Dave
>
> On Dec 1, 2008, at 11:53 AM, Craig Partridge wrote:
>
>>
>> Hi Dave:
>>
>> So fine, call it datum or message -- the point is that some things that
>> are desired have a single current instance. That instance may get
>> replicated
>> eventually, or not, depending on context. It may be that you can
>> retrieve something similar from other, more widely available,
>> sources/instances/etc.
>>
>> But you haven't responded to the point I made which is that when you
>> want something that is rare, what I've discovered is all systems to
>> date embed location. If I'm understanding your note, you think I'm
>> saying there's a reference copy/instance that we all must go back to
>> ala the Grail (nope, that's not what I'm saying) or that I'm otherwise
>> intentionally making things rare. Instead I'm saying, when something is
>> rare (1 instance/instantiation/whatever in the world -- and, by the way,
>> I care about such cases as I used to be a medievalist and occasionally
>> was probably the first person to see a document since it was written 700
>> years ago), I've found that every information retrieval system
>> (including
>> Van's) embeds a location.
>>
>> Thanks!
>>
>> Craig
>>
>> In message <49340902.2050400 at reed.com>, "David P. Reed" writes:
>>
>>> Interesting.
>>>
>>> Your presumption that information is a matter of copies, and that "sole
>>> copy" is a well-defined term, suggests a fundamental difference in our
>>> understanding of the word "information".
>>>
>>> Had you used the word "datum" or "message" (two human constructed
>>> concepts), I might agree. But "information" is not a synonym for
>>> either
>>> term. Both are *representations* or *instantiations* of information.
>>>
>>> A piece of paper with a number printed on it may be the "sole instance"
>>> of a printed piece of paper with that particular representation of
>>> information. But if that number represents (say) "the total net value
>>> of my bank account on Dec. 1 2008", it is not at all the only "copy" of
>>> information.
>>>
>>> Information typically exists independent of form or
>>> representation. It
>>> is a constructed, calculated, computed thing. It doesn't exist
>>> independently, nor does it exist in sole form.
>>>
>>> Yes, I could agree with you that if information were forced to exist in
>>> "single copy" form, it would require some complex and amazing procedure
>>> to copy that piece of information into another place. But, once
>>> copied,
>>> it would be smeared across half the universe. (or alternatively you
>>> could decide, since "place" is really not a very easy-to-define term,
>>> that the information is still in one place, but the universe has now
>>> collapsed significantly, because all the places "containing" (whatever
>>> that means) the information would be "the same place").
>>>
>>> But independent of that: why is any information system designed to have
>>> data in a "sole copy"? Van asks this question, and he is wise to ask
>>> this question. Most computer systems work by having vast numbers of
>>> copies of data. We constantly see most information representations used
>>> in computation in the form of cached data.
>>>
>>> It seems to me that it is a pure fetish, perhaps conditioned by
>>> training, to posit that most information is represented by single
>>> copies. That way lies "brittle" failure-prone engineering.
>>>
>>> Let a thousand representations bloom. Many of them will be copies of a
>>> datum. Others will be computable recovery algorithms - some of which
>>> invent an abstraction called "location". But even that abstraction
>>> called location is not a "place" in the sense of a 4 dimensional
>>> spatial
>>> metric based coordinate system. I address a piece of paper by its
>>> title, not its current location in the file folder on someone's desk.
>>>
>>>
>>> Craig Partridge wrote:
>>>>> Our dear friend, Van Jacobsen, has decided that layering "where"
>>>>> under
>>>>> "what" with regard to data is neither necessary, nor a good idea.
>>>>>
>>>>> I agree: confusing the container with the information it happens
>>>>> to hold
>>>>> is a layer violation. Information is not bound to place, nor is
>>>>> there a
>>>>> primary instance. Information is place-free, and perhaps the idea
>>>>> that
>>>>> there must be a "place" where it "is" is an idea whose time should
>>>>> pass,
>>>>> and the purveyors of that idea as a holy writ (the OSI layering)
>>>>> retired
>>>>> to play golf.
>>>>>
>>>>
>>>> Hi Dave:
>>>>
>>>> Much as I'd like to believe this particular theory (as it is nice,
>>>> clean
>>>> and pretty), practical considerations suggest we're not there.
>>>>
>>>> I've talked with some of the folks working on information and seeking
>>>> to make information place-free, and the answer, so far, that I've
>>>> gotten
>>>> is that you get part-way there. If the information is popular or
>>>> "nearby" then there are mechanisms that can be viewed as place-free
>>>> (and
>>>> a good thing -- it means that the more popular a piece of
>>>> information is,
>>>> the easier to get easily and perhaps from somewhere locally).
>>>>
>>>> But if you ask about retrieving an uncommon piece of information then
>>>> you discover "location" crawls out from under the covers. That is,
>>>> if you ask the question "where do I find the sole copy of item X", you
>>>> learn that somewhere hidden in the name of X is a location -- perhaps
>>>> of X or perhaps of a rendezvous server that knows where X is -- but
>>>> there's the location of something buried in there.
>>>>
>>>> Thanks!
>>>>
>>>> Craig
>>>>
>>>>
>>
>