From Jon.Crowcroft at cl.cam.ac.uk Tue Nov 4 07:57:57 2008 From: Jon.Crowcroft at cl.cam.ac.uk (Jon Crowcroft) Date: Tue, 04 Nov 2008 15:57:57 +0000 Subject: [e2e] a means to an end Message-ID: so a lot of IANG (Internet Arch Ng) work is on addressing - and a lot of nice work has come out on how to do secured id+loc split in terms of requirements and technologies on the address space... there's all the usual reasons for doin this split (seamless mobility, with transport doin its thing on the id part only; multicast; multihome; multipath; etc) but, BUT this is sidestepping the big problem which is to have a service which hosts the id<->loc mapping, which actually scales to the size of the expected workload... such a service has to suport at least the scale of the cellular nets service which tracks 4billion phones so that calls are routed to the right place (across multiple providers) and calls roam in real time - so scale and update rate for such a service is something that doesn't look like DNS or BGP .... such a system faces both the user and the routing system which is an unusual system too in terms of security requirements & snakeholder analysis one thing that occurs to me is that such a system needs to have a very wide operating range and so is almost certainyl data driven - indeed, perhaps it is the first and foremost data driven application that we should be building as an internet service substrate if you want to be reductionist, it looks like a fully distributed NAT management control plane From swb at employees.org Tue Nov 4 11:36:54 2008 From: swb at employees.org (Scott Brim) Date: Tue, 04 Nov 2008 14:36:54 -0500 Subject: [e2e] a means to an end In-Reply-To: References: Message-ID: <4910A456.6030700@employees.org> On 11/4/08 10:57 AM, Jon Crowcroft allegedly wrote: > so a lot of IANG (Internet Arch Ng) > work is on addressing - > > and a lot of nice work > has come out on how to do secured > id+loc split > in terms of requirements and technologies > on the address space... > > there's all the usual reasons for doin this split > (seamless mobility, with transport doin its thing on the id > part only; multicast; multihome; multipath; etc) > > but, BUT this is sidestepping the big problem > which is to have a service which hosts the > id<->loc mapping, which actually > scales to the size of the expected workload... Jon: Why do you think that is necessary at all? There are two uses for identifiers: (1) to find things in the first place and (2) for AAA for sessions once nodes have been located. For (1), to find things in the first place, you do not need to know exactly where they are at all points in time, you can use another level of indirection: a rendezvous point that knows where they are. MIP6, for example, provides this in its home agent, without any special id->loc mapping server (unless you consider the HA itself to be a mapping server). You *could* have a central mapping system that everyone updates, but having another level of indirection, e.g. DNS -> HA -> MN, makes everything more robust and places the operational burden on the nodes that benefit. Also, persistent rendezvous points may be generally useful idea for all initial contacts, because that way some policy can be invoked at the rendezvous point (for example routing you to voicemail), and for those packets that are forwarded to the target node, the node itself gets to decide whether and how to respond. For (2), ongoing sessions, you do not need any central server. You need mechanisms for initially authenticating identifiers and possibly re-authenticating, but not an id-loc mapping server. Finally, I don't see any use for a server for mapping in the opposite direction, from locator to identifier, although your "<->" implies you want one. If you want to know what is at a particular location, it is better to require you to ask it directly. The node in question might consider some identifiers to be privileged information, and not be willing to give them away to anyone querying a locator in general. Also there can be many identifiers in use for a particular locator, and many of them will be transient. What is the point of a third party service for this? So I question your assumptions. Come to Minneapolis and let's talk about it :-). Scott From Jon.Crowcroft at cl.cam.ac.uk Wed Nov 5 01:48:46 2008 From: Jon.Crowcroft at cl.cam.ac.uk (Jon Crowcroft) Date: Wed, 05 Nov 2008 09:48:46 +0000 Subject: [e2e] a means to an end In-Reply-To: <4910A456.6030700@employees.org> References: <4910A456.6030700@employees.org> Message-ID: the "level of indirection" is exactly what I am talking about but noone appears to be designing a service that implements this with a view to the workload (including secure update rate) it should sustain. the two way mapping is needed because of audit/accountability trails In missive <4910A456.6030700 at employees.org>, Scott Brim typed: >>On 11/4/08 10:57 AM, Jon Crowcroft allegedly wrote: >>> so a lot of IANG (Internet Arch Ng) >>> work is on addressing - >>> >>> and a lot of nice work >>> has come out on how to do secured >>> id+loc split >>> in terms of requirements and technologies >>> on the address space... >>> >>> there's all the usual reasons for doin this split >>> (seamless mobility, with transport doin its thing on the id >>> part only; multicast; multihome; multipath; etc) >>> >>> but, BUT this is sidestepping the big problem >>> which is to have a service which hosts the >>> id<->loc mapping, which actually >>> scales to the size of the expected workload... >> >>Jon: Why do you think that is necessary at all? >> >>There are two uses for identifiers: (1) to find things in the first >>place and (2) for AAA for sessions once nodes have been located. >> >>For (1), to find things in the first place, you do not need to know >>exactly where they are at all points in time, you can use another level >>of indirection: a rendezvous point that knows where they are. MIP6, for >>example, provides this in its home agent, without any special id->loc >>mapping server (unless you consider the HA itself to be a mapping >>server). You *could* have a central mapping system that everyone >>updates, but having another level of indirection, e.g. DNS -> HA -> MN, >>makes everything more robust and places the operational burden on the >>nodes that benefit. Also, persistent rendezvous points may be generally >>useful idea for all initial contacts, because that way some policy can >>be invoked at the rendezvous point (for example routing you to >>voicemail), and for those packets that are forwarded to the target node, >>the node itself gets to decide whether and how to respond. >> >>For (2), ongoing sessions, you do not need any central server. You need >>mechanisms for initially authenticating identifiers and possibly >>re-authenticating, but not an id-loc mapping server. >> >>Finally, I don't see any use for a server for mapping in the opposite >>direction, from locator to identifier, although your "<->" implies you >>want one. If you want to know what is at a particular location, it is >>better to require you to ask it directly. The node in question might >>consider some identifiers to be privileged information, and not be >>willing to give them away to anyone querying a locator in general. Also >>there can be many identifiers in use for a particular locator, and many >>of them will be transient. What is the point of a third party service >>for this? >> >>So I question your assumptions. Come to Minneapolis and let's talk >>about it :-). >> >>Scott cheers jon From ali at sics.se Wed Nov 5 04:26:06 2008 From: ali at sics.se (Ali Ghodsi) Date: Wed, 05 Nov 2008 13:26:06 +0100 Subject: [e2e] a means to an end In-Reply-To: References: Message-ID: <491190DE.7010706@sics.se> Jon Crowcroft wrote: > but, BUT this is sidestepping the big problem > which is to have a service which hosts the > id<->loc mapping, which actually > scales to the size of the expected workload... > Can DHTs be part of the solution, and if not, what are the essential features which they are lacking? (trying to fish for research problems) Regards, Ali From michael.welzl at uibk.ac.at Thu Nov 6 10:11:28 2008 From: michael.welzl at uibk.ac.at (Michael Welzl) Date: Thu, 06 Nov 2008 19:11:28 +0100 Subject: [e2e] a means to an end In-Reply-To: <491190DE.7010706@sics.se> References: <491190DE.7010706@sics.se> Message-ID: <1225995088.3733.231.camel@pc105-c703.uibk.ac.at> On Wed, 2008-11-05 at 13:26 +0100, Ali Ghodsi wrote: > Jon Crowcroft wrote: > > but, BUT this is sidestepping the big problem > > which is to have a service which hosts the > > id<->loc mapping, which actually > > scales to the size of the expected workload... > > > Can DHTs be part of the solution, and if not, what are the essential > features which they are lacking? (trying to fish for research problems) Location dependance, which even the "id" part should have (at least in the form of some concept of "nearness"). This was pointed out quite convincingly (IMO) by John Day in his "patterns in network architecture" book. Cheers, Michael From dpreed at reed.com Thu Nov 6 12:06:07 2008 From: dpreed at reed.com (David P. Reed) Date: Thu, 06 Nov 2008 15:06:07 -0500 Subject: [e2e] a means to an end In-Reply-To: <1225995088.3733.231.camel@pc105-c703.uibk.ac.at> References: <491190DE.7010706@sics.se> <1225995088.3733.231.camel@pc105-c703.uibk.ac.at> Message-ID: <49134E2F.8010704@reed.com> Why should "location" be relevant to networking? Must all wires be buried permanently in the ground? Does wireless and mobility not occur? Michael Welzl wrote: > On Wed, 2008-11-05 at 13:26 +0100, Ali Ghodsi wrote: > >> Jon Crowcroft wrote: >> >>> but, BUT this is sidestepping the big problem >>> which is to have a service which hosts the >>> id<->loc mapping, which actually >>> scales to the size of the expected workload... >>> >>> >> Can DHTs be part of the solution, and if not, what are the essential >> features which they are lacking? (trying to fish for research problems) >> > > Location dependance, which even the "id" part should > have (at least in the form of some concept of "nearness"). > > This was pointed out quite convincingly (IMO) by John Day > in his "patterns in network architecture" book. > > Cheers, > Michael > > > > From craig at aland.bbn.com Thu Nov 6 12:52:04 2008 From: craig at aland.bbn.com (Craig Partridge) Date: Thu, 06 Nov 2008 15:52:04 -0500 Subject: [e2e] a means to an end In-Reply-To: Your message of "Thu, 06 Nov 2008 15:06:07 EST." <49134E2F.8010704@reed.com> Message-ID: <20081106205204.CCE5D28E155@aland.bbn.com> In message <49134E2F.8010704 at reed.com>, "David P. Reed" writes: >Why should "location" be relevant to networking? Must all wires be >buried permanently in the ground? Does wireless and mobility not occur? I think it is easier to see the merit of location when one thinks about retrieving data. You need some clue as to where the data is. Craig From dpreed at reed.com Thu Nov 6 13:20:42 2008 From: dpreed at reed.com (David P. Reed) Date: Thu, 06 Nov 2008 16:20:42 -0500 Subject: [e2e] a means to an end In-Reply-To: <20081106205204.CCE5D28E155@aland.bbn.com> References: <20081106205204.CCE5D28E155@aland.bbn.com> Message-ID: <49135FAA.6080603@reed.com> 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. Craig Partridge wrote: > In message <49134E2F.8010704 at reed.com>, "David P. Reed" writes: > > >> Why should "location" be relevant to networking? Must all wires be >> buried permanently in the ground? Does wireless and mobility not occur? >> > > I think it is easier to see the merit of location when one thinks about > retrieving data. You need some clue as to where the data is. > > Craig > > From dpreed at reed.com Thu Nov 6 13:29:29 2008 From: dpreed at reed.com (David P. Reed) Date: Thu, 06 Nov 2008 16:29:29 -0500 Subject: [e2e] a means to an end In-Reply-To: <04EC169B-5D71-427D-989F-E41FE30BEB9E@cisco.com> References: <491190DE.7010706@sics.se> <1225995088.3733.231.camel@pc105-c703.uibk.ac.at> <49134E2F.8010704@reed.com> <04EC169B-5D71-427D-989F-E41FE30BEB9E@cisco.com> Message-ID: <491361B9.2030506@reed.com> The original "six degrees of separation" experiment showed that networks can route messages without being told "where". The only argument is one of efficiency, and that argument only applies when a) nothing moves very fast, and b) the sender can be assumed to know "where". Let's say I have a message for all Republicans. I can send that message quite reliably, without ever knowing "where" the set of all Republicans is. In fact, it's a feature that I can do that. What's particularly nice is that in some cases, it is far *more* efficient to do that than to "first, find the locations of all Republicans" and "second, deliver the message to that set of locations". Maintaining a complex location set as an intermediate computed value seems like it would cost a lot more than just telling each Republican I know to pass the message to any Republicans he/she knows. OK, OK. that's not communications - because only the holy scripture of the Cisco router defines "real" communications. :-) They have a patent on it, which they license to their IETF. Fred Baker wrote: > It's kind of hard to get a message to a destination, fixed or mobile, > without giving the network an idea of where it is to go. That's kind > of the point of the locator. > > That said, the point of the endpoint ID is to identify the application > on the system, the transport connection endpoint, independent of its > location. If the application moves from one system to another, the > transport connection needs to be able to follow it. > > Gee whiz. RFCs 1483, 1753, 1922, 2102, and 2103. > > On Nov 6, 2008, at 12:06 PM, David P. Reed wrote: > >> Why should "location" be relevant to networking? Must all wires be >> buried permanently in the ground? Does wireless and mobility not occur? >> >> Michael Welzl wrote: >>> On Wed, 2008-11-05 at 13:26 +0100, Ali Ghodsi wrote: >>> >>>> Jon Crowcroft wrote: >>>> >>>>> but, BUT this is sidestepping the big problem >>>>> which is to have a service which hosts the id<->loc mapping, which >>>>> actually scales to the size of the expected workload... >>>>> >>>> Can DHTs be part of the solution, and if not, what are the >>>> essential features which they are lacking? (trying to fish for >>>> research problems) >>>> >>> >>> Location dependance, which even the "id" part should >>> have (at least in the form of some concept of "nearness"). >>> >>> This was pointed out quite convincingly (IMO) by John Day >>> in his "patterns in network architecture" book. >>> >>> Cheers, >>> Michael >>> >>> >>> >>> > > From craig at aland.bbn.com Thu Nov 6 13:30:57 2008 From: craig at aland.bbn.com (Craig Partridge) Date: Thu, 06 Nov 2008 16:30:57 -0500 Subject: [e2e] a means to an end In-Reply-To: Your message of "Thu, 06 Nov 2008 16:20:42 EST." <49135FAA.6080603@reed.com> Message-ID: <20081106213057.479E728E155@aland.bbn.com> Hi Dave: Interesting you invoked Van as it was a talk with Van last week that led to my comment. I suspect this means you mean one thing by your comment and I mean something else (i.e. we're in agreement but having a semantics problem). So let me try restating what I took from chatting with Van (with the understanding that this is my take, not necessarily Van's). * Information is place free. * Actually accessing that information, in the worst case, requires a rendezvous point (if it is popular data, it doesn't -- someone near you will have a copy -- but information that is of only occasional interest requires more effort). * To get to the rendezvous point, you need some way to convert from the name/label/ID of the information to a location of a rendezvous point that knows where the information currently resides (or, better, can get the information sent to you). Thanks! Craig In message <49135FAA.6080603 at reed.com>, "David P. Reed" writes: >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. > >Craig Partridge wrote: >> In message <49134E2F.8010704 at reed.com>, "David P. Reed" writes: >> >> >>> Why should "location" be relevant to networking? Must all wires be >>> buried permanently in the ground? Does wireless and mobility not occur? >>> >> >> I think it is easier to see the merit of location when one thinks about >> retrieving data. You need some clue as to where the data is. >> >> Craig >> >> From dpreed at reed.com Thu Nov 6 13:48:19 2008 From: dpreed at reed.com (David P. Reed) Date: Thu, 06 Nov 2008 16:48:19 -0500 Subject: [e2e] a means to an end In-Reply-To: <20081106213057.479E728E155@aland.bbn.com> References: <20081106213057.479E728E155@aland.bbn.com> Message-ID: <49136623.5000106@reed.com> It can be in many places, including everywhere and nowhere. As an example of the latter, consider the location of the piece of information called the "majority" of a set of voters. Let's assume that the set of voters has cardinality N. (Both Dave Gifford and I, and later Leslie Lamport, built practical networked computing systems that were based on key information elements being stored as majorities of this sort). The "location" of such a majority is, in some sense, a superposition of subsets that have the following property: the subset has floor(N/2)+1 elements who vote in the same way. Depending on the preponerance of agreeable voters, the "location" of the majority has at least 2^(floor(N/2)) possible states, all of which are "a location of the majority". I'm bloody serious. The idea that one must access information by *first* deciding *where* to look and then asking a container is JUST WRONG. Or to be more polite, it is a design choice that we made arbitrarily in the Internet. But it is not unambiguously "right". Craig Partridge wrote: > Hi Dave: > > Interesting you invoked Van as it was a talk with Van last week that led to > my comment. I suspect this means you mean one thing by your comment and > I mean something else (i.e. we're in agreement but having a semantics > problem). > > So let me try restating what I took from chatting with Van (with the > understanding that this is my take, not necessarily Van's). > > * Information is place free. > > * Actually accessing that information, in the worst case, requires > a rendezvous point (if it is popular data, it doesn't -- someone > near you will have a copy -- but information that is of only occasional > interest requires more effort). > > * To get to the rendezvous point, you need some way to convert from the > name/label/ID of the information to a location of a rendezvous > point that knows where the information currently resides (or, better, > can get the information sent to you). > > Thanks! > > Craig > > In message <49135FAA.6080603 at reed.com>, "David P. Reed" writes: > > >> 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. >> >> Craig Partridge wrote: >> >>> In message <49134E2F.8010704 at reed.com>, "David P. Reed" writes: >>> >>> >>> >>>> Why should "location" be relevant to networking? Must all wires be >>>> buried permanently in the ground? Does wireless and mobility not occur? >>>> >>>> >>> I think it is easier to see the merit of location when one thinks about >>> retrieving data. You need some clue as to where the data is. >>> >>> Craig >>> >>> >>> > > From day at std.com Thu Nov 6 13:46:50 2008 From: day at std.com (John Day) Date: Thu, 6 Nov 2008 16:46:50 -0500 Subject: [e2e] a means to an end In-Reply-To: <20081106205204.CCE5D28E155@aland.bbn.com> References: <20081106205204.CCE5D28E155@aland.bbn.com> Message-ID: Indeed. As Shoch said, application names indicate what; addresses, where; and routes, how. Of course in this case, the "where" is relative to the graph of the network. Which is of course why addresses should be topological, i.e. location dependent but not route dependent. At 15:52 -0500 2008/11/06, Craig Partridge wrote: >In message <49134E2F.8010704 at reed.com>, "David P. Reed" writes: > >>Why should "location" be relevant to networking? Must all wires be >>buried permanently in the ground? Does wireless and mobility not occur? > >I think it is easier to see the merit of location when one thinks about >retrieving data. You need some clue as to where the data is. > >Craig From craig at aland.bbn.com Thu Nov 6 13:56:18 2008 From: craig at aland.bbn.com (Craig Partridge) Date: Thu, 06 Nov 2008 16:56:18 -0500 Subject: [e2e] a means to an end In-Reply-To: Your message of "Thu, 06 Nov 2008 16:48:19 EST." <49136623.5000106@reed.com> Message-ID: <20081106215618.54A0628E155@aland.bbn.com> In message <49136623.5000106 at reed.com>, "David P. Reed" writes: >I'm bloody serious. The idea that one must access information by >*first* deciding *where* to look and then asking a container is JUST >WRONG. Or to be more polite, it is a design choice that we made >arbitrarily in the Internet. But it is not unambiguously "right". Hi Dave: We're clearly not communicating. I carefully did not say *first* -- I sought to make clear it was the thing you did if alternatives failed. Craig > >Craig Partridge wrote: >> Hi Dave: >> >> Interesting you invoked Van as it was a talk with Van last week that led to >> my comment. I suspect this means you mean one thing by your comment and >> I mean something else (i.e. we're in agreement but having a semantics >> problem). >> >> So let me try restating what I took from chatting with Van (with the >> understanding that this is my take, not necessarily Van's). >> >> * Information is place free. >> >> * Actually accessing that information, in the worst case, requires >> a rendezvous point (if it is popular data, it doesn't -- someone >> near you will have a copy -- but information that is of only occasiona >l >> interest requires more effort). >> >> * To get to the rendezvous point, you need some way to convert from the >> name/label/ID of the information to a location of a rendezvous >> point that knows where the information currently resides (or, better, >> can get the information sent to you). >> >> Thanks! >> >> Craig >> >> In message <49135FAA.6080603 at reed.com>, "David P. Reed" writes: >> >> >>> 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. >>> >>> Craig Partridge wrote: >>> >>>> In message <49134E2F.8010704 at reed.com>, "David P. Reed" writes: >>>> >>>> >>>> >>>>> Why should "location" be relevant to networking? Must all wires be >>>>> buried permanently in the ground? Does wireless and mobility not occur? >>>>> >>>>> >>>> I think it is easier to see the merit of location when one thinks about >>>> retrieving data. You need some clue as to where the data is. >>>> >>>> Craig >>>> >>>> >>>> >> >> From dpreed at reed.com Thu Nov 6 14:02:31 2008 From: dpreed at reed.com (David P. Reed) Date: Thu, 06 Nov 2008 17:02:31 -0500 Subject: [e2e] a means to an end In-Reply-To: <8900B298-4E63-45D0-B0E5-B9A23C4A0947@cisco.com> References: <491190DE.7010706@sics.se> <1225995088.3733.231.camel@pc105-c703.uibk.ac.at> <49134E2F.8010704@reed.com> <04EC169B-5D71-427D-989F-E41FE30BEB9E@cisco.com> <491361B9.2030506@reed.com> <8900B298-4E63-45D0-B0E5-B9A23C4A0947@cisco.com> Message-ID: <49136977.8000203@reed.com> Fred - I have nothing against you, and nothing against Cisco or the IETF. I apologize for any bad feelings that seemed to be directed against persons or institutions. I was reacting to the *idea* that IETF RFC's or the Internet as built (mostly out of Cisco routers) is somehow the "right" answer, or that studying either of them answers the discussion Crowcroft started. Generally, I react sarcastically to citations of holy writ - and your note cited about 5 RFCs by number - when involved in a conversation that started out focusing on addressing in general, and my seriously meant question in regard to the role "location" need play in end-to-end communications function. I admire and respect the IETF, Cisco, and Fred Baker. Always have. Fred Baker wrote: > > On Nov 6, 2008, at 1:29 PM, David P. Reed wrote: >> OK, OK. that's not communications - because only the holy scripture >> of the Cisco router defines "real" communications. :-) They have a >> patent on it, which they license to their IETF. > > Some day I'll figure out what you have against Cisco, the IETF, or me. > It seems that we can't engage in a simple conversation without a barb > from you. > > Until I do, I'm going to leave this on the table. I'll ask you to do > the same. > From sollins at csail.mit.edu Thu Nov 6 14:09:29 2008 From: sollins at csail.mit.edu (Karen R. Sollins) Date: Thu, 6 Nov 2008 17:09:29 -0500 Subject: [e2e] a means to an end In-Reply-To: <20081106205204.CCE5D28E155@aland.bbn.com> References: <20081106205204.CCE5D28E155@aland.bbn.com> Message-ID: Actually, no. If you think about Van Jacobson's content centric networking in which one turns things upside down, one forwards information as much as possible, so that it is "everywhere" or at least broadly so. Then location is increasingly irrelevant. Only the id (and other parts that he includes) really matter. I realize that I am only scratching the surface of Van's perspective. He's the authority on it. Another similar project is PSIRP (psirp.org). There are probably others around too. Karen At 3:52 PM -0500 11/6/08, Craig Partridge wrote: >In message <49134E2F.8010704 at reed.com>, "David P. Reed" writes: > >>Why should "location" be relevant to networking? Must all wires be >>buried permanently in the ground? Does wireless and mobility not occur? > >I think it is easier to see the merit of location when one thinks about >retrieving data. You need some clue as to where the data is. > >Craig From dpreed at reed.com Thu Nov 6 14:16:06 2008 From: dpreed at reed.com (David P. Reed) Date: Thu, 06 Nov 2008 17:16:06 -0500 Subject: [e2e] a means to an end In-Reply-To: <3DD8735B-2342-4CFB-9815-4C4644A4C9E6@cisco.com> References: <491190DE.7010706@sics.se> <1225995088.3733.231.camel@pc105-c703.uibk.ac.at> <49134E2F.8010704@reed.com> <04EC169B-5D71-427D-989F-E41FE30BEB9E@cisco.com> <491361B9.2030506@reed.com> <3DD8735B-2342-4CFB-9815-4C4644A4C9E6@cisco.com> Message-ID: <49136CA6.6010303@reed.com> Fred Baker wrote: > It sure is more convenient to be able to include only the people you > want involved in the conversation and leave everyone else out of it. Enabling filtering is the more general idea you are calling for here. We achieve that in wireless networks by "code division multiplexing". Doesn't need to involve "location" (which would be space-division multiplexing, i.e. beam-forming) to achieve orders of magnitude in efficiency. Yes, if you enable most communications to be easily filtered out by those not interested (by tuning one's selective receiver to cover only a single place or time or coding/modulation) you can make communications more efficient. That is the same sort of efficiency that "location" addressing gives you, and often it's a lot more efficient than attempting to deliver to one place. I'm making an architectural principle argument: if you want a piece of information, there are many ways to reduce the waste/cost/... and switching the communications based on "place" is *not the fundamental one*. That said, sometimes it is. If most of your communications is via fiber, mostly between elements that don't move, and where those containers contain a largely static collection of information, then "location" turns out to be useful. Whole industries can be built on it that last maybe 25 years or more, and that's not bad. From garmitage at swin.edu.au Thu Nov 6 15:02:39 2008 From: garmitage at swin.edu.au (grenville armitage) Date: Fri, 07 Nov 2008 10:02:39 +1100 Subject: [e2e] a means to an end In-Reply-To: <49135FAA.6080603@reed.com> References: <20081106205204.CCE5D28E155@aland.bbn.com> <49135FAA.6080603@reed.com> Message-ID: <4913778F.8040203@swin.edu.au> David P. Reed wrote: [..] > 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, I wonder if "Information" should be considered to have a "when" it is, not just "what" it is. And the "when" could be measured relative to my current location. So it does seem potentially relevant to know some sort of indication of "where" insofar as "where" can be mapped to "how long might it minimally me take to retrieve the information that is". cheers, gja From day at std.com Thu Nov 6 15:33:05 2008 From: day at std.com (John Day) Date: Thu, 6 Nov 2008 18:33:05 -0500 Subject: [e2e] a means to an end In-Reply-To: <49135FAA.6080603@reed.com> References: <20081106205204.CCE5D28E155@aland.bbn.com> <49135FAA.6080603@reed.com> Message-ID: I think you are worrying too much about longevity. I would hope that at any point in time information is somewhere. Perhaps even in multiple places. This is why levels of indirection are so useful. As for the purveying the OSI layers. All 7 of them were wrong and long dead. I don't mention them when I teach and frankly find it peculiar that how strongly everyone else seems to cling to the ideas of data link, network and transport layers. How quaint! But seriously, with traditional approaches to forwarding, the "location-ness" of the address is merely a means to keep the combinatorial computation of the forwarding table tractable. Actually I agree entirely with what Van is saying although I think his focus is a bit narrow. At 16:20 -0500 2008/11/06, David P. Reed 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. > >Craig Partridge wrote: >>In message <49134E2F.8010704 at reed.com>, "David P. Reed" writes: >> >> >>>Why should "location" be relevant to networking? Must all wires >>>be buried permanently in the ground? Does wireless and mobility >>>not occur? >>> >> >>I think it is easier to see the merit of location when one thinks about >>retrieving data. You need some clue as to where the data is. >> >>Craig >> >> From ali at sics.se Fri Nov 7 00:52:31 2008 From: ali at sics.se (Ali Ghodsi) Date: Fri, 07 Nov 2008 09:52:31 +0100 Subject: [e2e] a means to an end In-Reply-To: <1225995088.3733.231.camel@pc105-c703.uibk.ac.at> References: <491190DE.7010706@sics.se> <1225995088.3733.231.camel@pc105-c703.uibk.ac.at> Message-ID: <491401CF.1080304@sics.se> Michael Welzl wrote: > Location dependance, which even the "id" part should > have (at least in the form of some concept of "nearness"). > > Sorry, not sure I understand. Do you mean that DHTs have strong connectivity requirements (e.g. nodes should be able to communicate with their direct successors on the ring etc)? In that case, there are DHTs which relax these requirements, e.g. small-world DHTs (Oscar, Symphony) and those that don't have a ring or lattice (P-grid, FuzzyNets, Kelips). Or do you mean that DHTs do not route efficiently because they ignore latencies (what's called stretch, or proximity awareness, or locality by the DHT folks). Or perhaps neither :). Regards, Ali From Jon.Crowcroft at cl.cam.ac.uk Fri Nov 7 01:31:56 2008 From: Jon.Crowcroft at cl.cam.ac.uk (Jon Crowcroft) Date: Fri, 07 Nov 2008 09:31:56 +0000 Subject: [e2e] a means to an end In-Reply-To: <49135FAA.6080603@reed.com> References: <20081106205204.CCE5D28E155@aland.bbn.com> <49135FAA.6080603@reed.com> Message-ID: my and my big mouth - i knew this would get hijacked into a philosohpy discussion. I am talking about this as I think the internet community is in denial and uses philopshy as an escape valve to avoid discussing the actual elephant in the room We need a new kind of network layer _service_ - to support finding end systems as they move around and so on. We have an idea of the workload on the service. It is unusual kind of service for the internet community as it isnt an overlay, it has to work inside the IP layer as it is something end systems and routers need to share state/fate with, (we hit this before implicity with multicast, and couldn't ever face up to it properly) It would be nice to capitalise on the last ten years of internet scale content service research, since the actual _volume_ of data in this service system is low, but the churn is very high. The service _might_ be implemented by some sort of 1-hop DHT but it needs to support consistency and security. It isnt DNS based and it isnt BGP based because both of those technologies have major design flaws and surive only due to heroic bandaids we need a Mocapetris for the 21st century, clearly it aint me....it might be Van:) cheers jon From dirk.trossen at bt.com Fri Nov 7 01:47:01 2008 From: dirk.trossen at bt.com (dirk.trossen@bt.com) Date: Fri, 7 Nov 2008 09:47:01 -0000 Subject: [e2e] a means to an end References: <20081106205204.CCE5D28E155@aland.bbn.com> Message-ID: <12153BA9BDDEB646872639E8C6954291036D18B0@E03MVC2-UKBR.domain1.systemhost.net> it is certainly important as to 'where' information is, in the end. But the question is whether or not the 'where' needs unique addressing or not, in particular if you dynamically bind information to a potential delivery tree of information providers and consumers. What you need is the ability to form the delivery tree, which does not require unique addressing of the leafs of that tree. Dirk -----Original Message----- From: end2end-interest-bounces at postel.org on behalf of Karen R. Sollins Sent: Thu 06/11/2008 22:09 To: Craig Partridge; David P. Reed Cc: end2end-interest at postel.org Subject: Re: [e2e] a means to an end Actually, no. If you think about Van Jacobson's content centric networking in which one turns things upside down, one forwards information as much as possible, so that it is "everywhere" or at least broadly so. Then location is increasingly irrelevant. Only the id (and other parts that he includes) really matter. I realize that I am only scratching the surface of Van's perspective. He's the authority on it. Another similar project is PSIRP (psirp.org). There are probably others around too. Karen At 3:52 PM -0500 11/6/08, Craig Partridge wrote: >In message <49134E2F.8010704 at reed.com>, "David P. Reed" writes: > >>Why should "location" be relevant to networking? Must all wires be >>buried permanently in the ground? Does wireless and mobility not occur? > >I think it is easier to see the merit of location when one thinks about >retrieving data. You need some clue as to where the data is. > >Craig From dirk.trossen at bt.com Fri Nov 7 01:54:15 2008 From: dirk.trossen at bt.com (dirk.trossen@bt.com) Date: Fri, 7 Nov 2008 09:54:15 -0000 Subject: [e2e] a means to an end References: <20081106213057.479E728E155@aland.bbn.com> Message-ID: <12153BA9BDDEB646872639E8C6954291036D18B1@E03MVC2-UKBR.domain1.systemhost.net> Craig, indeed, you need to get to the rendezvous point that 'serves' your information, i.e., can match the consumers and producers and therefore build the delivery tree. Conceptually, a particular rendezvous point implements a 'network of information' (being information in itself), i.e., you can identify the information network itself with an identifier (which is place-free) to which the rendezvous points serving this particular network of information, can subscribe. And you're back to information-centric routing without a-priori knowledge of location. Of course, you need to get to the 'global' rendezvous system that helps you find the rendezvous point that serves the network in which your information reside. That's similar to a network attachment process in IP during which you receive local gateway information (DHCP). But that does not relate to any particular information at hand, only to enabling the general process of information retrieval. More can be found indeed on http://www.psirp.org on these principles of building information-centric networks. Dirk -----Original Message----- From: end2end-interest-bounces at postel.org on behalf of Craig Partridge Sent: Thu 06/11/2008 21:30 To: David P. Reed Cc: end2end-interest at postel.org Subject: Re: [e2e] a means to an end Hi Dave: Interesting you invoked Van as it was a talk with Van last week that led to my comment. I suspect this means you mean one thing by your comment and I mean something else (i.e. we're in agreement but having a semantics problem). So let me try restating what I took from chatting with Van (with the understanding that this is my take, not necessarily Van's). * Information is place free. * Actually accessing that information, in the worst case, requires a rendezvous point (if it is popular data, it doesn't -- someone near you will have a copy -- but information that is of only occasional interest requires more effort). * To get to the rendezvous point, you need some way to convert from the name/label/ID of the information to a location of a rendezvous point that knows where the information currently resides (or, better, can get the information sent to you). Thanks! Craig In message <49135FAA.6080603 at reed.com>, "David P. Reed" writes: >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. > >Craig Partridge wrote: >> In message <49134E2F.8010704 at reed.com>, "David P. Reed" writes: >> >> >>> Why should "location" be relevant to networking? Must all wires be >>> buried permanently in the ground? Does wireless and mobility not occur? >>> >> >> I think it is easier to see the merit of location when one thinks about >> retrieving data. You need some clue as to where the data is. >> >> Craig >> >> From ggm at apnic.net Fri Nov 7 03:43:39 2008 From: ggm at apnic.net (George Michaelson) Date: Fri, 7 Nov 2008 21:43:39 +1000 Subject: [e2e] a means to an end In-Reply-To: References: <20081106205204.CCE5D28E155@aland.bbn.com> <49135FAA.6080603@reed.com> Message-ID: I think we may be in a place and time where new protocols are not such a good idea. for instance, why can't the DHT simply be applied as a URI into a (local) webserver, discovered on the local link, and then replied to in suitable form eg as XML? or REST or something? yes, it could be 'do it in DNS' but just because we say 'no, not again' doesn't mean inventing proto direct on IP. And, the same for BGP. Please, no more heroic programmers. Good mathematicians, maybe. Not to be an entire layering/IP heretic, but, perhaps, this is more about managing an information space and the MAPPING than it is about designing a protocol, be it connection/ connectionless -G From kkrama at research.att.com Fri Nov 7 04:38:43 2008 From: kkrama at research.att.com (RAMAKRISHNAN, KADANGODE K (K. K.)) Date: Fri, 7 Nov 2008 07:38:43 -0500 Subject: [e2e] a means to an end In-Reply-To: <12153BA9BDDEB646872639E8C6954291036D18B1@E03MVC2-UKBR.domain1.systemhost.net> References: <20081106213057.479E728E155@aland.bbn.com> <12153BA9BDDEB646872639E8C6954291036D18B1@E03MVC2-UKBR.domain1.systemhost.net> Message-ID: Dirk and Craig, In this context of information centric networks, we have been working for a while on an architecture called "XTreeNet". We focus on disseminating information from producers to interested information consumers as well as enabling consumers to query and find information of interest. A high level overview of our architecture can be found in the WCW 2005 proceedings (see: http://www.cs.utexas.edu/%7Eyzhang/papers/xtreenet-wcw05.pdf ). While we start with making this work in an overlay, our goal is to make it efficient for forwarding in the underlay. At a high level, we probably have similar goals as Van's content centric networks. If you want to make information access work at a fine enough granularity, scale becomes an issue - to this end, we have been looking at how to make multicast scale up, somewhat in the context of what Dirk speaks of. When you focus on the "unit" of information, disseminating it to consumers of information on a subscription tree and finding it by forwarding the query along a sink tree associated with the unit of information, then the notion of location can be thought of as being orthogonal (not necessarily irrelevant). Thanks, --- K. K. Ramakrishnan Email: kkrama at research.att.com AT&T Labs-Research, Rm. A161 Tel: (973)360-8764 180 Park Ave, Florham Park, NJ 07932 Fax: (973) 360-8871 URL: http://www.research.att.com/info/kkrama -----Original Message----- From: end2end-interest-bounces at postel.org [mailto:end2end-interest-bounces at postel.org] On Behalf Of dirk.trossen at bt.com Sent: Friday, November 07, 2008 4:54 AM To: craig at aland.bbn.com; dpreed at reed.com Cc: end2end-interest at postel.org Subject: Re: [e2e] a means to an end Craig, indeed, you need to get to the rendezvous point that 'serves' your information, i.e., can match the consumers and producers and therefore build the delivery tree. Conceptually, a particular rendezvous point implements a 'network of information' (being information in itself), i.e., you can identify the information network itself with an identifier (which is place-free) to which the rendezvous points serving this particular network of information, can subscribe. And you're back to information-centric routing without a-priori knowledge of location. Of course, you need to get to the 'global' rendezvous system that helps you find the rendezvous point that serves the network in which your information reside. That's similar to a network attachment process in IP during which you receive local gateway information (DHCP). But that does not relate to any particular information at hand, only to enabling the general process of information retrieval. More can be found indeed on http://www.psirp.org on these principles of building information-centric networks. Dirk -----Original Message----- From: end2end-interest-bounces at postel.org on behalf of Craig Partridge Sent: Thu 06/11/2008 21:30 To: David P. Reed Cc: end2end-interest at postel.org Subject: Re: [e2e] a means to an end Hi Dave: Interesting you invoked Van as it was a talk with Van last week that led to my comment. I suspect this means you mean one thing by your comment and I mean something else (i.e. we're in agreement but having a semantics problem). So let me try restating what I took from chatting with Van (with the understanding that this is my take, not necessarily Van's). * Information is place free. * Actually accessing that information, in the worst case, requires a rendezvous point (if it is popular data, it doesn't -- someone near you will have a copy -- but information that is of only occasional interest requires more effort). * To get to the rendezvous point, you need some way to convert from the name/label/ID of the information to a location of a rendezvous point that knows where the information currently resides (or, better, can get the information sent to you). Thanks! Craig From fred at cisco.com Thu Nov 6 13:18:50 2008 From: fred at cisco.com (Fred Baker) Date: Thu, 6 Nov 2008 13:18:50 -0800 Subject: [e2e] a means to an end In-Reply-To: <49134E2F.8010704@reed.com> References: <491190DE.7010706@sics.se> <1225995088.3733.231.camel@pc105-c703.uibk.ac.at> <49134E2F.8010704@reed.com> Message-ID: <04EC169B-5D71-427D-989F-E41FE30BEB9E@cisco.com> It's kind of hard to get a message to a destination, fixed or mobile, without giving the network an idea of where it is to go. That's kind of the point of the locator. That said, the point of the endpoint ID is to identify the application on the system, the transport connection endpoint, independent of its location. If the application moves from one system to another, the transport connection needs to be able to follow it. Gee whiz. RFCs 1483, 1753, 1922, 2102, and 2103. On Nov 6, 2008, at 12:06 PM, David P. Reed wrote: > Why should "location" be relevant to networking? Must all wires be > buried permanently in the ground? Does wireless and mobility not > occur? > > Michael Welzl wrote: >> On Wed, 2008-11-05 at 13:26 +0100, Ali Ghodsi wrote: >> >>> Jon Crowcroft wrote: >>> >>>> but, BUT this is sidestepping the big problem >>>> which is to have a service which hosts the id<->loc mapping, >>>> which actually scales to the size of the expected workload... >>>> >>> Can DHTs be part of the solution, and if not, what are the >>> essential features which they are lacking? (trying to fish for >>> research problems) >>> >> >> Location dependance, which even the "id" part should >> have (at least in the form of some concept of "nearness"). >> >> This was pointed out quite convincingly (IMO) by John Day >> in his "patterns in network architecture" book. >> >> Cheers, >> Michael >> >> >> >> From fred at cisco.com Thu Nov 6 13:42:59 2008 From: fred at cisco.com (Fred Baker) Date: Thu, 6 Nov 2008 13:42:59 -0800 Subject: [e2e] a means to an end In-Reply-To: <491361B9.2030506@reed.com> References: <491190DE.7010706@sics.se> <1225995088.3733.231.camel@pc105-c703.uibk.ac.at> <49134E2F.8010704@reed.com> <04EC169B-5D71-427D-989F-E41FE30BEB9E@cisco.com> <491361B9.2030506@reed.com> Message-ID: <8900B298-4E63-45D0-B0E5-B9A23C4A0947@cisco.com> On Nov 6, 2008, at 1:29 PM, David P. Reed wrote: > OK, OK. that's not communications - because only the holy scripture > of the Cisco router defines "real" communications. :-) They have a > patent on it, which they license to their IETF. Some day I'll figure out what you have against Cisco, the IETF, or me. It seems that we can't engage in a simple conversation without a barb from you. Until I do, I'm going to leave this on the table. I'll ask you to do the same. From fred at cisco.com Thu Nov 6 13:56:45 2008 From: fred at cisco.com (Fred Baker) Date: Thu, 6 Nov 2008 13:56:45 -0800 Subject: [e2e] a means to an end In-Reply-To: <491361B9.2030506@reed.com> References: <491190DE.7010706@sics.se> <1225995088.3733.231.camel@pc105-c703.uibk.ac.at> <49134E2F.8010704@reed.com> <04EC169B-5D71-427D-989F-E41FE30BEB9E@cisco.com> <491361B9.2030506@reed.com> Message-ID: <3DD8735B-2342-4CFB-9815-4C4644A4C9E6@cisco.com> On Nov 6, 2008, at 1:29 PM, David P. Reed wrote: > Let's say I have a message for all Republicans. I can send that > message quite reliably, without ever knowing "where" the set of all > Republicans is. In fact, it's a feature that I can do that. What's > particularly nice is that in some cases, it is far *more* efficient > to do that than to "first, find the locations of all Republicans" > and "second, deliver the message to that set of locations". > Maintaining a complex location set as an intermediate computed value > seems like it would cost a lot more than just telling each > Republican I know to pass the message to any Republicans he/she knows. We call that "multicast". Yes, we know that the objective is to get it to the members of the group identified by the group address. > The original "six degrees of separation" experiment showed that > networks can route messages without being told "where". The only > argument is one of efficiency, and that argument only applies when > a) nothing moves very fast, and b) the sender can be assumed to know > "where". well, maybe. In today's network, there are a lot of things, and the do indeed move pretty quickly. That said, if I want to send something to some object in the network named "David P. Reed", it sure is helpful to have some idea that the object might be associated with another object like "reed.com", and to be able to translate that into some notion of where "David P. Reed" might be found. The alternative is some variation on a search algorithm like "ask everyone you know if they have seen David P. Reed recently, and if so where they last saw him", which has scaling difficulties. Sure. I can dense-mode broadcast everything everywhere. I have visions of how well that would work. My son gave me an example that might be applicable. He is in USMC OCS, which means that if he wants to say anything to anyone that isn't an officer candidate he has to stand at attention and shout it. Saturday night, he and a bunch of compadres were having dinner together and discussing OCS pick-up lines. They theorized that they were supposed to 1) approach a table full of young ladies 2) pop to attention 3) shout: "Good evening, ma'am! Candidate Baker requests information regarding the telephone number of the ladie in the blue dress! Thanks you ma'am!" 4) politely await any result that might ensue. Now, let's imagine that all conversations happened that way - all the time everywhere. It sure is more convenient to be able to include only the people you want involved in the conversation and leave everyone else out of it. From fred at cisco.com Thu Nov 6 14:32:20 2008 From: fred at cisco.com (Fred Baker) Date: Thu, 6 Nov 2008 14:32:20 -0800 Subject: [e2e] a means to an end In-Reply-To: <49136CA6.6010303@reed.com> References: <491190DE.7010706@sics.se> <1225995088.3733.231.camel@pc105-c703.uibk.ac.at> <49134E2F.8010704@reed.com> <04EC169B-5D71-427D-989F-E41FE30BEB9E@cisco.com> <491361B9.2030506@reed.com> <3DD8735B-2342-4CFB-9815-4C4644A4C9E6@cisco.com> <49136CA6.6010303@reed.com> Message-ID: <7CAEAF7A-031E-40BB-B8B0-7C98677CEC3D@cisco.com> On Nov 6, 2008, at 2:16 PM, David P. Reed wrote: > > > Fred Baker wrote: >> It sure is more convenient to be able to include only the people >> you want involved in the conversation and leave everyone else out >> of it. > Enabling filtering is the more general idea you are calling for here. actually, no. I'm not asking everyone else in the room to turn their hearing aids off. I'm asking to be able to talk with the intended recipient without involving anyone I don't have to. > We achieve that in wireless networks by "code division > multiplexing". Doesn't need to involve "location" (which would be > space-division multiplexing, i.e. beam-forming) to achieve orders of > magnitude in efficiency. OK, let's take your example. To direct a message to your intended target, you select the beam that gets to that target. Whatever you call that beam, it is your local name for that target at that layer. It serves the function of a locator. When you want to direct a message to the target, you translate your notion of the target's identity to "which communication channel shall I use", which is in the case the name of the beam. It tells you the location of your target, in the context of a direct wireless network. "Direct wireless networks" are a special case of "networks". Other networks find locators interesting as well, and define them in ways appropriate to their technologies just as wireless networks do. > I'm making an architectural principle argument: if you want a piece > of information, there are many ways to reduce the waste/cost/... > and switching the communications based on "place" is *not the > fundamental one*. That said, sometimes it is. If most of your > communications is via fiber, mostly between elements that don't > move, and where those containers contain a largely static collection > of information, then "location" turns out to be useful. Whole > industries can be built on it that last maybe 25 years or more, and > that's not bad. yes. that said, there are fairly long-lived industries that base what they do on "current location" as well. consider mobile telephony, whatever name and technology you want to apply to it. A telephone number is essentially an identifier for the computer that can tell where your intended audience is coupled with the information it will need to identify them. That computer translates that into an IMSI, which is a binary identifier for the handset-or-whatever. As the handset moves in the network, it registers with cell after cell, which in turn register their association with the IMSI with the computer in question. A circuit gets set up, and as you move the circuit trails along behind you as you pass through various cells. The telephone number is a name, and the IMSI is a name. But the information gets translated (by registration) to a location (a cell) and perhaps the location of a communication (a circuit). Place may not be fundamental. But it sure is useful. From ali at sics.se Fri Nov 7 09:30:20 2008 From: ali at sics.se (Ali Ghodsi) Date: Fri, 07 Nov 2008 18:30:20 +0100 Subject: [e2e] a means to an end In-Reply-To: References: <20081106205204.CCE5D28E155@aland.bbn.com> <49135FAA.6080603@reed.com> Message-ID: <49147B2C.7060004@sics.se> Jon Crowcroft wrote: > It is unusual kind of service for the internet community as it isnt an overlay, > it has to work inside the IP layer > as it is something end systems and routers need to share state/fate with, > (we hit this before implicity with multicast, and couldn't ever face up to it properly) > This would preclude overlays, and in particular DHTs, because they're app level (aside from ROFL, VRR and variants). One of my favourite DHT papers is SkipNet by MS, which a lot of people seem to have forgotten (not so cited anymore). They guarantee fate sharing, even though it is an overlay. I'll quickly recap the main idea for those who don't want to read it. It is a DHT a'la Chord, but nodes on the ring are lexicographically sorted (in reverse, e.g. se.sics at ali). Hence, nodes in the same AS would occupy the same region of the ring. Hence, a partition would leave each component of the partition fully functioning. SkipNet has some other additional features, e.g. a) nodes don't need to be balanced on the ring, and b) if you look for a piece of data within your AS you never route outside of it, which is also good for transit costs. (I don't remember the paper talking about AS:es and transit/peering links, but it's essentially there). So maybe we could use that? Regards, Ali From swb at employees.org Fri Nov 7 09:50:18 2008 From: swb at employees.org (Scott Brim) Date: Fri, 07 Nov 2008 12:50:18 -0500 Subject: [e2e] a means to an end In-Reply-To: References: <4910A456.6030700@employees.org> Message-ID: <49147FDA.1000309@employees.org> On 11/5/08 4:48 AM, Jon Crowcroft allegedly wrote: > the "level of indirection" is exactly what I am talking about but > noone appears to be designing a service that implements this with a > view to the workload (including secure update rate) it should > sustain. I'm saying it doesn't have to be "a service". Or technically I suppose I'm saying that it can be many independent "services", but there doesn't have to be a widely coordinated infrastructure mechanism by which IDs can be mapped directly to locators. Relatively slow-moving, public nodes can update their location directly in a mapping service (including DNS), but fast-moving or more security-conscious nodes can use a level of indirection, for example a "home agent" or a rendezvous point, in which case the central mechanism does not know where the node actually is. So I'm questioning the requirements for updating a central service, and pointing out that a level of indirection via the rendezvous points has advantages. > the two way mapping is needed because of audit/accountability > trails Generally that's privileged information, and should _not_ be publicly available in a general service. If you need to know who was involved in a communication, for example to arrest him, you do need a mapping from locator to originating site, and you need to request coordination with the node's home site, etc. I don't believe that has anything to do with a general mechanism for mapping from locator-of-the-moment to ID-of-the-moment. On 11/5/08 7:26 AM, Ali Ghodsi allegedly wrote: > Can DHTs be part of the solution, and if not, what are the essential > features which they are lacking? (trying to fish for research > problems) Yes but again IMHO you can either keep locators up-to-date in the DHT -- Jon's approach -- or you can keep the information relatively stable, pointing to a set of nodes which need to be accessed to get the current answer (and which might be DHT nodes or not). On 11/7/08 4:31 AM, Jon Crowcroft allegedly wrote: > my and my big mouth - > > i knew this would get hijacked into a philosohpy discussion. I'm going to split all that out into a different reply. This one is just about your idea. Scott From Jon.Crowcroft at cl.cam.ac.uk Fri Nov 7 10:10:28 2008 From: Jon.Crowcroft at cl.cam.ac.uk (Jon Crowcroft) Date: Fri, 07 Nov 2008 18:10:28 +0000 Subject: [e2e] a means to an end In-Reply-To: <49147FDA.1000309@employees.org> References: <4910A456.6030700@employees.org> <49147FDA.1000309@employees.org> Message-ID: did i say it was centralised? nope - did you say you want end systems to implement multiple APIs? why? why not just have one API (a.k.a. service) and multiple strageies for distribution/cacheing/pre-fetching/localisation/aggregation based n the demand pattern? In missive <49147FDA.1000309 at employees.org>, Scott Brim typed: >>On 11/5/08 4:48 AM, Jon Crowcroft allegedly wrote: >>> the "level of indirection" is exactly what I am talking about but >>> noone appears to be designing a service that implements this with a >>> view to the workload (including secure update rate) it should >>> sustain. >> >>I'm saying it doesn't have to be "a service". Or technically I suppose >>I'm saying that it can be many independent "services", but there doesn't >>have to be a widely coordinated infrastructure mechanism by which IDs >>can be mapped directly to locators. Relatively slow-moving, public >>nodes can update their location directly in a mapping service (including >>DNS), but fast-moving or more security-conscious nodes can use a level >>of indirection, for example a "home agent" or a rendezvous point, in >>which case the central mechanism does not know where the node actually >>is. So I'm questioning the requirements for updating a central service, >>and pointing out that a level of indirection via the rendezvous points >>has advantages. >> >>> the two way mapping is needed because of audit/accountability >>> trails >> >>Generally that's privileged information, and should _not_ be publicly >>available in a general service. If you need to know who was involved >>in a communication, for example to arrest him, you do need a mapping >>from locator to originating site, and you need to request coordination >>with the node's home site, etc. I don't believe that has anything to >>do with a general mechanism for mapping from locator-of-the-moment to >>ID-of-the-moment. >> >> >>On 11/5/08 7:26 AM, Ali Ghodsi allegedly wrote: >>> Can DHTs be part of the solution, and if not, what are the essential >>> features which they are lacking? (trying to fish for research >>> problems) >> >>Yes but again IMHO you can either keep locators up-to-date in the DHT >>-- Jon's approach -- or you can keep the information relatively >>stable, pointing to a set of nodes which need to be accessed to get >>the current answer (and which might be DHT nodes or not). >> >> >>On 11/7/08 4:31 AM, Jon Crowcroft allegedly wrote: >>> my and my big mouth - >>> >>> i knew this would get hijacked into a philosohpy discussion. >> >>I'm going to split all that out into a different reply. This one is >>just about your idea. >> >>Scott >> cheers jon From swb at employees.org Fri Nov 7 10:25:00 2008 From: swb at employees.org (Scott Brim) Date: Fri, 07 Nov 2008 13:25:00 -0500 Subject: [e2e] a means to an end In-Reply-To: References: <4910A456.6030700@employees.org> <49147FDA.1000309@employees.org> Message-ID: <491487FC.40607@employees.org> On 11/7/08 1:10 PM, Jon Crowcroft allegedly wrote: > did i say it was centralised? nope - Well, I carefully said (this time) "a widely coordinated infrastructure mechanism by which IDs can be mapped directly to locators". Don't you want that? You drew parallels between what you want and DNS or a 1-hop DHT. > did you say you want end systems to implement multiple APIs? I don't think I did. > why? why not just have one API (a.k.a. service) and multiple strageies > for distribution/cacheing/pre-fetching/localisation/aggregation > based n the demand pattern? Oh, so you're talking about an API, not something out in the network like DNS? In that case I think we agree. swb > > In missive <49147FDA.1000309 at employees.org>, Scott Brim typed: > > >>On 11/5/08 4:48 AM, Jon Crowcroft allegedly wrote: > >>> the "level of indirection" is exactly what I am talking about but > >>> noone appears to be designing a service that implements this with a > >>> view to the workload (including secure update rate) it should > >>> sustain. > >> > >>I'm saying it doesn't have to be "a service". Or technically I suppose > >>I'm saying that it can be many independent "services", but there doesn't > >>have to be a widely coordinated infrastructure mechanism by which IDs > >>can be mapped directly to locators. Relatively slow-moving, public > >>nodes can update their location directly in a mapping service (including > >>DNS), but fast-moving or more security-conscious nodes can use a level > >>of indirection, for example a "home agent" or a rendezvous point, in > >>which case the central mechanism does not know where the node actually > >>is. So I'm questioning the requirements for updating a central service, > >>and pointing out that a level of indirection via the rendezvous points > >>has advantages. > >> > >>> the two way mapping is needed because of audit/accountability > >>> trails > >> > >>Generally that's privileged information, and should _not_ be publicly > >>available in a general service. If you need to know who was involved > >>in a communication, for example to arrest him, you do need a mapping > >>from locator to originating site, and you need to request coordination > >>with the node's home site, etc. I don't believe that has anything to > >>do with a general mechanism for mapping from locator-of-the-moment to > >>ID-of-the-moment. > >> > >> > >>On 11/5/08 7:26 AM, Ali Ghodsi allegedly wrote: > >>> Can DHTs be part of the solution, and if not, what are the essential > >>> features which they are lacking? (trying to fish for research > >>> problems) > >> > >>Yes but again IMHO you can either keep locators up-to-date in the DHT > >>-- Jon's approach -- or you can keep the information relatively > >>stable, pointing to a set of nodes which need to be accessed to get > >>the current answer (and which might be DHT nodes or not). > >> > >> > >>On 11/7/08 4:31 AM, Jon Crowcroft allegedly wrote: > >>> my and my big mouth - > >>> > >>> i knew this would get hijacked into a philosohpy discussion. > >> > >>I'm going to split all that out into a different reply. This one is > >>just about your idea. > >> > >>Scott > >> > > cheers > > jon > From Jon.Crowcroft at cl.cam.ac.uk Fri Nov 7 10:38:29 2008 From: Jon.Crowcroft at cl.cam.ac.uk (Jon Crowcroft) Date: Fri, 07 Nov 2008 18:38:29 +0000 Subject: [e2e] a means to an end In-Reply-To: <491487FC.40607@employees.org> References: <4910A456.6030700@employees.org> <49147FDA.1000309@employees.org> <491487FC.40607@employees.org> Message-ID: yep - common service model - but disparate implementatin - a bit loke ip forwarding service versus ip route algorithms In missive <491487FC.40607 at employees.org>, Scott Brim typed: >>On 11/7/08 1:10 PM, Jon Crowcroft allegedly wrote: >>> did i say it was centralised? nope - >> >>Well, I carefully said (this time) "a widely coordinated infrastructure >>mechanism by which IDs can be mapped directly to locators". Don't you >>want that? You drew parallels between what you want and DNS or a 1-hop >>DHT. >> >>> did you say you want end systems to implement multiple APIs? >> >>I don't think I did. >> >>> why? why not just have one API (a.k.a. service) and multiple strageies >>> for distribution/cacheing/pre-fetching/localisation/aggregation >>> based n the demand pattern? >> >>Oh, so you're talking about an API, not something out in the network >>like DNS? In that case I think we agree. >> >>swb >> >>> >>> In missive <49147FDA.1000309 at employees.org>, Scott Brim typed: >>> >>> >>On 11/5/08 4:48 AM, Jon Crowcroft allegedly wrote: >>> >>> the "level of indirection" is exactly what I am talking about but >>> >>> noone appears to be designing a service that implements this with a >>> >>> view to the workload (including secure update rate) it should >>> >>> sustain. >>> >> >>> >>I'm saying it doesn't have to be "a service". Or technically I suppose >>> >>I'm saying that it can be many independent "services", but there doesn't >>> >>have to be a widely coordinated infrastructure mechanism by which IDs >>> >>can be mapped directly to locators. Relatively slow-moving, public >>> >>nodes can update their location directly in a mapping service (including >>> >>DNS), but fast-moving or more security-conscious nodes can use a level >>> >>of indirection, for example a "home agent" or a rendezvous point, in >>> >>which case the central mechanism does not know where the node actually >>> >>is. So I'm questioning the requirements for updating a central service, >>> >>and pointing out that a level of indirection via the rendezvous points >>> >>has advantages. >>> >> >>> >>> the two way mapping is needed because of audit/accountability >>> >>> trails >>> >> >>> >>Generally that's privileged information, and should _not_ be publicly >>> >>available in a general service. If you need to know who was involved >>> >>in a communication, for example to arrest him, you do need a mapping >>> >>from locator to originating site, and you need to request coordination >>> >>with the node's home site, etc. I don't believe that has anything to >>> >>do with a general mechanism for mapping from locator-of-the-moment to >>> >>ID-of-the-moment. >>> >> >>> >> >>> >>On 11/5/08 7:26 AM, Ali Ghodsi allegedly wrote: >>> >>> Can DHTs be part of the solution, and if not, what are the essential >>> >>> features which they are lacking? (trying to fish for research >>> >>> problems) >>> >> >>> >>Yes but again IMHO you can either keep locators up-to-date in the DHT >>> >>-- Jon's approach -- or you can keep the information relatively >>> >>stable, pointing to a set of nodes which need to be accessed to get >>> >>the current answer (and which might be DHT nodes or not). >>> >> >>> >> >>> >>On 11/7/08 4:31 AM, Jon Crowcroft allegedly wrote: >>> >>> my and my big mouth - >>> >>> >>> >>> i knew this would get hijacked into a philosohpy discussion. >>> >> >>> >>I'm going to split all that out into a different reply. This one is >>> >>just about your idea. >>> >> >>> >>Scott >>> >> >>> >>> cheers >>> >>> jon >>> cheers jon From ping at pingpan.org Fri Nov 7 11:59:38 2008 From: ping at pingpan.org (Ping Pan) Date: Fri, 7 Nov 2008 11:59:38 -0800 Subject: [e2e] a means to an end In-Reply-To: References: <20081106205204.CCE5D28E155@aland.bbn.com> <49135FAA.6080603@reed.com> Message-ID: <22d04a930811071159g36ca7fb1reeb2fbd87ec1dfd1@mail.gmail.com> Jon, I had the same thoughts when reading this year's Sigcomm paper "Taming the Torrent". The paper actually is not related to your comment here, but it made one wondering... It's obvious that there is a big hole when it comes to mapping the users who roam in the network and the content that sits somewhere and can get replicated to else where by someone at some time. There seems to be many problems and ideas floating around. It may be a lookup issue whereby CDN-like DNS redirect may solve the problem or perhaps DHT. It may also be a network resource management issue... It may also be a YouTube problem. ;-) Not sure we will get into philosophy debate, but this has strong implication in business. So before we start to offer solutions, maybe we should try to fully understand the problem first. 2 cents, - Ping On Fri, Nov 7, 2008 at 1:31 AM, Jon Crowcroft wrote: > > We need a new kind of network layer _service_ - to support finding end > systems > as they move around and so on. > > > > It is unusual kind of service for the internet community as it isnt an > overlay, > it has to work inside the IP layer > as it is something end systems and routers need to share state/fate with, > > > The service _might_ be implemented by some sort of 1-hop DHT > but it needs to support consistency and security. > > It isnt DNS based and it isnt BGP > based because both of those technologies > have major design flaws and surive > only due to heroic bandaids > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.postel.org/pipermail/end2end-interest/attachments/20081107/3bcfe2a9/attachment.html From L.Wood at surrey.ac.uk Fri Nov 7 15:33:43 2008 From: L.Wood at surrey.ac.uk (Lloyd Wood) Date: Fri, 7 Nov 2008 23:33:43 +0000 Subject: [e2e] a means to an end In-Reply-To: <04EC169B-5D71-427D-989F-E41FE30BEB9E@cisco.com> References: <491190DE.7010706@sics.se> <1225995088.3733.231.camel@pc105-c703.uibk.ac.at> <49134E2F.8010704@reed.com> <04EC169B-5D71-427D-989F-E41FE30BEB9E@cisco.com> Message-ID: <66011996-5C5B-4AF1-839D-1075A0D33CD1@surrey.ac.uk> On 6 Nov 2008, at 21:18, Fred Baker wrote: > It's kind of hard to get a message to a destination, fixed or > mobile, without giving the network an idea of where it is to go. > That's kind of the point of the locator. > > That said, the point of the endpoint ID is to identify the > application on the system, the transport connection endpoint, > independent of its location. If the application moves from one > system to another, the transport connection needs to be able to > follow it. can anyone explain how that clear explanation of the endpoint ID matches with the definition of endpoint ID given in RFC5050, section 4.4? thanks! L. DTN work: http://info.ee.surrey.ac.uk/Personal/L.Wood/saratoga/ From dpreed at reed.com Fri Nov 7 17:04:29 2008 From: dpreed at reed.com (David P. Reed) Date: Fri, 07 Nov 2008 20:04:29 -0500 Subject: [e2e] a means to an end In-Reply-To: <63B29FC7-B661-46AF-A0C3-3587B26BD864@cisco.com> References: <491190DE.7010706@sics.se> <1225995088.3733.231.camel@pc105-c703.uibk.ac.at> <49134E2F.8010704@reed.com> <04EC169B-5D71-427D-989F-E41FE30BEB9E@cisco.com> <66011996-5C5B-4AF1-839D-1075A0D33CD1@surrey.ac.uk> <63B29FC7-B661-46AF-A0C3-3587B26BD864@cisco.com> Message-ID: <4914E59D.9030204@reed.com> Just for clarification, Fred, I'm not postulating anything in particular. At most I'm raising a (possibly irritating) question founded in my current interests in making wireless communication a first class citizen and wired communication a mere resident alien in the human agora, one who bids to supplement the natural capabilities of humans to communicate just fine for centuries without "service providers." We already have very enticing service providers who offer efficiency/convenience in exchange for down payments on their customers' firstborn children, thank you very much. In particular, we might well wonder why all network operators who maintain routers should become privileged to know where *all* the people on the planet who *might* communicate are currently located in order to deliver messages connecting a vanishingly small subset of the N^2 possible pairings of customers. Should the routers in Russia know when a Georgian raising money for military support travels between NY and China? If that person never needs to talk to a Russian, why distribute the tracking data in any form, much less distribute it to places where communications will never be sought? Certainly this "network location tracking" enhances "efficiency" in one sense. And the folks on this list who think that networks ought be at the center of all power and control might feel just fine with this. After all, they personally have good consciences and nothing but love for their fellow humans (other than those whom their governments have managed to define as subhuman, evil beings :-) ). Of course, as mere servants of the market, our personal qualms should never be attached to mere technical attempts at efficiency. We must serve only the investors of our employers, never humanity, nor professional standards and ethics. Fred Baker wrote: > On Nov 7, 2008, at 3:33 PM, Lloyd Wood wrote: >> On 6 Nov 2008, at 21:18, Fred Baker wrote: >>> It's kind of hard to get a message to a destination, fixed or >>> mobile, without giving the network an idea of where it is to go. >>> That's kind of the point of the locator. >>> >>> That said, the point of the endpoint ID is to identify the >>> application on the system, the transport connection endpoint, >>> independent of its location. If the application moves from one >>> system to another, the transport connection needs to be able to >>> follow it. >> >> can anyone explain how that clear explanation of the endpoint ID >> matches with the definition of endpoint ID given in RFC5050, section >> 4.4? > > About the same way the description maps to the endpoint ID found in > RFC 5201-5201 and 5338. Like HIP's Endpoint ID, DTN's Bundle ID lacks > any way for a system, given knowledge of what instance of an > application it wants to talk with or what data object it wants to > find, to determine the locator of that object. Given the locator we > can establish whether we are talking to the right system, but not the > other way around. > > David is postulating that the only thing we need is a name for the > object we want to look at, and we can determine everything else we > need to know. It's wonderful theory, and on an isolated LAN it might > even make sense. > From dpreed at reed.com Fri Nov 7 17:34:32 2008 From: dpreed at reed.com (David P. Reed) Date: Fri, 07 Nov 2008 20:34:32 -0500 Subject: [e2e] a means to an end In-Reply-To: <880D8DCD-1F14-4244-A923-DF86382BE64B@cisco.com> References: <491190DE.7010706@sics.se> <1225995088.3733.231.camel@pc105-c703.uibk.ac.at> <49134E2F.8010704@reed.com> <04EC169B-5D71-427D-989F-E41FE30BEB9E@cisco.com> <66011996-5C5B-4AF1-839D-1075A0D33CD1@surrey.ac.uk> <63B29FC7-B661-46AF-A0C3-3587B26BD864@cisco.com> <4914E59D.9030204@reed.com> <880D8DCD-1F14-4244-A923-DF86382BE64B@cisco.com> Message-ID: <4914ECA8.4040805@reed.com> Fred Baker wrote: > > I'm not at all sure what you're talking about. AFAIK, IP addresses are > not assigned to people. > They are assigned to devices carried by people, and it is well known how to correlate observations of humans with observations of their radio emissions. (one can track bluetooth UIDs associated with phones quite easily, even when not in "discoverable" mode - and QinetiQ recently bought a company whose only skill is doing just that task efficiently and cheaply. Tracking the WiFi addresses of iPhones Androids, etc. are even more trivial). Should tracking become a "network layer" function? I don't honestly know, but one should question whether aggressive tracking is essential to communications, I think. It's not just philosophy of no consequence. From L.Wood at surrey.ac.uk Sat Nov 8 01:51:41 2008 From: L.Wood at surrey.ac.uk (Lloyd Wood) Date: Sat, 8 Nov 2008 09:51:41 +0000 Subject: [e2e] a means to an end In-Reply-To: <880D8DCD-1F14-4244-A923-DF86382BE64B@cisco.com> References: <491190DE.7010706@sics.se> <1225995088.3733.231.camel@pc105-c703.uibk.ac.at> <49134E2F.8010704@reed.com> <04EC169B-5D71-427D-989F-E41FE30BEB9E@cisco.com> <66011996-5C5B-4AF1-839D-1075A0D33CD1@surrey.ac.uk> <63B29FC7-B661-46AF-A0C3-3587B26BD864@cisco.com> <4914E59D.9030204@reed.com> <880D8DCD-1F14-4244-A923-DF86382BE64B@cisco.com> Message-ID: <9CAC624A-BBAA-44FD-9ADD-BAA63F46B606@surrey.ac.uk> Fred, you did write RFC3924. On 8 Nov 2008, at 01:07, Fred Baker wrote: > AFAIK, IP addresses are not assigned to people. DTN work: http://info.ee.surrey.ac.uk/Personal/L.Wood/saratoga/ From Jon.Crowcroft at cl.cam.ac.uk Sat Nov 8 02:55:41 2008 From: Jon.Crowcroft at cl.cam.ac.uk (Jon Crowcroft) Date: Sat, 08 Nov 2008 10:55:41 +0000 Subject: [e2e] a means to an end In-Reply-To: <9CAC624A-BBAA-44FD-9ADD-BAA63F46B606@surrey.ac.uk> References: <491190DE.7010706@sics.se> <1225995088.3733.231.camel@pc105-c703.uibk.ac.at> <49134E2F.8010704@reed.com> <04EC169B-5D71-427D-989F-E41FE30BEB9E@cisco.com> <66011996-5C5B-4AF1-839D-1075A0D33CD1@surrey.ac.uk> <63B29FC7-B661-46AF-A0C3-3587B26BD864@cisco.com> <4914E59D.9030204@reed.com> <880D8DCD-1F14-4244-A923-DF86382BE64B@cisco.com> <9CAC624A-BBAA-44FD-9ADD-BAA63F46B606@surrey.ac.uk> Message-ID: of course, in the UK, since we don't have id cards, we dont really know if the IP address is assigned to a person - its assigned potentially to an alias[*]:) but with the amount of UK cctv surveillance, we sure know where that alias is most of the time... so maybe that's what we need - a webcam on every end point and youtube to log where each end point is located, then we just go to youtube, search for the name or other attributes of our end point (e.g. "3 year old explaining plot of star wars" yields-> http://www.collegehumor.com/video:1804047 and then we can continue our conversation... j. [*] "alias" - the name used by Bob Dylan on film in the movie Pat Garrett&Billy the Kid, instead of his real identity, Robert Zimmerman. In missive <9CAC624A-BBAA-44FD-9ADD-BAA63F46B606 at surrey.ac.uk>, Lloyd Wood type d: >>Fred, you did write RFC3924. >> >>On 8 Nov 2008, at 01:07, Fred Baker wrote: >>> AFAIK, IP addresses are not assigned to people. >> >>DTN work: http://info.ee.surrey.ac.uk/Personal/L.Wood/saratoga/ >> >> >> >> >> >> >> cheers jon From L.Wood at surrey.ac.uk Sat Nov 8 05:19:06 2008 From: L.Wood at surrey.ac.uk (Lloyd Wood) Date: Sat, 8 Nov 2008 13:19:06 +0000 Subject: [e2e] a means to an end In-Reply-To: References: <491190DE.7010706@sics.se> <1225995088.3733.231.camel@pc105-c703.uibk.ac.at> <49134E2F.8010704@reed.com> <04EC169B-5D71-427D-989F-E41FE30BEB9E@cisco.com> <66011996-5C5B-4AF1-839D-1075A0D33CD1@surrey.ac.uk> <63B29FC7-B661-46AF-A0C3-3587B26BD864@cisco.com> <4914E59D.9030204@reed.com> <880D8DCD-1F14-4244-A923-DF86382BE64B@cisco.com> <9CAC624A-BBAA-44FD-9ADD-BAA63F46B606@surrey.ac.uk> Message-ID: Jon, read: http://www.telegraph.co.uk/news/uknews/3384743/Internet-black-boxes-to-record-every-email-and-website-visit.html Internet black boxes to record every email and website visit, Graham Tibbetts, Daily Telegraph, 6 Nov 2008. Fred's lawful intercept has done so well. L. On 8 Nov 2008, at 10:55, Jon Crowcroft wrote: > of course, in the UK, since we don't have id cards, > we dont really know if the IP address is assigned to a person - its > assigned potentially to an alias[*]:) DTN work: http://info.ee.surrey.ac.uk/Personal/L.Wood/saratoga/ From dpreed at reed.com Sat Nov 8 07:57:40 2008 From: dpreed at reed.com (David P. Reed) Date: Sat, 08 Nov 2008 10:57:40 -0500 Subject: [e2e] a means to an end In-Reply-To: <88097421-71EB-4D9E-A2BE-4948C7EDE7AD@cisco.com> References: <491190DE.7010706@sics.se> <1225995088.3733.231.camel@pc105-c703.uibk.ac.at> <49134E2F.8010704@reed.com> <04EC169B-5D71-427D-989F-E41FE30BEB9E@cisco.com> <66011996-5C5B-4AF1-839D-1075A0D33CD1@surrey.ac.uk> <63B29FC7-B661-46AF-A0C3-3587B26BD864@cisco.com> <4914E59D.9030204@reed.com> <88097421-71EB-4D9E-A2BE-4948C7EDE7AD@cisco.com> Message-ID: <4915B6F4.406@reed.com> I thought I made it clear that I don't direct any innuendo towards Fred. Nowhere in this message do I attribute ANYTHING to Fred. That said, I do attribute to "folks on this list who think that networks should be the center of power and control", If that can be called "innuendo directed at Fred" I want to clarify it right here: I did not mean that phrase to refer to Fred, not in ANY way. As far as I know, Fred does not believe that. I apologize for any possible interpretation that that phrase applied to Fred, such an interpretation was not meant in any way. I do think there are or have been such people on this list. I prefer not to embarrass them by naming them. You can read the messages archived to find those messages where people assert that the network designers should decide which uses of the network are to be allowed, and which are not. I also referred to "servants of the market". Perhaps my dismay at those who continue to assert that there is no place for ethics in business, no place for concern about the impact of the systems one designs led me to express myself too sarcastically. Yet I personally feel it is quite important for us NOT to design extra "location tracking" into the base of the Internet unless it is NECESSARY. It is not sufficient to say it saves pennies. The saving of pennies can also justify designing airplanes that crash twice as often. stephen wolff wrote: > David - > > Rarely have I seen so unjustified, extended, and egregious innuendo > directed towards a gentleman who has for many years served the > Internet, its user community, and his employer with openness, > competence, and honor. > > On the topic of professional standards and ethics: Look inward, and > know thyself. > > stephen wolff > > On Nov 7, 2008, at 20:04, David P. Reed wrote: > >> Just for clarification, Fred, I'm not postulating anything in >> particular. >> >> At most I'm raising a (possibly irritating) question founded in my >> current interests in making wireless communication a first class >> citizen and wired communication a mere resident alien in the human >> agora, one who bids to supplement the natural capabilities of humans >> to communicate just fine for centuries without "service providers." >> We already have very enticing service providers who offer >> efficiency/convenience in exchange for down payments on their >> customers' firstborn children, thank you very much. >> >> In particular, we might well wonder why all network operators who >> maintain routers should become privileged to know where *all* the >> people on the planet who *might* communicate are currently located in >> order to deliver messages connecting a vanishingly small subset of >> the N^2 possible pairings of customers. Should the routers in Russia >> know when a Georgian raising money for military support travels >> between NY and China? If that person never needs to talk to a >> Russian, why distribute the tracking data in any form, much less >> distribute it to places where communications will never be sought? >> >> Certainly this "network location tracking" enhances "efficiency" in >> one sense. And the folks on this list who think that networks ought >> be at the center of all power and control might feel just fine with >> this. After all, they personally have good consciences and nothing >> but love for their fellow humans (other than those whom their >> governments have managed to define as subhuman, evil beings :-) ). >> >> Of course, as mere servants of the market, our personal qualms should >> never be attached to mere technical attempts at efficiency. We must >> serve only the investors of our employers, never humanity, nor >> professional standards and ethics. > > From dpreed at reed.com Sat Nov 8 08:33:47 2008 From: dpreed at reed.com (David P. Reed) Date: Sat, 08 Nov 2008 11:33:47 -0500 Subject: [e2e] a means to an end In-Reply-To: <9CAC624A-BBAA-44FD-9ADD-BAA63F46B606@surrey.ac.uk> References: <491190DE.7010706@sics.se> <1225995088.3733.231.camel@pc105-c703.uibk.ac.at> <49134E2F.8010704@reed.com> <04EC169B-5D71-427D-989F-E41FE30BEB9E@cisco.com> <66011996-5C5B-4AF1-839D-1075A0D33CD1@surrey.ac.uk> <63B29FC7-B661-46AF-A0C3-3587B26BD864@cisco.com> <4914E59D.9030204@reed.com> <880D8DCD-1F14-4244-A923-DF86382BE64B@cisco.com> <9CAC624A-BBAA-44FD-9ADD-BAA63F46B606@surrey.ac.uk> Message-ID: <4915BF6B.6000502@reed.com> In this context, I re-read RFC3924. (An informational RFC, I should note, not a standard). Indeed, Fred was an author of the document, perhaps not of the design. The second quote suggests that government intrusion into information being sent to registries of location information (i.e. RADIUS servers) is both desired and is actually recommended by Cisco, at least in countries, such as my own, that have policies that support surveillance without court supervision. I would also note that there is no specific protection of the information thus made available to non-governmental sources described in the document. Marketers, for example, such as NebuAd and Phorm, should feel free to track location of individuals by their network footprints, perhaps giving another use for this architectural feature. > IESG Note > > This RFC is not a candidate for any level of Internet Standard. The > IETF disclaims any knowledge of the fitness of this RFC for any > purpose, and in particular notes that the decision to publish is not > based on IETF review for such things as security, congestion control > or inappropriate interaction with deployed protocols. The RFC Editor > has chosen to publish this document at its discretion. Readers of > this document should exercise caution in evaluating its value for > implementation and deployment. > > Abstract > > For the purposes of this document, lawful intercept is the lawfully > authorized interception and monitoring of communications. Service > providers are being asked to meet legal and regulatory requirements > for the interception of voice as well as data communications in IP > networks in a variety of countries worldwide. Although requirements > vary from country to country, some requirements remain common even > though details such as delivery formats may differ. This document > describes Cisco's Architecture for supporting lawful intercept in IP > networks. It provides a general solution that has a minimum set of > common interfaces. This document does not attempt to address any of > the specific legal requirements or obligations that may exist in a > particular country. > > 4.2. Data Services > > The same model (Figure 1) can also be used for data services. In > this case the IRI IAP could be a server that acts as registration, > authentication and authorization point for the data service (e.g., a > RADIUS server). If a potential IRI IAP does not have the available > interfaces (c) and (e), the MD may have to do a content tap on > registration signaling in order to obtain the IRI. > > The IRI in the case of a data service could include: > > * The time that the user registered or de-registered for the > service. > * Addressing information (i.e., given the user identity, what IP > address or other information is available that could be used in > interface (d) to do the content tap). > > Once suitable addressing information is available in order to do > content tapping the MD can invoke the tap via interface (d). > > Clearly the IRI interfaces (c, e, g) are different for data than they > are for voice services. However, the content IAP is typically the > same (an edge router). Interfaces (d, f, and h) may also be the > same. > Lloyd Wood wrote: > Fred, you did write RFC3924. > > On 8 Nov 2008, at 01:07, Fred Baker wrote: >> AFAIK, IP addresses are not assigned to people. > > DTN work: http://info.ee.surrey.ac.uk/Personal/L.Wood/saratoga/ > > > > > > > > From fred at cisco.com Fri Nov 7 16:00:23 2008 From: fred at cisco.com (Fred Baker) Date: Fri, 7 Nov 2008 16:00:23 -0800 Subject: [e2e] a means to an end In-Reply-To: <66011996-5C5B-4AF1-839D-1075A0D33CD1@surrey.ac.uk> References: <491190DE.7010706@sics.se> <1225995088.3733.231.camel@pc105-c703.uibk.ac.at> <49134E2F.8010704@reed.com> <04EC169B-5D71-427D-989F-E41FE30BEB9E@cisco.com> <66011996-5C5B-4AF1-839D-1075A0D33CD1@surrey.ac.uk> Message-ID: <63B29FC7-B661-46AF-A0C3-3587B26BD864@cisco.com> On Nov 7, 2008, at 3:33 PM, Lloyd Wood wrote: > On 6 Nov 2008, at 21:18, Fred Baker wrote: >> It's kind of hard to get a message to a destination, fixed or >> mobile, without giving the network an idea of where it is to go. >> That's kind of the point of the locator. >> >> That said, the point of the endpoint ID is to identify the >> application on the system, the transport connection endpoint, >> independent of its location. If the application moves from one >> system to another, the transport connection needs to be able to >> follow it. > > can anyone explain how that clear explanation of the endpoint ID > matches with the definition of endpoint ID given in RFC5050, section > 4.4? About the same way the description maps to the endpoint ID found in RFC 5201-5201 and 5338. Like HIP's Endpoint ID, DTN's Bundle ID lacks any way for a system, given knowledge of what instance of an application it wants to talk with or what data object it wants to find, to determine the locator of that object. Given the locator we can establish whether we are talking to the right system, but not the other way around. David is postulating that the only thing we need is a name for the object we want to look at, and we can determine everything else we need to know. It's wonderful theory, and on an isolated LAN it might even make sense. From fred at cisco.com Fri Nov 7 17:07:24 2008 From: fred at cisco.com (Fred Baker) Date: Fri, 7 Nov 2008 17:07:24 -0800 Subject: [e2e] a means to an end In-Reply-To: <4914E59D.9030204@reed.com> References: <491190DE.7010706@sics.se> <1225995088.3733.231.camel@pc105-c703.uibk.ac.at> <49134E2F.8010704@reed.com> <04EC169B-5D71-427D-989F-E41FE30BEB9E@cisco.com> <66011996-5C5B-4AF1-839D-1075A0D33CD1@surrey.ac.uk> <63B29FC7-B661-46AF-A0C3-3587B26BD864@cisco.com> <4914E59D.9030204@reed.com> Message-ID: <880D8DCD-1F14-4244-A923-DF86382BE64B@cisco.com> On Nov 7, 2008, at 5:04 PM, David P. Reed wrote: > In particular, we might well wonder why all network operators who > maintain routers should become privileged to know where *all* the > people on the planet who *might* communicate are currently located > in order to deliver messages connecting a vanishingly small subset > of the N^2 possible pairings of customers. Should the routers in > Russia know when a Georgian raising money for military support > travels between NY and China? If that person never needs to talk to > a Russian, why distribute the tracking data in any form, much less > distribute it to places where communications will never be sought? I'm not at all sure what you're talking about. AFAIK, IP addresses are not assigned to people. From v13 at v13.gr Sat Nov 8 11:06:18 2008 From: v13 at v13.gr (Stefanos Harhalakis) Date: Sat, 8 Nov 2008 21:06:18 +0200 Subject: [e2e] a means to an end In-Reply-To: <4914E59D.9030204@reed.com> References: <63B29FC7-B661-46AF-A0C3-3587B26BD864@cisco.com> <4914E59D.9030204@reed.com> Message-ID: <200811082106.18795.v13@v13.gr> On Saturday 08 November 2008, David P. Reed wrote: > possible pairings of customers. Should the routers in Russia know when > a Georgian raising money for military support travels between NY and > China? If that person never needs to talk to a Russian, why distribute > the tracking data in any form, much less distribute it to places where > communications will never be sought? The words 'If' and 'never' in the above sentence are very hard to analyze and very difficult to prove. I believe that the sort answer is 'yes they should'. Adding such low-level barriers and borders to the Internet doesn't seem a good idea. Don't forget that much of Internet traffic (if not the majority) is -or started as- non company-related. Thus, I'd rephrase your question as: "Should a kid in Russia be able to play a p2p on-line game with a Georgian kid and also browse a chinese web server?" Perhaps the above sentences aren't exactly what you mean. At some point you're talking about something like 'on-demand routing' but considering the number of remote-ends (I don't call them destinations) an ISP communicates with at any point of time, most probably the whole world is covered. From dpreed at reed.com Sat Nov 8 11:32:45 2008 From: dpreed at reed.com (David P. Reed) Date: Sat, 08 Nov 2008 14:32:45 -0500 Subject: [e2e] [unclassified] Re: a means to an end In-Reply-To: <200811082106.18795.v13@v13.gr> References: <63B29FC7-B661-46AF-A0C3-3587B26BD864@cisco.com> <4914E59D.9030204@reed.com> <200811082106.18795.v13@v13.gr> Message-ID: <4915E95D.7030206@reed.com> I was addressing the idea that the network necessarily needs to know "where" for all entities not actually communicating at the moment, just in case any particular entity decides to get some information it has. My point is that it is not necessary, and it may also be harmful. As a consequence, perhaps one should try to design communications functions that are not founded on a pervasive "location tracking" function. The "content centric" network approach of Van Jacobsen is one such approach that recognizes that not all communications involves locating, but instead involves propagating and fetching information by its name. One can make such a system efficient without basing it on "location tracking" forms of routing. Another simple example would be a node that uses IPv4's loose source routing option for a mobile node to maintain a path to and from its current location that is known only to a subset of endpoints that it trusts. The endpoint's current location would be revealed only along the path it traverses, not more widely than that. (this is like "on demand" routing, but moves the function into the endpoints, rather than into the routers). Stefanos Harhalakis wrote: > On Saturday 08 November 2008, David P. Reed wrote: > >> possible pairings of customers. Should the routers in Russia know when >> a Georgian raising money for military support travels between NY and >> China? If that person never needs to talk to a Russian, why distribute >> the tracking data in any form, much less distribute it to places where >> communications will never be sought? >> > > The words 'If' and 'never' in the above sentence are very hard to analyze > and very difficult to prove. I believe that the sort answer is 'yes they > should'. Adding such low-level barriers and borders to the Internet doesn't > seem a good idea. > > Don't forget that much of Internet traffic (if not the majority) is -or > started as- non company-related. Thus, I'd rephrase your question as: > > "Should a kid in Russia be able to play a p2p on-line game with a Georgian kid > and also browse a chinese web server?" > > Perhaps the above sentences aren't exactly what you mean. At some point > you're talking about something like 'on-demand routing' but considering the > number of remote-ends (I don't call them destinations) an ISP communicates > with at any point of time, most probably the whole world is covered. > > From huitema at windows.microsoft.com Sat Nov 8 11:56:40 2008 From: huitema at windows.microsoft.com (Christian Huitema) Date: Sat, 8 Nov 2008 11:56:40 -0800 Subject: [e2e] a means to an end In-Reply-To: <880D8DCD-1F14-4244-A923-DF86382BE64B@cisco.com> References: <491190DE.7010706@sics.se> <1225995088.3733.231.camel@pc105-c703.uibk.ac.at> <49134E2F.8010704@reed.com> <04EC169B-5D71-427D-989F-E41FE30BEB9E@cisco.com> <66011996-5C5B-4AF1-839D-1075A0D33CD1@surrey.ac.uk> <63B29FC7-B661-46AF-A0C3-3587B26BD864@cisco.com> <4914E59D.9030204@reed.com> <880D8DCD-1F14-4244-A923-DF86382BE64B@cisco.com> Message-ID: <8EFB68EAE061884A8517F2A755E8B60A13DB8E26DF@NA-EXMSG-W601.wingroup.windeploy.ntdev.microsoft.com> > I'm not at all sure what you're talking about. AFAIK, IP addresses are > not assigned to people. Let's look at a concrete, market driven evaluation of that. We have a "privacy" process at Microsoft, where reviewers assess the impact of proposed products on the users' privacy, and often recommend design changes. A key part of the assessment is whether the application handles "personal identifiers", i.e. pieces of data that can be used to identify or track a person. If an application is found to do that, then a number of more stringent rules kick in, such as getting user consent, having processes to safeguard the data, and in fact quite a few more. Long story short: we expressly consider IP addresses as personal identifiers, and submit them to pretty much the same rules as e-mail addresses. Yes, you can argue that IP addresses are sometimes shared and sometimes changed, but we believe there is enough correlation between IP addresses and user identities to place them in the "personal identifier" category, even if that is quite inconvenient for product designers. I don't know whether we can design networks where locators and identifiers would not have that "personal identifier" characteristic. For example, identifiers that remain valid for a long enough period would de facto become user identifiers. Locators that embeds unique identification of the end-end delivery point would also have that characteristic. -- Christian Huitema From pekka.nikander at nomadiclab.com Sat Nov 8 23:25:38 2008 From: pekka.nikander at nomadiclab.com (Pekka Nikander) Date: Sun, 9 Nov 2008 09:25:38 +0200 Subject: [e2e] a means to an end In-Reply-To: References: <20081106205204.CCE5D28E155@aland.bbn.com> <49135FAA.6080603@reed.com> Message-ID: <2F96E808-6A16-46A0-B836-819C220EE701@nomadiclab.com> A few potential ingredients. Path-specific locators seem to have lower overall utility, as such, but have the large benefit of not being directly useful for DDoS. Obviously, they need to be updated also when the receiver moves, not only when the sender moves. Overall, they share many of the problems with source routing, but when properly designed perhaps not the most blatant security vulnerabilities. People seem to do just fine with MPLS stacks... Path-specific locators can be more easily converted to time-specific ones than universal locators.... A market of competing services usually seems to yield better dynamics than one centrally controlled service. If scalability is an issue, breaking down the service into smaller pieces may make it more manageable. Besides, aren't we more bowing to Reed's law than Metcalfe's law these days? A service per community, perhaps? As someone else already pointed out, once you have an end-to-end association, updating the locators becomes easier than finding the other party in the first place. Especially if you can make before break, which of course is useful for any hard end-to-end services anyway. Aren't we moving away from end-to-end to some variant of store-and- forward? Or, it is all just time scales? For 200 ms end-to-end latency the tricks needed are different from those you need with a 2000 ms time budget; most of today's Internet traffic seems to do just fine with 2-4s perceived latency. (TCP duh, but that's a detail.) Convert queues to opportunistic caches, observe that the prices of storage still go down much faster than bandwidth, and realise that soon you'd better send all the time on those precious long hauls even if you don't have an immediate paying receiver. --Pekka, ducking for tomatoes On 7 Nov 2008, at 11:31, Jon Crowcroft wrote: > my and my big mouth - > > i knew this would get hijacked into a philosohpy discussion. > > I am talking about this as I think the internet community is in denial > and uses philopshy as an escape valve to avoid discussing the actual > elephant in the room > > We need a new kind of network layer _service_ - to support finding > end systems > as they move around and so on. > > We have an idea of the workload on the service. > > It is unusual kind of service for the internet community as it isnt > an overlay, > it has to work inside the IP layer > as it is something end systems and routers need to share state/fate > with, > (we hit this before implicity with multicast, and couldn't ever > face up to it properly) > > It would be nice to capitalise on the last ten years of > internet scale content service research, > since the actual _volume_ of data in this service system is low, > but the churn is very high. > > The service _might_ be implemented by some sort of 1-hop DHT > but it needs to support consistency and security. > > It isnt DNS based and it isnt BGP > based because both of those technologies > have major design flaws and surive > only due to heroic bandaids > > we need a Mocapetris for the 21st century, clearly > > it aint me....it might be Van:) > > cheers > > jon > > From dpreed at reed.com Sun Nov 9 04:31:00 2008 From: dpreed at reed.com (David P. Reed) Date: Sun, 09 Nov 2008 07:31:00 -0500 Subject: [e2e] a means to an end In-Reply-To: <2F96E808-6A16-46A0-B836-819C220EE701@nomadiclab.com> References: <20081106205204.CCE5D28E155@aland.bbn.com> <49135FAA.6080603@reed.com> <2F96E808-6A16-46A0-B836-819C220EE701@nomadiclab.com> Message-ID: <4916D804.8070508@reed.com> Riffing on Pekka's opening - why not multiple competing "routing" layers? In the old days, when the Internet was about tying together different pre-existing networks into a coherent whole, it *was* one of many. (at least one other routing mechanism existed - uucp -- and it used some of the same pre-existing networks). Those many differed rather more than they need to - there was no common "sockets" API at the endpoints that could unify them, for example. But that is a result of their divergent heritages. Subsequently, they entered a melting pot, giving us the universal culture we call the Internet Today. The current state of the Internet is that IP is still pretty trivial and includes some little-used tools (loose source routing, unroutable addresses, ...) that can be used by convention to build alternative routing schemes at modest cost. Programmable routers (Linux iptables, Click) and switches (OpenFlow) are becoming easy to deploy. Rather than a "single routing strategy to rule them all" perhaps they should compete for business, overlaid on a universal world-wide "dumb" fabric that they use in creative ways? This sort of thing is what Van is doing, what some DTNers are doing, what Tor is doing. Rather than objecting to them on trivial grounds (saving pennies, wirespeed content inspection, need for "lawful intercept") perhaps we need to do research on them leading to a routing layer that has emergent properties other than DDoS. Pekka Nikander wrote: > A few potential ingredients. > > > Path-specific locators seem to have lower overall utility, as such, > but have the large benefit of not being directly useful for DDoS. > Obviously, they need to be updated also when the receiver moves, not > only when the sender moves. Overall, they share many of the problems > with source routing, but when properly designed perhaps not the most > blatant security vulnerabilities. People seem to do just fine with > MPLS stacks... > > Path-specific locators can be more easily converted to time-specific > ones than universal locators.... > > > A market of competing services usually seems to yield better dynamics > than one centrally controlled service. If scalability is an issue, > breaking down the service into smaller pieces may make it more > manageable. Besides, aren't we more bowing to Reed's law than > Metcalfe's law these days? A service per community, perhaps? > > > As someone else already pointed out, once you have an end-to-end > association, updating the locators becomes easier than finding the > other party in the first place. Especially if you can make before > break, which of course is useful for any hard end-to-end services anyway. > > > Aren't we moving away from end-to-end to some variant of > store-and-forward? Or, it is all just time scales? For 200 ms > end-to-end latency the tricks needed are different from those you need > with a 2000 ms time budget; most of today's Internet traffic seems to > do just fine with 2-4s perceived latency. (TCP duh, but that's a > detail.) Convert queues to opportunistic caches, observe that the > prices of storage still go down much faster than bandwidth, and > realise that soon you'd better send all the time on those precious > long hauls even if you don't have an immediate paying receiver. > > > --Pekka, ducking for tomatoes > > > On 7 Nov 2008, at 11:31, Jon Crowcroft wrote: > >> my and my big mouth - >> >> i knew this would get hijacked into a philosohpy discussion. >> >> I am talking about this as I think the internet community is in denial >> and uses philopshy as an escape valve to avoid discussing the actual >> elephant in the room >> >> We need a new kind of network layer _service_ - to support finding >> end systems >> as they move around and so on. >> >> We have an idea of the workload on the service. >> >> It is unusual kind of service for the internet community as it isnt >> an overlay, >> it has to work inside the IP layer >> as it is something end systems and routers need to share state/fate >> with, >> (we hit this before implicity with multicast, and couldn't ever face >> up to it properly) >> >> It would be nice to capitalise on the last ten years of >> internet scale content service research, >> since the actual _volume_ of data in this service system is low, >> but the churn is very high. >> >> The service _might_ be implemented by some sort of 1-hop DHT >> but it needs to support consistency and security. >> >> It isnt DNS based and it isnt BGP >> based because both of those technologies >> have major design flaws and surive >> only due to heroic bandaids >> >> we need a Mocapetris for the 21st century, clearly >> >> it aint me....it might be Van:) >> >> cheers >> >> jon >> >> > > From Jon.Crowcroft at cl.cam.ac.uk Sun Nov 9 06:10:42 2008 From: Jon.Crowcroft at cl.cam.ac.uk (Jon Crowcroft) Date: Sun, 09 Nov 2008 14:10:42 +0000 Subject: [e2e] a means to an end In-Reply-To: <2F96E808-6A16-46A0-B836-819C220EE701@nomadiclab.com> References: <20081106205204.CCE5D28E155@aland.bbn.com> <49135FAA.6080603@reed.com> <2F96E808-6A16-46A0-B836-819C220EE701@nomadiclab.com> Message-ID: we have a bunch of interpretations of IP addresses today (many more than "officially" sanctioned) and I agree that a new id-loc split is going to have a number of interpretations (probably all the ones we have now, and definitely some new ones) so assuming the id part is done (without loss of generality:) we can discuss how locators work and how to map from diferent kinds of id, to loc (and, if/when/where needed or allowed, pace, scott brim) from loc to id - but lets leave that for now) locators can refer to fixed points of network attachment (like phone landline numbers refer to sockets on the wall) to objects (in content) where they look a bit like anycast to groups of recipients (where they are group locs and need recursively (and distributedly) remapping to actual locs and to current locations of a mobile node where we need/can have a more efficient way to remap when the node moves for the other node(s) currently in session with this one, than we do for new nodes trying to find it... (actually, i am not sure if this is true for both ends moving unless you buy into router state which has to scale order number of current mobile sessions, which doesn't look tracatable to me, or to hierarchical location thingies, which might be ok but ....) anyhow the API for host and router is still the same - the point is what sort of service do you want? (there's some nice work by colleagues here in this context ages back - viz http://www.cl.cam.ac.uk/~pes20/nomadicpict.html In missive <2F96E808-6A16-46A0-B836-819C220EE701 at nomadiclab.com>, Pekka Nikande r typed: >>A few potential ingredients. >> >> >>Path-specific locators seem to have lower overall utility, as such, >>but have the large benefit of not being directly useful for DDoS. >>Obviously, they need to be updated also when the receiver moves, not >>only when the sender moves. Overall, they share many of the problems >>with source routing, but when properly designed perhaps not the most >>blatant security vulnerabilities. People seem to do just fine with >>MPLS stacks... >> >>Path-specific locators can be more easily converted to time-specific >>ones than universal locators.... >> >> >>A market of competing services usually seems to yield better dynamics >>than one centrally controlled service. If scalability is an issue, >>breaking down the service into smaller pieces may make it more >>manageable. Besides, aren't we more bowing to Reed's law than >>Metcalfe's law these days? A service per community, perhaps? >> >> >>As someone else already pointed out, once you have an end-to-end >>association, updating the locators becomes easier than finding the >>other party in the first place. Especially if you can make before >>break, which of course is useful for any hard end-to-end services >>anyway. >> >> >>Aren't we moving away from end-to-end to some variant of store-and- >>forward? Or, it is all just time scales? For 200 ms end-to-end >>latency the tricks needed are different from those you need with a >>2000 ms time budget; most of today's Internet traffic seems to do just >>fine with 2-4s perceived latency. (TCP duh, but that's a detail.) >>Convert queues to opportunistic caches, observe that the prices of >>storage still go down much faster than bandwidth, and realise that >>soon you'd better send all the time on those precious long hauls even >>if you don't have an immediate paying receiver. >> >> >>--Pekka, ducking for tomatoes >> >> >>On 7 Nov 2008, at 11:31, Jon Crowcroft wrote: >> >>> my and my big mouth - >>> >>> i knew this would get hijacked into a philosohpy discussion. >>> >>> I am talking about this as I think the internet community is in denial >>> and uses philopshy as an escape valve to avoid discussing the actual >>> elephant in the room >>> >>> We need a new kind of network layer _service_ - to support finding >>> end systems >>> as they move around and so on. >>> >>> We have an idea of the workload on the service. >>> >>> It is unusual kind of service for the internet community as it isnt >>> an overlay, >>> it has to work inside the IP layer >>> as it is something end systems and routers need to share state/fate >>> with, >>> (we hit this before implicity with multicast, and couldn't ever >>> face up to it properly) >>> >>> It would be nice to capitalise on the last ten years of >>> internet scale content service research, >>> since the actual _volume_ of data in this service system is low, >>> but the churn is very high. >>> >>> The service _might_ be implemented by some sort of 1-hop DHT >>> but it needs to support consistency and security. >>> >>> It isnt DNS based and it isnt BGP >>> based because both of those technologies >>> have major design flaws and surive >>> only due to heroic bandaids >>> >>> we need a Mocapetris for the 21st century, clearly >>> >>> it aint me....it might be Van:) >>> >>> cheers >>> >>> jon >>> >>> >> cheers jon From jnc at mercury.lcs.mit.edu Sun Nov 9 06:48:21 2008 From: jnc at mercury.lcs.mit.edu (Noel Chiappa) Date: Sun, 9 Nov 2008 09:48:21 -0500 (EST) Subject: [e2e] a means to an end Message-ID: <20081109144821.687B06BE555@mercury.lcs.mit.edu> > From: "David P. Reed" > Date: Sun, 09 Nov 2008 07:31:00 -0500 > why not multiple competing "routing" layers? > ... > Rather than a "single routing strategy to rule them all" perhaps they > should compete for business, overlaid on a universal world-wide "dumb" > fabric that they use in creative ways? By "routing", do you mean 'forwarding of user traffic', or 'selection of paths'? If the former, the whole concept of MPLS was to allow a single fabric to be used to simultaneously support multiple different traffic handling paradigms; so one could have, for want of a better term (connection-based drags in too many other concepts), a flow-based paradigm running simultaneously with a pure datagram model (i.e. no setup, no concept or recognition of traffic aggregates). If the latter, some previous work I did tried to bring in the concept of allowing competing path-selection algorithms. The design did share a single underlying database of information about the network between them (of connectivity), but it seemed to me that that level of commonality didn't unduly burden the ability to go different ways, and having that common underlying database had advantages that offset its disadvantages. I know there is a position that there are some connectivity models which can't be represented in the model we picked (a graph), but the architecture did allow non-graph connectivity models in localized areas, and I still think that for the overall representation of the global network, the graph model is best. Noel From dpreed at reed.com Sun Nov 9 11:05:15 2008 From: dpreed at reed.com (David P. Reed) Date: Sun, 09 Nov 2008 14:05:15 -0500 Subject: [e2e] a means to an end In-Reply-To: <940A6613-E050-4F8A-AA62-12A4B7ACEB0C@cisco.com> References: <20081106205204.CCE5D28E155@aland.bbn.com> <49135FAA.6080603@reed.com> <2F96E808-6A16-46A0-B836-819C220EE701@nomadiclab.com> <4916D804.8070508@reed.com> <940A6613-E050-4F8A-AA62-12A4B7ACEB0C@cisco.com> Message-ID: <4917346B.3080902@reed.com> I'm completely confused by the suggestions from Fred and Noel that 802.11 802.1, MPLS are somehow competing with the current IP routing system. None of those are end-to-end solutions, ... Is the confusion between the limited scope of 802.11 and 802.16 and the planet-scale scope of IP addressing really prevalent among the community? Maybe this explains why so many seem to confuse the hardware and cabling with networking. KInd of like confusing the Intel instruction set with the Win32 API, or confusing the workings of the marketplace with the resolution of social issues. Fred Baker wrote: > > On Nov 9, 2008, at 4:31 AM, David P. Reed wrote: > >> why not multiple competing "routing" layers? > > We have those, in spades. Consider 802.11, 802.1, 802.16, ATM and its > predecessors, etc. > From jnc at mercury.lcs.mit.edu Sun Nov 9 17:05:26 2008 From: jnc at mercury.lcs.mit.edu (Noel Chiappa) Date: Sun, 9 Nov 2008 20:05:26 -0500 (EST) Subject: [e2e] a means to an end Message-ID: <20081110010527.10D166BE590@mercury.lcs.mit.edu> > From: "David P. Reed" > I'm completely confused by the suggestions from ... Noel that .. MPLS > are somehow competing with the current IP routing system. > None of those are end-to-end solutions ... I didn't say it was. I was merely providing it as a concrete *example* of an architectural approach to packet forwarding which can support a number of different forwarding models. And you never answered my question about whether in speaking of "'routing' layers" you meant "'forwarding of user traffic', or 'selection of paths'" - or both. Noel From dpreed at reed.com Sun Nov 9 19:11:20 2008 From: dpreed at reed.com (David P. Reed) Date: Sun, 09 Nov 2008 22:11:20 -0500 Subject: [e2e] a means to an end In-Reply-To: <459576D8-21EF-4757-9E89-894B67E8C48D@cisco.com> References: <20081106205204.CCE5D28E155@aland.bbn.com> <49135FAA.6080603@reed.com> <2F96E808-6A16-46A0-B836-819C220EE701@nomadiclab.com> <4916D804.8070508@reed.com> <940A6613-E050-4F8A-AA62-12A4B7ACEB0C@cisco.com> <4917346B.3080902@reed.com> <459576D8-21EF-4757-9E89-894B67E8C48D@cisco.com> Message-ID: <4917A658.8070707@reed.com> I was referring to a different possibility thinking from the viewpoint of a "network over networks" that provides connectivity among IP end-hosts: there is no reason not to have a number of competing routing systems all sharing (agreeing to) the same IP (v4 or v6) address space, at a planetary scale. That could be done by using LSR or GRE or tunneling to get from and endpoint to the first hop router of its chosen routing system. Today's "tunnel broker" system for IPv6 actually looks a bit like that - it competes with the "standard" IPv4 routing to get to a subset of the same endpoints. And a corporate "intranet" also looks like that, approximately. But I am talking about a "public" not a "private" Internet. Fred Baker wrote: > > On Nov 9, 2008, at 11:05 AM, David P. Reed wrote: >> I'm completely confused by the suggestions from Fred and Noel that >> 802.11 802.1, MPLS are somehow competing with the current IP routing >> system. None of those are end-to-end solutions, ... > > Depends on your viewpoint. There are those that think of them as end > to end solutions in some stated domain. In Beijing during the last > week of October I visited a school that literally was proposing > MPLS-on-Ethernet as an end-to-end solution. > > The reason I mentioned them is this. You noted that the Internet was > designed as a network of networks, and IP was the ring to bind them. > True enough. We have two variations on that in the present Internet. > One is that we literally have separate networks connected through a > collection of backbone networks, often by means of network address > translators or other gateways. The other is that the IP protocol > usually runs atop some lower layer (what I call "intranet", what > others inexplicably call "layer 2") networks, including various > extended LAN, circuit switch, and virtual circuit networks. > > To my way of thinking, whether you mean this in an infrastructure > sense, and administrative sense, or a routing protocol sense, the > Internet is very much a network of networks. > >> Is the confusion between the limited scope of 802.11 and 802.16 and the >> planet-scale scope of IP addressing really prevalent among the >> community? >> >> Maybe this explains why so many seem to confuse the hardware and cabling >> with networking. KInd of like confusing the Intel instruction set with >> the Win32 API, or confusing the workings of the marketplace with the >> resolution of social issues. >> >> Fred Baker wrote: >>> >>> On Nov 9, 2008, at 4:31 AM, David P. Reed wrote: >>> >>>> why not multiple competing "routing" layers? >>> >>> We have those, in spades. Consider 802.11, 802.1, 802.16, ATM and >>> its predecessors, etc. >>> >> > > From pekka.nikander at nomadiclab.com Mon Nov 10 00:57:25 2008 From: pekka.nikander at nomadiclab.com (Pekka Nikander) Date: Mon, 10 Nov 2008 10:57:25 +0200 Subject: [e2e] a means to an end In-Reply-To: <20081109144821.687B06BE555@mercury.lcs.mit.edu> References: <20081109144821.687B06BE555@mercury.lcs.mit.edu> Message-ID: <250CBC06-5592-488D-9EB9-5CF5C56D77C8@nomadiclab.com> > If [path selection], some previous work I did tried to bring in the > concept of > allowing competing path-selection algorithms. The design did share a > single > underlying database of information about the network between them (of > connectivity), but it seemed to me that that level of commonality > didn't > unduly burden the ability to go different ways, and having that common > underlying database had advantages that offset its disadvantages. I > know > there is a position that there are some connectivity models which > can't be > represented in the model we picked (a graph), but the architecture > did allow > non-graph connectivity models in localized areas, and I still think > that for > the overall representation of the global network, the graph model is > best. And what did you learn? What are the tussles? Is it realistic for different players to trust each other with enough of information so that useful-enough graph approximations can be formed? Are there situations where one can benefit too much from lying to the peers? --Pekka From dpreed at reed.com Mon Nov 10 05:02:28 2008 From: dpreed at reed.com (David P. Reed) Date: Mon, 10 Nov 2008 08:02:28 -0500 Subject: [e2e] a means to an end In-Reply-To: <250CBC06-5592-488D-9EB9-5CF5C56D77C8@nomadiclab.com> References: <20081109144821.687B06BE555@mercury.lcs.mit.edu> <250CBC06-5592-488D-9EB9-5CF5C56D77C8@nomadiclab.com> Message-ID: <491830E4.70806@reed.com> Noel's ideas were not tried. They were (essentially) shouted down or ignored, take your pick. There is a lot of merit in those ideas, and perhaps they should be resurrected. The one fear I personally have is that the techniques he described have the risk of creating non-interconnected "walled gardens" overlaid on the network over networks. That's why I talked about competing for *public* delivery and using the same common address space. Pekka Nikander wrote: >> If [path selection], some previous work I did tried to bring in the >> concept of >> allowing competing path-selection algorithms. The design did share a >> single >> underlying database of information about the network between them (of >> connectivity), but it seemed to me that that level of commonality didn't >> unduly burden the ability to go different ways, and having that common >> underlying database had advantages that offset its disadvantages. I know >> there is a position that there are some connectivity models which >> can't be >> represented in the model we picked (a graph), but the architecture >> did allow >> non-graph connectivity models in localized areas, and I still think >> that for >> the overall representation of the global network, the graph model is >> best. > > And what did you learn? What are the tussles? Is it realistic for > different players to trust each other with enough of information so > that useful-enough graph approximations can be formed? Are there > situations where one can benefit too much from lying to the peers? > > --Pekka > > From jnc at mercury.lcs.mit.edu Mon Nov 10 09:09:04 2008 From: jnc at mercury.lcs.mit.edu (Noel Chiappa) Date: Mon, 10 Nov 2008 12:09:04 -0500 (EST) Subject: [e2e] a means to an end Message-ID: <20081110170904.41E096BE580@mercury.lcs.mit.edu> > From: Pekka Nikander > Date: Sun, 9 Nov 2008 09:25:38 +0200 > Path-specific locators Let me make sure I understand what you mean by this term. To me, it implies 'a source route composed of names of only local scope' - whether the 'names' refer to outbound-interface/next-hop pairs, or local flow names, or whatever, I don't have any specific concept. To justify why it seems to me that that's what must be implied, 'path-specific' first seems to imply that the name(s) in it do have local scope (i.e. a particular path-specific locator refers to two different destinations, when interpreted at different places in the network). Next, unless there's *something* in that first local scope which will get that packet to the ultimate destination based only a single local-scope name (which I think is unfeasible, for reasons I will discuss below), there must be a series of these scope-local names - which sounds awfully like a source route. Is that a correct description of what you visualize them to be? If not, can you give a bit more detail on what that term implies (in terms of mechanism) to you? The reason I think that it's infeasible to have a path-specific locator be composed of only a single local-scope name - e.g. a flow which goes all the way to the destination - is that that general approach doesn't seem to offer much, when scaled up to support all possible destinations in the network. For instance, if they are flows, you'd need to have a full set (to every destination in the network) at every source in the network - the N^2 problem. Even if it's not flows, but rather e.g. a translation which turns that scope-local name into a global locator, the path-specific locator is really just a security layer which obscures what global locator that scope-local locator translates to. It can't be much shorter/simpler than a global locator because that single scope-local locator has to be able to specify the full range of destinations that can be specified in a global locator. Or am I missing something? Noel From jnc at mercury.lcs.mit.edu Mon Nov 10 09:23:29 2008 From: jnc at mercury.lcs.mit.edu (Noel Chiappa) Date: Mon, 10 Nov 2008 12:23:29 -0500 (EST) Subject: [e2e] a means to an end Message-ID: <20081110172329.C2C856BE586@mercury.lcs.mit.edu> > From: Jon Crowcroft > locators can refer to fixed points of network attachment ... to objects > (in content) where they look a bit like anycast Umm, only in an IPv4-like-model where there's a conflation between the concept of 'routing table entry' and 'destination' is anycast a location. But see my next point... > to groups of recipients (where they are group locs and need recursively > (and distributedly) remapping To me, this is a different, higher-level semantic concept. A group doesn't have a 'location', its (only?) attribute is 'list of members', and each element in *that* set has the property 'location'. > anyhow the API for host and router is still the same But is this viable? Can you fully introduce richer semantics into the network if the only interface to them is the unmodified old one? Noel From fred at cisco.com Sun Nov 9 07:22:01 2008 From: fred at cisco.com (Fred Baker) Date: Sun, 9 Nov 2008 07:22:01 -0800 Subject: [e2e] a means to an end In-Reply-To: <4916D804.8070508@reed.com> References: <20081106205204.CCE5D28E155@aland.bbn.com> <49135FAA.6080603@reed.com> <2F96E808-6A16-46A0-B836-819C220EE701@nomadiclab.com> <4916D804.8070508@reed.com> Message-ID: <940A6613-E050-4F8A-AA62-12A4B7ACEB0C@cisco.com> On Nov 9, 2008, at 4:31 AM, David P. Reed wrote: > why not multiple competing "routing" layers? We have those, in spades. Consider 802.11, 802.1, 802.16, ATM and its predecessors, etc. From fred at cisco.com Sun Nov 9 15:20:56 2008 From: fred at cisco.com (Fred Baker) Date: Sun, 9 Nov 2008 15:20:56 -0800 Subject: [e2e] a means to an end In-Reply-To: <4917346B.3080902@reed.com> References: <20081106205204.CCE5D28E155@aland.bbn.com> <49135FAA.6080603@reed.com> <2F96E808-6A16-46A0-B836-819C220EE701@nomadiclab.com> <4916D804.8070508@reed.com> <940A6613-E050-4F8A-AA62-12A4B7ACEB0C@cisco.com> <4917346B.3080902@reed.com> Message-ID: <459576D8-21EF-4757-9E89-894B67E8C48D@cisco.com> On Nov 9, 2008, at 11:05 AM, David P. Reed wrote: > I'm completely confused by the suggestions from Fred and Noel that > 802.11 802.1, MPLS are somehow competing with the current IP routing > system. None of those are end-to-end solutions, ... Depends on your viewpoint. There are those that think of them as end to end solutions in some stated domain. In Beijing during the last week of October I visited a school that literally was proposing MPLS- on-Ethernet as an end-to-end solution. The reason I mentioned them is this. You noted that the Internet was designed as a network of networks, and IP was the ring to bind them. True enough. We have two variations on that in the present Internet. One is that we literally have separate networks connected through a collection of backbone networks, often by means of network address translators or other gateways. The other is that the IP protocol usually runs atop some lower layer (what I call "intranet", what others inexplicably call "layer 2") networks, including various extended LAN, circuit switch, and virtual circuit networks. To my way of thinking, whether you mean this in an infrastructure sense, and administrative sense, or a routing protocol sense, the Internet is very much a network of networks. > Is the confusion between the limited scope of 802.11 and 802.16 and > the > planet-scale scope of IP addressing really prevalent among the > community? > > Maybe this explains why so many seem to confuse the hardware and > cabling > with networking. KInd of like confusing the Intel instruction set > with > the Win32 API, or confusing the workings of the marketplace with the > resolution of social issues. > > Fred Baker wrote: >> >> On Nov 9, 2008, at 4:31 AM, David P. Reed wrote: >> >>> why not multiple competing "routing" layers? >> >> We have those, in spades. Consider 802.11, 802.1, 802.16, ATM and >> its predecessors, etc. >> > From swb at employees.org Mon Nov 10 10:52:28 2008 From: swb at employees.org (Scott Brim) Date: Mon, 10 Nov 2008 13:52:28 -0500 Subject: [e2e] a means to an end In-Reply-To: <4916D804.8070508@reed.com> References: <20081106205204.CCE5D28E155@aland.bbn.com> <49135FAA.6080603@reed.com> <2F96E808-6A16-46A0-B836-819C220EE701@nomadiclab.com> <4916D804.8070508@reed.com> Message-ID: <18712.33516.635568.347349@sbrim-mbp.local> Excerpts from David P. Reed at 07:31:00 -0500 on Sun 9 Nov 2008: > Riffing on Pekka's opening - why not multiple competing "routing" > layers? Yes, you can run multiple ships-in-the-night "networks" over a single underlying "layer network", but how do the endpoints know what they can even try to reach? One way of doing that is to have a common internetworking layer -- call it the Internet. Another is to have the endpoints know how to search according to the protocols they can speak and networks they are connected to (but only those). This means smart endpoints and difficult customer support. I predict that if you ran this experiment, everyone would converge to a single "network" after all. > In the old days, when the Internet was about tying together > different pre-existing networks into a coherent whole, it *was* one of > many. (at least one other routing mechanism existed - uucp -- and it > used some of the same pre-existing networks). UUCP had totally different syntax and the protocols to use were (are) implicit in the addressing. From lynne at telemuse.net Mon Nov 10 13:03:48 2008 From: lynne at telemuse.net (Lynne Jolitz) Date: Mon, 10 Nov 2008 13:03:48 -0800 Subject: [e2e] a means to an end In-Reply-To: <459576D8-21EF-4757-9E89-894B67E8C48D@cisco.com> References: <20081106205204.CCE5D28E155@aland.bbn.com> <49135FAA.6080603@reed.com> <2F96E808-6A16-46A0-B836-819C220EE701@nomadiclab.com> <4916D804.8070508@reed.com> <940A6613-E050-4F8A-AA62-12A4B7ACEB0C@cisco.com> <4917346B.3080902@reed.com> <459576D8-21EF-4757-9E89-894B67E8C48D@cisco.com> Message-ID: <4918A1B4.8010205@telemuse.net> I assume by Fred's "MPLS on Ethernet" mention that the reason underlying their unusual approach is that they see no point (except more overhead) in the additional layers below an MPLS routing layer, so the end-points are the only things that matter (while ignoring of course, diagnostics, blockage identification and so forth). But let's take this further. An old suggestion proposed at an IETF in the early 1980's was similarly to disconnect the appearance of the routing layer and visibility of the network itself and tunnel everything on top of the network, so you'd have a layer 3 network encapsulated on top of a layer-3 network not visible except within the routing cloud. This was to hide the actual infrastructure so it couldn't be attacked. One could even encapsulate with TCP instead of IP such that you could allocate bandwidth portions and routes in an independent way - more like an OC IS-to-IS routing scheme. The view was the only people who cared about routing were the ones who could see how it was working, so why be open to DDOS attacks on the routers themselves, and also so as to promote quality. This was before BGP. So now we've got a Chinese proposal on MPLS-on-Ethernet. The advantage of their approach is that at layer 2 you can do it with mindless switches and spanning tree algorithms. This means very efficient, very low power, very dumb routers. Can this be produced? Yes, in massive quantities. Would people buy this? Very likely if cheap enough. How would massive deployment impact the Internet? That's one I'm wondering about. Lynne Jolitz. Fred Baker wrote: > > On Nov 9, 2008, at 11:05 AM, David P. Reed wrote: > >> I'm completely confused by the suggestions from Fred and Noel that >> 802.11 802.1, MPLS are somehow competing with the current IP routing >> system. None of those are end-to-end solutions, ... > > > Depends on your viewpoint. There are those that think of them as end > to end solutions in some stated domain. In Beijing during the last > week of October I visited a school that literally was proposing MPLS- > on-Ethernet as an end-to-end solution. > > The reason I mentioned them is this. You noted that the Internet was > designed as a network of networks, and IP was the ring to bind them. > True enough. We have two variations on that in the present Internet. > One is that we literally have separate networks connected through a > collection of backbone networks, often by means of network address > translators or other gateways. The other is that the IP protocol > usually runs atop some lower layer (what I call "intranet", what > others inexplicably call "layer 2") networks, including various > extended LAN, circuit switch, and virtual circuit networks. > > To my way of thinking, whether you mean this in an infrastructure > sense, and administrative sense, or a routing protocol sense, the > Internet is very much a network of networks. > >> Is the confusion between the limited scope of 802.11 and 802.16 and the >> planet-scale scope of IP addressing really prevalent among the >> community? >> >> Maybe this explains why so many seem to confuse the hardware and >> cabling >> with networking. KInd of like confusing the Intel instruction set >> with >> the Win32 API, or confusing the workings of the marketplace with the >> resolution of social issues. >> >> Fred Baker wrote: >> >>> >>> On Nov 9, 2008, at 4:31 AM, David P. Reed wrote: >>> >>>> why not multiple competing "routing" layers? >>> >>> >>> We have those, in spades. Consider 802.11, 802.1, 802.16, ATM and >>> its predecessors, etc. >>> >> > From Jon.Crowcroft at cl.cam.ac.uk Mon Nov 10 15:36:51 2008 From: Jon.Crowcroft at cl.cam.ac.uk (Jon Crowcroft) Date: Mon, 10 Nov 2008 23:36:51 +0000 Subject: [e2e] a means to an end In-Reply-To: <4918A1B4.8010205@telemuse.net> References: <20081106205204.CCE5D28E155@aland.bbn.com> <49135FAA.6080603@reed.com> <2F96E808-6A16-46A0-B836-819C220EE701@nomadiclab.com> <4916D804.8070508@reed.com> <940A6613-E050-4F8A-AA62-12A4B7ACEB0C@cisco.com> <4917346B.3080902@reed.com> <459576D8-21EF-4757-9E89-894B67E8C48D@cisco.com> <4918A1B4.8010205@telemuse.net> Message-ID: mpls on ethernet is fine if you do cells in frames but remember, mpls is not a good solutuon for mobility, or multicast nor was atm we tried - it failed. In missive <4918A1B4.8010205 at telemuse.net>, Lynne Jolitz typed: >>I assume by Fred's "MPLS on Ethernet" mention that the reason underlying >>their unusual approach is that they see no point (except more overhead) >>in the additional layers below an MPLS routing layer, so the end-points >>are the only things that matter (while ignoring of course, diagnostics, >>blockage identification and so forth). >> >>But let's take this further. An old suggestion proposed at an IETF in >>the early 1980's was similarly to disconnect the appearance of the >>routing layer and visibility of the network itself and tunnel everything >>on top of the network, so you'd have a layer 3 network encapsulated on >>top of a layer-3 network not visible except within the routing cloud. >>This was to hide the actual infrastructure so it couldn't be attacked. >>One could even encapsulate with TCP instead of IP such that you could >>allocate bandwidth portions and routes in an independent way - more like >>an OC IS-to-IS routing scheme. The view was the only people who cared >>about routing were the ones who could see how it was working, so why be >>open to DDOS attacks on the routers themselves, and also so as to >>promote quality. This was before BGP. >> >>So now we've got a Chinese proposal on MPLS-on-Ethernet. The advantage >>of their approach is that at layer 2 you can do it with mindless >>switches and spanning tree algorithms. This means very efficient, very >>low power, very dumb routers. Can this be produced? Yes, in massive >>quantities. Would people buy this? Very likely if cheap enough. >> >>How would massive deployment impact the Internet? That's one I'm >>wondering about. Lynne Jolitz. >> >>Fred Baker wrote: >> >>> >>> On Nov 9, 2008, at 11:05 AM, David P. Reed wrote: >>> >>>> I'm completely confused by the suggestions from Fred and Noel that >>>> 802.11 802.1, MPLS are somehow competing with the current IP routing >>>> system. None of those are end-to-end solutions, ... >>> >>> >>> Depends on your viewpoint. There are those that think of them as end >>> to end solutions in some stated domain. In Beijing during the last >>> week of October I visited a school that literally was proposing MPLS- >>> on-Ethernet as an end-to-end solution. >>> >>> The reason I mentioned them is this. You noted that the Internet was >>> designed as a network of networks, and IP was the ring to bind them. >>> True enough. We have two variations on that in the present Internet. >>> One is that we literally have separate networks connected through a >>> collection of backbone networks, often by means of network address >>> translators or other gateways. The other is that the IP protocol >>> usually runs atop some lower layer (what I call "intranet", what >>> others inexplicably call "layer 2") networks, including various >>> extended LAN, circuit switch, and virtual circuit networks. >>> >>> To my way of thinking, whether you mean this in an infrastructure >>> sense, and administrative sense, or a routing protocol sense, the >>> Internet is very much a network of networks. >>> >>>> Is the confusion between the limited scope of 802.11 and 802.16 and the >>>> planet-scale scope of IP addressing really prevalent among the >>>> community? >>>> >>>> Maybe this explains why so many seem to confuse the hardware and >>>> cabling >>>> with networking. KInd of like confusing the Intel instruction set >>>> with >>>> the Win32 API, or confusing the workings of the marketplace with the >>>> resolution of social issues. >>>> >>>> Fred Baker wrote: >>>> >>>>> >>>>> On Nov 9, 2008, at 4:31 AM, David P. Reed wrote: >>>>> >>>>>> why not multiple competing "routing" layers? >>>>> >>>>> >>>>> We have those, in spades. Consider 802.11, 802.1, 802.16, ATM and >>>>> its predecessors, etc. >>>>> >>>> >>> >> cheers jon From dpreed at reed.com Mon Nov 10 16:07:02 2008 From: dpreed at reed.com (David P. Reed) Date: Mon, 10 Nov 2008 19:07:02 -0500 Subject: [e2e] a means to an end In-Reply-To: <18712.33516.635568.347349@sbrim-mbp.local> References: <20081106205204.CCE5D28E155@aland.bbn.com> <49135FAA.6080603@reed.com> <2F96E808-6A16-46A0-B836-819C220EE701@nomadiclab.com> <4916D804.8070508@reed.com> <18712.33516.635568.347349@sbrim-mbp.local> Message-ID: <4918CCA6.4000108@reed.com> Two quick responses: 1. In a planet scale network, with jurisdictions that claim the right to do things like a) block specific correspondents from talking to each other with packets that pass through their subnets, b) spy on traffic passing through their domain to gain market advantage or intelligence, c) use packets passing through their domain to track and target (for assassination) various individuals by their address info, d) insert packets to spoof endpoints into thinking their correspondent is breaking a connection or whatever, ... then one might want to have alternatives to the "standard" routing chose by the gods of the Internet. (I hope the metaphors are seen as a general issue, the problem today is *very* real, and not the same when viewed from different perspectives at the endpoints). Do you believe in one world government? If so, I might believe that the equilibrium state for you would be a single "optimum". If not, why do you think that all people would agree to a single set of paths for their most valuable communications? The fantasy can be maintained only if you believe networks are economic or mathematical abstractions that fit postulates created by the Computer Science Gods at the NSF review panels who decide what is valid to think about and design. Or some other pretender to omniscience - pick the one you want to bow down to. (the same clean mathematical theorist's fantasy of convergence to stable equilibrium has dominated economics for 50 years. Look where that got us...) 2. My point about UUCP was that it coexisted side-by-side with the Internet, delivering mail and carrying files without using TCP, IP or anything else, but it had a routing layer. Later it just became vestigial, an app on top of the Internet, but in its early days, when the Internet was far from a foregone conclusion, Unix machines made point-to-point connections that routed traffic over whatever circuits it could have access to (including direct dialup links). But then I am probably a lot older than you are. Scott Brim wrote: > Excerpts from David P. Reed at 07:31:00 -0500 on Sun 9 Nov 2008: > >> Riffing on Pekka's opening - why not multiple competing "routing" >> layers? >> > > Yes, you can run multiple ships-in-the-night "networks" over a single > underlying "layer network", but how do the endpoints know what they > can even try to reach? One way of doing that is to have a common > internetworking layer -- call it the Internet. Another is to have the > endpoints know how to search according to the protocols they can speak > and networks they are connected to (but only those). This means smart > endpoints and difficult customer support. I predict that if you ran > this experiment, everyone would converge to a single "network" after > all. > > >> In the old days, when the Internet was about tying together >> different pre-existing networks into a coherent whole, it *was* one of >> many. (at least one other routing mechanism existed - uucp -- and it >> used some of the same pre-existing networks). >> > > UUCP had totally different syntax and the protocols to use were (are) > implicit in the addressing. > > > > From pekka.nikander at nomadiclab.com Mon Nov 10 22:54:25 2008 From: pekka.nikander at nomadiclab.com (Pekka Nikander) Date: Tue, 11 Nov 2008 08:54:25 +0200 Subject: [e2e] a means to an end In-Reply-To: <20081110170904.41E096BE580@mercury.lcs.mit.edu> References: <20081110170904.41E096BE580@mercury.lcs.mit.edu> Message-ID: <1E0C6F27-1948-41C5-BE93-8A013E9CE8AF@nomadiclab.com> On 9 Sun, 9 Nov 2008 09:25:38 +0200, Pekka Nikander wrote: >> Path-specific locators On 10 Nov 2008, at 19:09, Noel Chiappa wrote: > Let me make sure I understand what you mean by this term. To me, it > implies 'a source route composed of names of only local scope' - > whether the 'names' refer to outbound-interface/next-hop pairs, or > local flow names, or whatever, I don't have any specific concept. That is one particular way of implementing path-specific locators. More generally, I may have been better referring to "location-specific locators", or "sender-specific locators", but both might have been even more confusing, IMHO. The general idea is to construct locators that are only useful along a specific path, at a specific location or region, or for a specific sender or sender group. Of course, the most obvious way is to use crypto and some kind of access control, as has been done in the myriad of path authorisation papers, such as [1,2,3,4], to name but a few. But that is boring by now; the most interesting problems seem to related to deployment incentives and the markets effects resulting from deploying such technologies. (If someone is interested in co-operation, I have a student working in that area.) More interesting is to consider the fundamentals of what you can do in a forwarding box. You get a packet. There is some information in the packet, some in your forwarding table, and then you know the incoming link. The goal is to decide which output links to use, but only if the packet is "meant" to be sent along those links. (You may want to relax some of the requirements and allow some false positives, provided that they are either random enough or controlled enough.) One specific interesting approach is to name the links uni- directionally (more or less as you suggest), and then to compress the names into a Bloom filter or other compact fixed-sized representation, tagging the packets with the compact representation. The representation effectively works as a path-specific locator. (There are a number of interesting details, such as loop prevention, fast failure recovery, some security issues, etc, but I would digress.) But you can go much further. Of course, you can check that the packet came from a right incoming link, but that is again boring (and has a number of obvious complications that make it a little bit brittle as such). More interestingly, you can accumulate the path so far to the packet (e.g., as a Bloom filter), and use that information as a part of the forwarding decision. In general, there is a wealth of potential information that you could use, pretty efficiently, for the forwarding decisions. Using destination addresses or source routing are by no means the only ways of constructing forwarding fabrics. I believe that the middle ground where you combine some source-routing-like techniques, some hop-by-hop- like forwarding, and are also ready to carefully add some dynamic forwarding state to the network, maybe hide undiscovered troves. But there are also dragons there. > Even if it's not flows, but rather e.g. a translation which turns > that scope-local name into a global locator, the path-specific > locator is really just a security layer which obscures what global > locator that scope-local locator translates to. It can't be much > shorter/simpler than a global locator because that single scope- > local locator has to be able to specify the full range of > destinations that can be specified in a global locator. You may well be right that path-specific locators cannot be shorter or simpler that global locators. However, I don't think that they are just a security layer. My fundamental question is whether it is possible to construct a forwarding fabric that has now global locators and where no single entity needs to have the full graph, or even a too large fraction of the whole graph. (Why such a design would lead to a favourable market structure is another interesting issue where I have only gut feelings to guide...) I believe the answer is yes, you can do that, and that you can do that in a way that is roughly as efficient as IP forwarding. Indeed, our current straw-man design has much smaller forwarding tables than IP or even MPLS has, the mechanics of forwarding decisions are trivial, and we seem to have solved most of the thorny issues related to traditional source routing. But I'm afraid that there may be a dragon or two lurking in the dark corners, ready to burn our straws completely. > Or am I missing something? Well, in this context (e2e-interest), I guess most of the people suffer from IP myopism. As I tried to indicate above, IMHO it is by no means a necessity to have IP-address like global locators. Indeed, I believe that a forwarding fabric without such locators would have potentially a much larger social utility that the current one we have. Unfortunately, the utility of such a fabric alone, without the proper rendezvous and topology management systems, would be zero... Of course, the original IP had forwarding, topology, and rendezvous all nicely packed together, avoiding many of the potential deployment hurdles related to a multi-component system. --Pekka [1] Anderson et al. Preventing Internet Denial-of-Service with Capabilities. (2008) [2] Handley et al. Steps Towards a DoS-resistant Internet Architecture. Future directions in network architecture (2004) pp. 49?56 [3] Keromytis et al. SOS: secure overlay services. CCR (2002) vol. 32 (4) pp. 61-72 [4] Parno et al. Portcullis: Protecting Connection Setup from Denial-of-Capability Attacks. SIGCOMM (2007) From swb at employees.org Mon Nov 10 11:33:13 2008 From: swb at employees.org (Scott Brim) Date: Mon, 10 Nov 2008 14:33:13 -0500 Subject: [e2e] a means to an end In-Reply-To: <63B29FC7-B661-46AF-A0C3-3587B26BD864@cisco.com> References: <491190DE.7010706@sics.se> <1225995088.3733.231.camel@pc105-c703.uibk.ac.at> <49134E2F.8010704@reed.com> <04EC169B-5D71-427D-989F-E41FE30BEB9E@cisco.com> <66011996-5C5B-4AF1-839D-1075A0D33CD1@surrey.ac.uk> <63B29FC7-B661-46AF-A0C3-3587B26BD864@cisco.com> Message-ID: <20081110193313.GA25444@cisco.com> Excerpts from Fred Baker at 16:00:23 -0800 on Fri 7 Nov 2008: > > can anyone explain how that clear explanation of the endpoint ID > > matches with the definition of endpoint ID given in RFC5050, section > > 4.4? > > About the same way the description maps to the endpoint ID found in > RFC 5201-5201 and 5338. Like HIP's Endpoint ID, DTN's Bundle ID lacks > any way for a system, given knowledge of what instance of an > application it wants to talk with or what data object it wants to > find, to determine the locator of that object. Given the locator we > can establish whether we are talking to the right system, but not the > other way around. This is tripping over some conflation of identifiers. There can be many identifiers in play at one time, for the same or different functions. An ID that you would use to find a process to talk to does not have to be the same as the ID you would use for session control or session authentication. A HIP HI can be used for both (but doesn't have to be), but afaik a Bundle ID cannot. From swb at employees.org Mon Nov 10 11:31:49 2008 From: swb at employees.org (Scott Brim) Date: Mon, 10 Nov 2008 14:31:49 -0500 Subject: [e2e] a means to an end In-Reply-To: References: <20081106205204.CCE5D28E155@aland.bbn.com> <49135FAA.6080603@reed.com> <2F96E808-6A16-46A0-B836-819C220EE701@nomadiclab.com> Message-ID: <20081110193149.GA25337@cisco.com> Excerpts from Jon Crowcroft at 14:10:42 +0000 on Sun 9 Nov 2008: > locators can refer to fixed points of network attachment > (like phone landline numbers refer to sockets on the wall) > to objects (in content) where they look a bit like anycast > to groups of recipients (where they are group locs and need > recursively (and distributedly) remapping to actual locs > and to current locations of a mobile > node where we need/can have a more efficient way to > remap when the node moves for the other node(s) > currently in session with this one, > than we do for new nodes trying to find it... I would think it's always easier for nodes with a session up to find each other than for nodes starting cold. I know who I'm talking to, and I can notify them when I move, with a rendezvous mechanism for backup if we lose track of each other. Authentication is certainly easier if there is pre-existing state, no? > (actually, i am not sure if this is true for both ends moving > unless you buy into router state which has to scale > order number of current mobile sessions, > which doesn't look tracatable to me, or to > hierarchical location thingies, which might be ok > but ....) There we are again :-). Let me know when you get here in December. > anyhow the API for host and router is still the same - the point is > what sort of service do you want? (there's some nice work by > colleagues here in this context ages back - viz > http://www.cl.cam.ac.uk/~pes20/nomadicpict.html Will read. swb From dpreed at reed.com Tue Nov 11 06:52:51 2008 From: dpreed at reed.com (David P. Reed) Date: Tue, 11 Nov 2008 09:52:51 -0500 Subject: [e2e] a means to an end In-Reply-To: <1E0C6F27-1948-41C5-BE93-8A013E9CE8AF@nomadiclab.com> References: <20081110170904.41E096BE580@mercury.lcs.mit.edu> <1E0C6F27-1948-41C5-BE93-8A013E9CE8AF@nomadiclab.com> Message-ID: <49199C43.6080001@reed.com> Re the likelihood of unification of routing to a single common routing system shared by all end users... I offer the following news (unverified) reported by "jamie rishaw" > on Farber's IP list today. > You may recall the event just a few months ago that alleged a > Pakistani "hijack" of the BGP route-advertisements leading to > Youtube.. the same is under way as I type this. > > :: Short Story / "Breaking News" :: > > Hundreds to thousands of networks connected to the internet are > being threatened and "black holed" by what appears to be a failure of > trust in the policies implementing the Internet routing protocol BGP. Maybe it *is* time for a few competing services that use the same address space to compete. The non-hostility based analogy is USPS and the other national postal services, FedEx, UPS and DHL. All undertake at retail (not only backbone) to deliver packages with the same address formats, and none has converged with another (though sometimes one provides part of the route for another - this is true of FedEx and the USPS, as one example, which cover for each other in different areas). This has many con's as well as many pro's, of course. If your monopoly local Internet access provider won't let you select the routing service but instead forces you to accept the one with which it has a "deal", you could find yourself held hostage by the monopolist. All I can say to that is that it is not a problem with multiple routing services, it is a problem with monopolists and the governments who enable them to sustain their monopolies. From randy at psg.com Tue Nov 11 08:26:36 2008 From: randy at psg.com (Randy Bush) Date: Tue, 11 Nov 2008 10:26:36 -0600 Subject: [e2e] a means to an end In-Reply-To: <49199C43.6080001@reed.com> References: <20081110170904.41E096BE580@mercury.lcs.mit.edu> <1E0C6F27-1948-41C5-BE93-8A013E9CE8AF@nomadiclab.com> <49199C43.6080001@reed.com> Message-ID: <4919B23C.4060100@psg.com> actually, today's fat finger disaster is limited to a portion of the internet specifically by protective routing policy. the long term solution in process is formally validated routing. and the sky is not falling. randy From touch at ISI.EDU Wed Nov 12 11:21:03 2008 From: touch at ISI.EDU (Joe Touch) Date: Wed, 12 Nov 2008 11:21:03 -0800 Subject: [e2e] a means to an end In-Reply-To: <20081106213057.479E728E155@aland.bbn.com> References: <20081106213057.479E728E155@aland.bbn.com> Message-ID: <491B2C9F.9020606@isi.edu> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Craig Partridge wrote: ... > So let me try restating what I took from chatting with Van (with the > understanding that this is my take, not necessarily Van's). > > * Information is place free. This doesn't make sense. Information exists at a place - perhaps, as in the case of "majority of X", in more than one place, or in an area, but regardless it always exists somewhere. > * Actually accessing that information, in the worst case, requires > a rendezvous point (if it is popular data, it doesn't -- someone > near you will have a copy -- but information that is of only occasional > interest requires more effort). Accessing the information requires getting to the information; rendezvous points are just places the information has either agreed to move to, or places that agree to forward the request to the information. They're otherwise uninteresting in this discussion - ultimately, the information exits somewhere, and a request needs to meet up with it to be useful. Joe -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkkbLJ8ACgkQE5f5cImnZrsByQCeM5Ut2EeKm8xXEI+Kfz5Cgpti KOsAoI/GkAXI1Bgm2n+0x3mPXISyuMnm =iAla -----END PGP SIGNATURE----- From touch at ISI.EDU Wed Nov 12 11:23:32 2008 From: touch at ISI.EDU (Joe Touch) Date: Wed, 12 Nov 2008 11:23:32 -0800 Subject: [e2e] a means to an end In-Reply-To: <491401CF.1080304@sics.se> References: <491190DE.7010706@sics.se> <1225995088.3733.231.camel@pc105-c703.uibk.ac.at> <491401CF.1080304@sics.se> Message-ID: <491B2D34.3060605@isi.edu> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 FWIW, I don't see DHTs as addressing this issue. Directories do address the issue, and DHTs are one way to implement directories. They have some advantages (dispersing load), and some disadvantages (destroying structure in the information of the directory that could be used to anticipate or cache information), but they seem irrelevant per se to the overall issue. Joe Ali Ghodsi wrote: > Michael Welzl wrote: >> Location dependance, which even the "id" part should >> have (at least in the form of some concept of "nearness"). >> >> > Sorry, not sure I understand. Do you mean that DHTs have strong > connectivity requirements (e.g. nodes should be able to communicate with > their direct successors on the ring etc)? In that case, there are DHTs > which relax these requirements, e.g. small-world DHTs (Oscar, Symphony) > and those that don't have a ring or lattice (P-grid, FuzzyNets, Kelips). > Or do you mean that DHTs do not route efficiently because they ignore > latencies (what's called stretch, or proximity awareness, or locality by > the DHT folks). Or perhaps neither :). > > Regards, > Ali -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkkbLTQACgkQE5f5cImnZrtp3ACeIdK+PTxnvwk43adDOJv0cALq +s4AnjCrnUuqZDiP5Xr5PZtpVmh4OSRZ =fdF8 -----END PGP SIGNATURE----- From dpreed at reed.com Wed Nov 12 12:33:11 2008 From: dpreed at reed.com (David P. Reed) Date: Wed, 12 Nov 2008 15:33:11 -0500 Subject: [e2e] a means to an end In-Reply-To: <491B2C9F.9020606@isi.edu> References: <20081106213057.479E728E155@aland.bbn.com> <491B2C9F.9020606@isi.edu> Message-ID: <491B3D87.6050104@reed.com> It is fundamentally wrong to say that *information* exists at a place. Storage exists at a place. A bit of information is fundamentally distinct in category and reality from a bit of storage. Only computer scientists are so confused and deluded as to think that information and storage container are the same thing. Joe Touch wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > > > Craig Partridge wrote: > ... > >> So let me try restating what I took from chatting with Van (with the >> understanding that this is my take, not necessarily Van's). >> >> * Information is place free. >> > > This doesn't make sense. Information exists at a place - perhaps, as in > the case of "majority of X", in more than one place, or in an area, but > regardless it always exists somewhere. > > >> * Actually accessing that information, in the worst case, requires >> a rendezvous point (if it is popular data, it doesn't -- someone >> near you will have a copy -- but information that is of only occasional >> interest requires more effort). >> > > Accessing the information requires getting to the information; > rendezvous points are just places the information has either agreed to > move to, or places that agree to forward the request to the information. > They're otherwise uninteresting in this discussion - ultimately, the > information exits somewhere, and a request needs to meet up with it to > be useful. > > Joe > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.9 (MingW32) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org > > iEYEARECAAYFAkkbLJ8ACgkQE5f5cImnZrsByQCeM5Ut2EeKm8xXEI+Kfz5Cgpti > KOsAoI/GkAXI1Bgm2n+0x3mPXISyuMnm > =iAla > -----END PGP SIGNATURE----- > > From L.Wood at surrey.ac.uk Wed Nov 12 13:27:14 2008 From: L.Wood at surrey.ac.uk (Lloyd Wood) Date: Wed, 12 Nov 2008 21:27:14 +0000 Subject: [e2e] a means to an end In-Reply-To: <491B2C9F.9020606@isi.edu> References: <20081106213057.479E728E155@aland.bbn.com> <491B2C9F.9020606@isi.edu> Message-ID: <67CDB729-A759-4B48-AC29-8763876F8D6F@surrey.ac.uk> >> * Information is place free. Physics disagrees. DTN work: http://info.ee.surrey.ac.uk/Personal/L.Wood/saratoga/ From touch at ISI.EDU Wed Nov 12 13:27:33 2008 From: touch at ISI.EDU (Joe Touch) Date: Wed, 12 Nov 2008 13:27:33 -0800 Subject: [e2e] a means to an end In-Reply-To: <491B3D87.6050104@reed.com> References: <20081106213057.479E728E155@aland.bbn.com> <491B2C9F.9020606@isi.edu> <491B3D87.6050104@reed.com> Message-ID: <491B4A45.6060409@isi.edu> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 David P. Reed wrote: > It is fundamentally wrong to say that *information* exists at a place. > Storage exists at a place. > > A bit of information is fundamentally distinct in category and reality > from a bit of storage. Only computer scientists are so confused and > deluded as to think that information and storage container are the same > thing. Information is the uncertainty of an outcome of an event. That event is typically the interpretation of one or more symbols, those symbols are tangeable, and have a location. This computer scientist didn't say anything about storage. Joe -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkkbSkUACgkQE5f5cImnZrsenQCfSMwP13avrJry3ToRIeG63pOS DUEAoMCURVAdNxFtHW0VUXr4tsjRGuWV =beSN -----END PGP SIGNATURE----- From dpreed at reed.com Wed Nov 12 13:44:35 2008 From: dpreed at reed.com (David P. Reed) Date: Wed, 12 Nov 2008 16:44:35 -0500 Subject: [e2e] [SPAM] Re: a means to an end In-Reply-To: <491B4A45.6060409@isi.edu> References: <20081106213057.479E728E155@aland.bbn.com> <491B2C9F.9020606@isi.edu> <491B3D87.6050104@reed.com> <491B4A45.6060409@isi.edu> Message-ID: <491B4E43.4010307@reed.com> No, information is not the uncertainty in the outcome of an event (not least because that puts information as a "future" thing). It's related to the number of possible states of a system as a whole. Decomposing the state of a system into the state of parts (needed to assign a location to some piece of information) must be done carefully, because the states of parts may have invariant relationships, which reduce the number of states, and create the illusion of information where there is none. E.g.: the states of atoms that make up a one-bit storage cell typically are highly correlated. Thus the cell contains a single bit of information, whereas the individual atoms contain no bits (or more properly, they contain contingent information, of the sort that the "majority" talks about). Similarly, the "temperature" of a mole of gas expresses a bounded number of bits of information, and that information is neither an event nor a place, and is not independent of the "pressure" and "volume" of the gas, each of which is dependent on the other. The general term "information" has no place. Joe Touch wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > > > David P. Reed wrote: > >> It is fundamentally wrong to say that *information* exists at a place. >> Storage exists at a place. >> >> A bit of information is fundamentally distinct in category and reality >> from a bit of storage. Only computer scientists are so confused and >> deluded as to think that information and storage container are the same >> thing. >> > > Information is the uncertainty of an outcome of an event. That event is > typically the interpretation of one or more symbols, those symbols are > tangeable, and have a location. > > This computer scientist didn't say anything about storage. > > Joe > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.9 (MingW32) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org > > iEYEARECAAYFAkkbSkUACgkQE5f5cImnZrsenQCfSMwP13avrJry3ToRIeG63pOS > DUEAoMCURVAdNxFtHW0VUXr4tsjRGuWV > =beSN > -----END PGP SIGNATURE----- > > From touch at ISI.EDU Wed Nov 12 13:50:38 2008 From: touch at ISI.EDU (Joe Touch) Date: Wed, 12 Nov 2008 13:50:38 -0800 Subject: [e2e] [SPAM] Re: a means to an end In-Reply-To: <491B4E43.4010307@reed.com> References: <20081106213057.479E728E155@aland.bbn.com> <491B2C9F.9020606@isi.edu> <491B3D87.6050104@reed.com> <491B4A45.6060409@isi.edu> <491B4E43.4010307@reed.com> Message-ID: <491B4FAE.5020800@isi.edu> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 David P. Reed wrote: > No, information is not the uncertainty in the outcome of an event (not > least because that puts information as a "future" thing). It's related > to the number of possible states of a system as a whole. Decomposing > the state of a system into the state of parts (needed to assign a > location to some piece of information) must be done carefully, because > the states of parts may have invariant relationships, which reduce the > number of states, and create the illusion of information where there is > none. There are numerous definitions of the term. Let's use your proposed one: "related to the number of possible states of a system" Both the system and the states are represented physically, and thus have a location. > E.g.: the states of atoms that make up a one-bit storage cell typically > are highly correlated. Thus the cell contains a single bit of > information, whereas the individual atoms contain no bits (or more > properly, they contain contingent information, of the sort that the > "majority" talks about). > > Similarly, the "temperature" of a mole of gas expresses a bounded number > of bits of information, and that information is neither an event nor a > place, and is not independent of the "pressure" and "volume" of the gas, > each of which is dependent on the other. The gas has a location. I never said that a bit correlated to an atom or a *point* in space. Joe -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkkbT64ACgkQE5f5cImnZrsxtQCg84qjORSbqXXH8n6ZrsJtUoZu QZkAoOCh0Yt2Y9+gKbuW1nk+vzR2xPeq =KkiS -----END PGP SIGNATURE----- From dpreed at reed.com Wed Nov 12 16:10:29 2008 From: dpreed at reed.com (David P. Reed) Date: Wed, 12 Nov 2008 19:10:29 -0500 Subject: [e2e] a means to an end In-Reply-To: <67CDB729-A759-4B48-AC29-8763876F8D6F@surrey.ac.uk> References: <20081106213057.479E728E155@aland.bbn.com> <491B2C9F.9020606@isi.edu> <67CDB729-A759-4B48-AC29-8763876F8D6F@surrey.ac.uk> Message-ID: <491B7075.10901@reed.com> Sorry, you are wrong. Physics has no notion of place associated with information, both in classical physics and in quantum physics. Lloyd Wood wrote: >>> * Information is place free. > > Physics disagrees. > > DTN work: http://info.ee.surrey.ac.uk/Personal/L.Wood/saratoga/ > > > > > > > > From dpreed at reed.com Wed Nov 12 16:13:12 2008 From: dpreed at reed.com (David P. Reed) Date: Wed, 12 Nov 2008 19:13:12 -0500 Subject: [e2e] [SPAM] Re: a means to an end In-Reply-To: <491B4FAE.5020800@isi.edu> References: <20081106213057.479E728E155@aland.bbn.com> <491B2C9F.9020606@isi.edu> <491B3D87.6050104@reed.com> <491B4A45.6060409@isi.edu> <491B4E43.4010307@reed.com> <491B4FAE.5020800@isi.edu> Message-ID: <491B7118.50205@reed.com> You should be careful. If the mole of gas is embedded in a larger system, its information is not separable from the larger system's information because there is no isolation. Joe Touch wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > > > David P. Reed wrote: > >> No, information is not the uncertainty in the outcome of an event (not >> least because that puts information as a "future" thing). It's related >> to the number of possible states of a system as a whole. Decomposing >> the state of a system into the state of parts (needed to assign a >> location to some piece of information) must be done carefully, because >> the states of parts may have invariant relationships, which reduce the >> number of states, and create the illusion of information where there is >> none. >> > > There are numerous definitions of the term. Let's use your proposed one: > > "related to the number of possible states of a system" > > Both the system and the states are represented physically, and thus have > a location. > > >> E.g.: the states of atoms that make up a one-bit storage cell typically >> are highly correlated. Thus the cell contains a single bit of >> information, whereas the individual atoms contain no bits (or more >> properly, they contain contingent information, of the sort that the >> "majority" talks about). >> >> Similarly, the "temperature" of a mole of gas expresses a bounded number >> of bits of information, and that information is neither an event nor a >> place, and is not independent of the "pressure" and "volume" of the gas, >> each of which is dependent on the other. >> > > The gas has a location. I never said that a bit correlated to an atom or > a *point* in space. > > Joe > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.9 (MingW32) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org > > iEYEARECAAYFAkkbT64ACgkQE5f5cImnZrsxtQCg84qjORSbqXXH8n6ZrsJtUoZu > QZkAoOCh0Yt2Y9+gKbuW1nk+vzR2xPeq > =KkiS > -----END PGP SIGNATURE----- > > From touch at ISI.EDU Wed Nov 12 16:34:13 2008 From: touch at ISI.EDU (touch@ISI.EDU) Date: Wed, 12 Nov 2008 16:34:13 -0800 Subject: [e2e] [SPAM] Re: a means to an end In-Reply-To: <491B7118.50205@reed.com> References: <20081106213057.479E728E155@aland.bbn.com> <491B2C9F.9020606@isi.edu> <491B3D87.6050104@reed.com> <491B4A45.6060409@isi.edu> <491B4E43.4010307@reed.com> <491B4FAE.5020800@isi.edu> <491B7118.50205@reed.com> Message-ID: <1226536453.491b76056506a@webmail.isi.edu> Quoting "David P. Reed" : > You should be careful. If the mole of gas is embedded in a larger > system, its information is not separable from the larger system's > information because there is no isolation. If you're talking about its temperature, that is defined as its average kinetic energy, which has no relationship to the environment in which it exists. However, intrinsic values like temperature are not in of themselves "information"; e.g., the mass of an electron is not "information" per se, but it can be information to an entity to whom that value is not known. Information is defined over a set of possible states, as the difference between the number of actual states vs. the number of possible. In this case, it's the number of possible temperatures vs. the actual temperature. Again, none of this is related to the system in which the gas resides. That's not to say that there are not measurements that are related to the environment of the system, but this isn't one of them. Or are you running towards the Liouville Theorem, regarding aggregate information and its conservation in a closed system? Why, however, is this relevant? Joer > > Joe Touch wrote: > > -----BEGIN PGP SIGNED MESSAGE----- > > Hash: SHA1 > > > > > > > > David P. Reed wrote: > > > >> No, information is not the uncertainty in the outcome of an event (not > >> least because that puts information as a "future" thing). It's related > >> to the number of possible states of a system as a whole. Decomposing > >> the state of a system into the state of parts (needed to assign a > >> location to some piece of information) must be done carefully, because > >> the states of parts may have invariant relationships, which reduce the > >> number of states, and create the illusion of information where there is > >> none. > >> > > > > There are numerous definitions of the term. Let's use your proposed one: > > > > "related to the number of possible states of a system" > > > > Both the system and the states are represented physically, and thus have > > a location. > > > > > >> E.g.: the states of atoms that make up a one-bit storage cell typically > >> are highly correlated. Thus the cell contains a single bit of > >> information, whereas the individual atoms contain no bits (or more > >> properly, they contain contingent information, of the sort that the > >> "majority" talks about). > >> > >> Similarly, the "temperature" of a mole of gas expresses a bounded number > >> of bits of information, and that information is neither an event nor a > >> place, and is not independent of the "pressure" and "volume" of the gas, > >> each of which is dependent on the other. > >> > > > > The gas has a location. I never said that a bit correlated to an atom or > > a *point* in space. > > > > Joe > > -----BEGIN PGP SIGNATURE----- > > Version: GnuPG v1.4.9 (MingW32) > > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org > > > > iEYEARECAAYFAkkbT64ACgkQE5f5cImnZrsxtQCg84qjORSbqXXH8n6ZrsJtUoZu > > QZkAoOCh0Yt2Y9+gKbuW1nk+vzR2xPeq > > =KkiS > > -----END PGP SIGNATURE----- > > > > > From bmanning at vacation.karoshi.com Wed Nov 12 16:57:45 2008 From: bmanning at vacation.karoshi.com (bmanning@vacation.karoshi.com) Date: Thu, 13 Nov 2008 00:57:45 +0000 Subject: [e2e] a means to an end In-Reply-To: <491B4A45.6060409@isi.edu> References: <20081106213057.479E728E155@aland.bbn.com> <491B2C9F.9020606@isi.edu> <491B3D87.6050104@reed.com> <491B4A45.6060409@isi.edu> Message-ID: <20081113005745.GA4162@vacation.karoshi.com.> isn't location defined by a set of coordinates? and the coordinates are information? and they have to be found somewhere (e.g. stored)? and where they are stored is in itself a location w/ its own set of coordinates? or is this harder than it looks? --bill From dpreed at reed.com Wed Nov 12 18:16:11 2008 From: dpreed at reed.com (David P. Reed) Date: Wed, 12 Nov 2008 21:16:11 -0500 Subject: [e2e] [SPAM] Re: a means to an end In-Reply-To: <1226536453.491b76056506a@webmail.isi.edu> References: <20081106213057.479E728E155@aland.bbn.com> <491B2C9F.9020606@isi.edu> <491B3D87.6050104@reed.com> <491B4A45.6060409@isi.edu> <491B4E43.4010307@reed.com> <491B4FAE.5020800@isi.edu> <491B7118.50205@reed.com> <1226536453.491b76056506a@webmail.isi.edu> Message-ID: <491B8DEB.2060108@reed.com> To your last question: this is relevant, because you asserted without qualification or caveat that ALL information (except for odd things like my majority example) *has a location*. That's just plain false. Some systems, by convention, are organized so that they store a piece of information in a single unique storage "bin" (a physical device, a time slot, an addressable magnetic domain, ...). But that is a convention of a designed organization or descriptive frame of reference, and hardly a "law of nature". In fact it is just a design choice. Even in trivial case of an RSA encrypted 32-bit word of data, stored in a 32-bit container, the "first bit" of data is not localized, but is smeared into the whole word. So saying that "all information is located" and therefore deriving that access of information requires "first finding its unique location" is JUST a choice of design. But it is not the only choice. You can talk about information that inherently has NO location, and doing so has benefits to the designer and the design space he works in. (as is the case with Van's work). In networking, it is worth thinking about this, because by abusing yourself of the notion of information being in a location, you can make better choices. Just look at "network coding" as one example - Dina Katabi and Crowcroft showed that in practice de-localizing information has many advantages. Or as a different example, consider the work of Trachtenberg, Minsky and Zippel on distributed set reconciliation. Information flows between containers in a manner that is diffused in space and time. Or look at a hologram or FFT - again information loses locality, with many benefits. Information may have a *name* - that is one of the points of my (now old) Ph.D. thesis, and in practice it is often the case that any information of interest must have an "effective computation" that can make a decision based on it. B ut even the "effectively computable" notion of information is NOT complete. There can be information that is not "effectively computable" - that's the whole point of Goedel's work. Note: We can also discuss physics if you like - I spend a lot of time thinking about the physics of information and information theory, so I'm happy to discuss it with you. Thoughh it perhaps is less relevant to e2e. But in fact, it is not the case that in modern physics information needs must have a location, either. You can try to approximate "localized information" in physics, but then you end up with laws that cannot describe all possible experiments. (In fact, the recent resolution of some of the paradoxes of black-hole information has been possible because Hawking admitted that information need not have a location - in essence, though the math is subtler than that). One of the problems with location in physics is that in most late 20th- early 21st century physical theories, there is no such thing as a "location" that is independent of the stuff that is in it. The boundaries of space themselves don't exist independently of their content. Of course when you take physics classes in school, the *problem sets* simplify reality to cases where information is localized. Surely you realize that problem sets are designed to teach, and not to represent the entirety of reality? touch at ISI.EDU wrote: > Quoting "David P. Reed" : > > >> You should be careful. If the mole of gas is embedded in a larger >> system, its information is not separable from the larger system's >> information because there is no isolation. >> > > If you're talking about its temperature, that is defined as its average kinetic > energy, which has no relationship to the environment in which it exists. > > However, intrinsic values like temperature are not in of themselves > "information"; e.g., the mass of an electron is not "information" per se, but > it can be information to an entity to whom that value is not known. Information > is defined over a set of possible states, as the difference between the number > of actual states vs. the number of possible. In this case, it's the number of > possible temperatures vs. the actual temperature. Again, none of this is > related to the system in which the gas resides. > > That's not to say that there are not measurements that are related to the > environment of the system, but this isn't one of them. Or are you running > towards the Liouville Theorem, regarding aggregate information and its > conservation in a closed system? > > Why, however, is this relevant? > > Joer > > >> Joe Touch wrote: >> >>> -----BEGIN PGP SIGNED MESSAGE----- >>> Hash: SHA1 >>> >>> >>> >>> David P. Reed wrote: >>> >>> >>>> No, information is not the uncertainty in the outcome of an event (not >>>> least because that puts information as a "future" thing). It's related >>>> to the number of possible states of a system as a whole. Decomposing >>>> the state of a system into the state of parts (needed to assign a >>>> location to some piece of information) must be done carefully, because >>>> the states of parts may have invariant relationships, which reduce the >>>> number of states, and create the illusion of information where there is >>>> none. >>>> >>>> >>> There are numerous definitions of the term. Let's use your proposed one: >>> >>> "related to the number of possible states of a system" >>> >>> Both the system and the states are represented physically, and thus have >>> a location. >>> >>> >>> >>>> E.g.: the states of atoms that make up a one-bit storage cell typically >>>> are highly correlated. Thus the cell contains a single bit of >>>> information, whereas the individual atoms contain no bits (or more >>>> properly, they contain contingent information, of the sort that the >>>> "majority" talks about). >>>> >>>> Similarly, the "temperature" of a mole of gas expresses a bounded number >>>> of bits of information, and that information is neither an event nor a >>>> place, and is not independent of the "pressure" and "volume" of the gas, >>>> each of which is dependent on the other. >>>> >>>> >>> The gas has a location. I never said that a bit correlated to an atom or >>> a *point* in space. >>> >>> Joe >>> -----BEGIN PGP SIGNATURE----- >>> Version: GnuPG v1.4.9 (MingW32) >>> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org >>> >>> iEYEARECAAYFAkkbT64ACgkQE5f5cImnZrsxtQCg84qjORSbqXXH8n6ZrsJtUoZu >>> QZkAoOCh0Yt2Y9+gKbuW1nk+vzR2xPeq >>> =KkiS >>> -----END PGP SIGNATURE----- >>> >>> >>> > > > > From L.Wood at surrey.ac.uk Wed Nov 12 22:50:38 2008 From: L.Wood at surrey.ac.uk (Lloyd Wood) Date: Thu, 13 Nov 2008 06:50:38 +0000 Subject: [e2e] a means to an end In-Reply-To: <491B7075.10901@reed.com> References: <20081106213057.479E728E155@aland.bbn.com> <491B2C9F.9020606@isi.edu> <67CDB729-A759-4B48-AC29-8763876F8D6F@surrey.ac.uk> <491B7075.10901@reed.com> Message-ID: <9AC2DB33-4479-475E-8C27-8FC60C2B8E08@surrey.ac.uk> On 13 Nov 2008, at 00:10, David P. Reed wrote: > Sorry, you are wrong. Physics has no notion of place associated > with information, both in classical physics and in quantum physics. See Bekenstein or the holographic principle. > Lloyd Wood wrote: >>>> * Information is place free. >> >> Physics disagrees. DTN work: http://info.ee.surrey.ac.uk/Personal/L.Wood/saratoga/ From v13 at v13.gr Thu Nov 13 02:08:19 2008 From: v13 at v13.gr (Stefanos Harhalakis) Date: Thu, 13 Nov 2008 12:08:19 +0200 Subject: [e2e] a means to an end In-Reply-To: <491B7075.10901@reed.com> References: <20081106213057.479E728E155@aland.bbn.com> <67CDB729-A759-4B48-AC29-8763876F8D6F@surrey.ac.uk> <491B7075.10901@reed.com> Message-ID: <200811131208.19787.v13@v13.gr> On Thursday 13 November 2008, David P. Reed wrote: > Sorry, you are wrong. Physics has no notion of place associated with > information, both in classical physics and in quantum physics. In fact, information is not a physics "quantity" but a human interpretation of something (an action/state, a combination of other things, etc...). The only thing that physics says is that any kind of information cannot travel faster than the speed of light (which can be further expressed as: we cannot move the information carrier faster than c). But this isn't actually relevant to the issue... When 'information' is distributed (practically always - bits in RAM are distributed) then there is no single-location for it but at the end there actually is an area that stores the whole information (for example: earth, all Internet nodes, all nodes of Amazon's EC2, my hard disk, my 1st RAM module, etc). Perhaps the question should be rephrased somehow like: Is information located in a single node (or accessed via a single one)? From jnc at mercury.lcs.mit.edu Thu Nov 13 04:32:41 2008 From: jnc at mercury.lcs.mit.edu (Noel Chiappa) Date: Thu, 13 Nov 2008 07:32:41 -0500 (EST) Subject: [e2e] [SPAM] Re: a means to an end Message-ID: <20081113123241.167F16BE56B@mercury.lcs.mit.edu> > From: touch at ISI.EDU > Why, however, is this relevant? My thoughts exactly... Noel From touch at ISI.EDU Thu Nov 13 07:30:55 2008 From: touch at ISI.EDU (Joe Touch) Date: Thu, 13 Nov 2008 07:30:55 -0800 Subject: [e2e] [SPAM] Re: a means to an end In-Reply-To: <491B8DEB.2060108@reed.com> References: <20081106213057.479E728E155@aland.bbn.com> <491B2C9F.9020606@isi.edu> <491B3D87.6050104@reed.com> <491B4A45.6060409@isi.edu> <491B4E43.4010307@reed.com> <491B4FAE.5020800@isi.edu> <491B7118.50205@reed.com> <1226536453.491b76056506a@webmail.isi.edu> <491B8DEB.2060108@reed.com> Message-ID: <491C482F.4050007@isi.edu> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 David P. Reed wrote: > To your last question: this is relevant, because you asserted without > qualification or caveat that ALL information (except for odd things like > my majority example) *has a location*. I didn't opt out of majorities having a location either. All information is based on a physical property (actual state vs. possible states), and physical entities have a location (which need not be a point). That information exists only in the abstract until it is determined (e.g., calculated, measured, etc.); that measurement itself has a location. ... > Even in trivial > case of an RSA encrypted 32-bit word of data, stored in a 32-bit > container, the "first bit" of data is not localized, but is smeared into > the whole word. I've already noted that location need not be a point. Note that an RSA encrypted word of data isn't smeared across all packets from all parties. >...You can talk > about information that inherently has NO location, and doing so has > benefits to the designer and the design space he works in. (as is the > case with Van's work). See below... > In networking, it is worth thinking about this, because by abusing > yourself of the notion of information being in a location, you can make > better choices. Just look at "network coding" as one example - Dina > Katabi and Crowcroft showed that in practice de-localizing information > has many advantages. Or as a different example, consider the work of > Trachtenberg, Minsky and Zippel on distributed set reconciliation. > Information flows between containers in a manner that is diffused in > space and time. Or look at a hologram or FFT - again information > loses locality, with many benefits. The state of a system that information represents has a location - again, not necessarily a point. However, that information isn't useful until it determined, which requires localization. Consider network coding - the information is spread among a finite set of packets, each with a specific location at a specific time -- it is NOT spread across all packets, or abstractly "across the network". Accessing the information means taking the distributed state and localizing the interpretation of that state - e.g., the packets of network coding aren't useful until they're recombined. ... > But in fact, it is not the case that in modern physics information needs > must have a location, either. You can try to approximate "localized > information" in physics, but then you end up with laws that cannot > describe all possible experiments. (In fact, the recent resolution of > some of the paradoxes of black-hole information has been possible > because Hawking admitted that information need not have a location - in > essence, though the math is subtler than that). Hawking's discussion focused on the loss of informatiuon, which - as I noted - requires diving into the Liouville Theorem, and considering the scope of the system in which conservation is determined - but we're not talking about conservation here. Joe -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkkcSC8ACgkQE5f5cImnZrugDACgvOK4E2hO/s0fuhcbHQzo8ytt TQ4An1qokn6qSP3ZrIvFM0/y0g5AC8bu =N2Z2 -----END PGP SIGNATURE----- From touch at ISI.EDU Thu Nov 13 07:41:36 2008 From: touch at ISI.EDU (Joe Touch) Date: Thu, 13 Nov 2008 07:41:36 -0800 Subject: [e2e] a means to an end In-Reply-To: <20081113005745.GA4162@vacation.karoshi.com.> References: <20081106213057.479E728E155@aland.bbn.com> <491B2C9F.9020606@isi.edu> <491B3D87.6050104@reed.com> <491B4A45.6060409@isi.edu> <20081113005745.GA4162@vacation.karoshi.com.> Message-ID: <491C4AB0.6030702@isi.edu> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, Bill, bmanning at vacation.karoshi.com wrote: > > isn't location defined by a set of coordinates? Sure. Potentially by a region expressed as a set of coordinates. > and the coordinates are information? Sure. > and they have to be found somewhere (e.g. stored)? Not necessarily the way you might expect. The information of where my stapler is located on my desk is stored only in the stapler itself; it isn't represented in other storage. However, in a computer system, it's generally fair to assume that information is either: - stored in memory somewhere (where communication paths act like memory) - available at some external input/measurement device (e.g., a camera, keyboard, temperature probe) Information can be built on information, e.g., the average temperature of the US is the aggregate of the values of the individual probes, etc. too. That second information doesn't exist in the absence of the lower-level point measures, however. Information can be spread out, but not infinitely (that would allow infinite entropy, and since info is negative entropy, that would imply zero info). > and where they are stored is in itself a location w/ its own set of coordinates? Sure - this is the resource discovery bootstrap problem. It's why every DNS client: a) knows the location of its DNS server's IP address in memory b) knows the DNS server IP address e.g., either its server, or the set of root IP addresses It also knows where it stores MAC addresses, it knows the MAC of directly connected routers, or it knows the MAC to use to broadcast a query to find them. It's all just bootstrapping at that point... Joe -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkkcSrAACgkQE5f5cImnZrsekgCdEap4rJbTYkx0tgK8Xw/x+bP+ ArUAn1M5v62B0qgavJACu2hxhKr1FNGX =3v9m -----END PGP SIGNATURE----- From bmanning at vacation.karoshi.com Thu Nov 13 08:44:44 2008 From: bmanning at vacation.karoshi.com (bmanning@vacation.karoshi.com) Date: Thu, 13 Nov 2008 16:44:44 +0000 Subject: [e2e] POV In-Reply-To: <491C4AB0.6030702@isi.edu> References: <20081106213057.479E728E155@aland.bbn.com> <491B2C9F.9020606@isi.edu> <491B3D87.6050104@reed.com> <491B4A45.6060409@isi.edu> <20081113005745.GA4162@vacation.karoshi.com.> <491C4AB0.6030702@isi.edu> Message-ID: <20081113164444.GA9013@vacation.karoshi.com.> On Thu, Nov 13, 2008 at 07:41:36AM -0800, Joe Touch wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Hi, Bill, > > bmanning at vacation.karoshi.com wrote: > > > > isn't location defined by a set of coordinates? > > Sure. Potentially by a region expressed as a set of coordinates. good... then we have a starting point for divergence. :) > > and they have to be found somewhere (e.g. stored)? > > Not necessarily the way you might expect. The information of where my > stapler is located on my desk is stored only in the stapler itself; it > isn't represented in other storage. actually, i posit that it is. on the presumption of a shared coordinate space, the stapler is internally consistant (assuming no acceleration or vector for the stapler for the nonce) and you are correct in that the coordinate set is unique to the stapler. however, the coordinate space is only useful to third parties. i.e. where you (and we will leave as an exercise to the reader what & where define "you") are -in relation- to the stapler coordinates. "... move the hand 210degress down, 18cm, at 3.5cm/sec until hand reaches 33 59 8.376 N 118 26 48.156 W 200m at zero acceleration..." then take what ever you find there. (should be the stapler, right?) > Joe From touch at ISI.EDU Thu Nov 13 08:48:39 2008 From: touch at ISI.EDU (Joe Touch) Date: Thu, 13 Nov 2008 08:48:39 -0800 Subject: [e2e] POV In-Reply-To: <20081113164444.GA9013@vacation.karoshi.com.> References: <20081106213057.479E728E155@aland.bbn.com> <491B2C9F.9020606@isi.edu> <491B3D87.6050104@reed.com> <491B4A45.6060409@isi.edu> <20081113005745.GA4162@vacation.karoshi.com.> <491C4AB0.6030702@isi.edu> <20081113164444.GA9013@vacation.karoshi.com.> Message-ID: <491C5A67.6080902@isi.edu> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 bmanning at vacation.karoshi.com wrote: > On Thu, Nov 13, 2008 at 07:41:36AM -0800, Joe Touch wrote: >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA1 >> >> Hi, Bill, >> >> bmanning at vacation.karoshi.com wrote: >>> isn't location defined by a set of coordinates? >> Sure. Potentially by a region expressed as a set of coordinates. > > good... then we have a starting point for divergence. :) > >>> and they have to be found somewhere (e.g. stored)? >> Not necessarily the way you might expect. The information of where my >> stapler is located on my desk is stored only in the stapler itself; it >> isn't represented in other storage. > > > actually, i posit that it is. on the presumption of a shared > coordinate space, the stapler is internally consistant (assuming > no acceleration or vector for the stapler for the nonce) and you > are correct in that the coordinate set is unique to the stapler. > > however, the coordinate space is only useful to third parties. i.e. > where you (and we will leave as an exercise to the reader what & where > define "you") are -in relation- to the stapler coordinates. > > "... move the hand 210degress down, 18cm, at 3.5cm/sec until hand reaches > 33 59 8.376 N 118 26 48.156 W 200m at zero acceleration..." then take > what ever you find there. (should be the stapler, right?) You're presuming that you know the location of a device near the stapler. How did you know that unless that location was stored somewhere you knew? Once you know that, then yes, you can _measure_ the location of the stapler using the sensing device at that location. At that point, the location of the stapler would be relative to the location of the other device as an offset - again, using information that you either had to have pre-shared or had to obtain somehow (length of the arm, angle, etc.) Joe -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkkcWmcACgkQE5f5cImnZrvTtACdE73LZ7PtZjkjnHykPoEzeuU2 bfYAoP3S6LCfwolFP+PDBLlQykJSQoMu =QbjV -----END PGP SIGNATURE----- From dpreed at reed.com Thu Nov 13 09:06:47 2008 From: dpreed at reed.com (David P. Reed) Date: Thu, 13 Nov 2008 12:06:47 -0500 Subject: [e2e] a means to an end In-Reply-To: <9AC2DB33-4479-475E-8C27-8FC60C2B8E08@surrey.ac.uk> References: <20081106213057.479E728E155@aland.bbn.com> <491B2C9F.9020606@isi.edu> <67CDB729-A759-4B48-AC29-8763876F8D6F@surrey.ac.uk> <491B7075.10901@reed.com> <9AC2DB33-4479-475E-8C27-8FC60C2B8E08@surrey.ac.uk> Message-ID: <491C5EA7.9010408@reed.com> Bekenstein's work is well known. If anything it says information has no place. The more complex (fractal) the boundary, the more information in the space it contains. That's a real interesting idea, but it suggests that the information is not actually in the space at all. It suggests that information *creates* the space that contains it, just as in GR, matter/energy creates space. You are discussing quantum gravity, which conspicuously does not have a notion of place, so it is pretty hard to say that information is *in* a place. Lloyd Wood wrote: > On 13 Nov 2008, at 00:10, David P. Reed wrote: > >> Sorry, you are wrong. Physics has no notion of place associated with >> information, both in classical physics and in quantum physics. > > See Bekenstein or the holographic principle. > >> Lloyd Wood wrote: >>>>> * Information is place free. >>> >>> Physics disagrees. > > DTN work: http://info.ee.surrey.ac.uk/Personal/L.Wood/saratoga/ > > > > > > > > From dpreed at reed.com Thu Nov 13 09:41:12 2008 From: dpreed at reed.com (David P. Reed) Date: Thu, 13 Nov 2008 12:41:12 -0500 Subject: [e2e] [SPAM] Re: a means to an end In-Reply-To: <491C482F.4050007@isi.edu> References: <20081106213057.479E728E155@aland.bbn.com> <491B2C9F.9020606@isi.edu> <491B3D87.6050104@reed.com> <491B4A45.6060409@isi.edu> <491B4E43.4010307@reed.com> <491B4FAE.5020800@isi.edu> <491B7118.50205@reed.com> <1226536453.491b76056506a@webmail.isi.edu> <491B8DEB.2060108@reed.com> <491C482F.4050007@isi.edu> Message-ID: <491C66B8.2050902@reed.com> Computation (measurement) doesn't necessarily have a single location either. Your brain happily functions without a tiny homunculus that makes the final decision. A computer can make a decision without representing the output of the decision in one place. A flock of geese maneuvers (and hence makes decisions) without there ever being a "command goose". And a slime mold "decides" to turn from slime to a stalk to a vermiform without a single decision maker. Who said a "measurement" was unitary? I think you need to debug your thinking apparatus. Joe Touch wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > > > David P. Reed wrote: > >> To your last question: this is relevant, because you asserted without >> qualification or caveat that ALL information (except for odd things like >> my majority example) *has a location*. >> > > I didn't opt out of majorities having a location either. > > All information is based on a physical property (actual state vs. > possible states), and physical entities have a location (which need not > be a point). That information exists only in the abstract until it is > determined (e.g., calculated, measured, etc.); that measurement itself > has a location. > > ... > >> Even in trivial >> case of an RSA encrypted 32-bit word of data, stored in a 32-bit >> container, the "first bit" of data is not localized, but is smeared into >> the whole word. >> > > I've already noted that location need not be a point. Note that an RSA > encrypted word of data isn't smeared across all packets from all parties. > > >> ...You can talk >> about information that inherently has NO location, and doing so has >> benefits to the designer and the design space he works in. (as is the >> case with Van's work). >> > > See below... > > >> In networking, it is worth thinking about this, because by abusing >> yourself of the notion of information being in a location, you can make >> better choices. Just look at "network coding" as one example - Dina >> Katabi and Crowcroft showed that in practice de-localizing information >> has many advantages. Or as a different example, consider the work of >> Trachtenberg, Minsky and Zippel on distributed set reconciliation. >> Information flows between containers in a manner that is diffused in >> space and time. Or look at a hologram or FFT - again information >> loses locality, with many benefits. >> > > The state of a system that information represents has a location - > again, not necessarily a point. However, that information isn't useful > until it determined, which requires localization. Consider network > coding - the information is spread among a finite set of packets, each > with a specific location at a specific time -- it is NOT spread across > all packets, or abstractly "across the network". Accessing the > information means taking the distributed state and localizing the > interpretation of that state - e.g., the packets of network coding > aren't useful until they're recombined. > > ... > >> But in fact, it is not the case that in modern physics information needs >> must have a location, either. You can try to approximate "localized >> information" in physics, but then you end up with laws that cannot >> describe all possible experiments. (In fact, the recent resolution of >> some of the paradoxes of black-hole information has been possible >> because Hawking admitted that information need not have a location - in >> essence, though the math is subtler than that). >> > > Hawking's discussion focused on the loss of informatiuon, which - as I > noted - requires diving into the Liouville Theorem, and considering the > scope of the system in which conservation is determined - but we're not > talking about conservation here. > > Joe > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.9 (MingW32) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org > > iEYEARECAAYFAkkcSC8ACgkQE5f5cImnZrugDACgvOK4E2hO/s0fuhcbHQzo8ytt > TQ4An1qokn6qSP3ZrIvFM0/y0g5AC8bu > =N2Z2 > -----END PGP SIGNATURE----- > > From touch at ISI.EDU Thu Nov 13 10:40:43 2008 From: touch at ISI.EDU (Joe Touch) Date: Thu, 13 Nov 2008 10:40:43 -0800 Subject: [e2e] [SPAM] Re: a means to an end In-Reply-To: <491C66B8.2050902@reed.com> References: <20081106213057.479E728E155@aland.bbn.com> <491B2C9F.9020606@isi.edu> <491B3D87.6050104@reed.com> <491B4A45.6060409@isi.edu> <491B4E43.4010307@reed.com> <491B4FAE.5020800@isi.edu> <491B7118.50205@reed.com> <1226536453.491b76056506a@webmail.isi.edu> <491B8DEB.2060108@reed.com> <491C482F.4050007@isi.edu> <491C66B8.2050902@reed.com> Message-ID: <491C74AB.8000207@isi.edu> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 David P. Reed wrote: > Computation (measurement) doesn't necessarily have a single location > either. You've made that argument repeatedly, as I have made the point that having a location doesn't mean having a single point location. > Your brain happily functions without a tiny homunculus that > makes the final decision. A computer can make a decision without > representing the output of the decision in one place. As can a tree fall in the forest without anyone to hear it. However, decisions that are hidden from the rest of the world are irrelevant; at some point, the brain components need to coordinate a decision (as do computer components), and the output is represented in a set of locations. There's no such thing as computation - or information - that has *no* location. > A flock of geese > maneuvers (and hence makes decisions) without there ever being a > "command goose". That's not quite correct; the lead goose is the one that others track in general (by feeling air currents); follower geese can initiate actions from their place backward, and the rest of the group will react when visual or auditory cues indicate (e.g., gunshots, trees falling in the forest, etc.). > And a slime mold "decides" to turn from slime to a > stalk to a vermiform without a single decision maker. Emergent behavior is fine, but it's still coordinated either by chemical, mechanical, etc. means. However, as others have noted, we've strayed far afield of the original issue - that information has a location (even if not a *point*), as I asserted originally. If you have a counterexample - i.e., information that has *no* location, please provide it. Examples for which the location is spread out, but for which a location exist, do not disprove my assertion. Joe -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkkcdKsACgkQE5f5cImnZrsYngCfSvSN9rp/yVOpptb/L7c9G4rR j1EAn3w5JffxsoQ6hDO3lFmQzWpBK1EV =2lEH -----END PGP SIGNATURE----- From dpreed at reed.com Thu Nov 13 11:29:24 2008 From: dpreed at reed.com (David P. Reed) Date: Thu, 13 Nov 2008 14:29:24 -0500 Subject: [e2e] [SPAM] Re: a means to an end In-Reply-To: <491C74AB.8000207@isi.edu> References: <20081106213057.479E728E155@aland.bbn.com> <491B2C9F.9020606@isi.edu> <491B3D87.6050104@reed.com> <491B4A45.6060409@isi.edu> <491B4E43.4010307@reed.com> <491B4FAE.5020800@isi.edu> <491B7118.50205@reed.com> <1226536453.491b76056506a@webmail.isi.edu> <491B8DEB.2060108@reed.com> <491C482F.4050007@isi.edu> <491C66B8.2050902@reed.com> <491C74AB.8000207@isi.edu> Message-ID: <491C8014.4020307@reed.com> Maybe you have a different definition of "location" than I do, Joe. I have provided many answers, and each one you fail to respond to, instead changing your definition of location. Joe Touch wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > > > David P. Reed wrote: > >> Computation (measurement) doesn't necessarily have a single location >> either. >> > > You've made that argument repeatedly, as I have made the point that > having a location doesn't mean having a single point location. > > >> Your brain happily functions without a tiny homunculus that >> makes the final decision. A computer can make a decision without >> representing the output of the decision in one place. >> > > As can a tree fall in the forest without anyone to hear it. However, > decisions that are hidden from the rest of the world are irrelevant; at > some point, the brain components need to coordinate a decision (as do > computer components), and the output is represented in a set of locations. > > There's no such thing as computation - or information - that has *no* > location. > > >> A flock of geese >> maneuvers (and hence makes decisions) without there ever being a >> "command goose". >> > > That's not quite correct; the lead goose is the one that others track in > general (by feeling air currents); follower geese can initiate actions > from their place backward, and the rest of the group will react when > visual or auditory cues indicate (e.g., gunshots, trees falling in the > forest, etc.). > > >> And a slime mold "decides" to turn from slime to a >> stalk to a vermiform without a single decision maker. >> > > Emergent behavior is fine, but it's still coordinated either by > chemical, mechanical, etc. means. > > However, as others have noted, we've strayed far afield of the original > issue - that information has a location (even if not a *point*), as I > asserted originally. If you have a counterexample - i.e., information > that has *no* location, please provide it. Examples for which the > location is spread out, but for which a location exist, do not disprove > my assertion. > > Joe > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.9 (MingW32) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org > > iEYEARECAAYFAkkcdKsACgkQE5f5cImnZrsYngCfSvSN9rp/yVOpptb/L7c9G4rR > j1EAn3w5JffxsoQ6hDO3lFmQzWpBK1EV > =2lEH > -----END PGP SIGNATURE----- > > From Jon.Crowcroft at cl.cam.ac.uk Fri Nov 14 00:16:29 2008 From: Jon.Crowcroft at cl.cam.ac.uk (Jon Crowcroft) Date: Fri, 14 Nov 2008 08:16:29 +0000 Subject: [e2e] [SPAM] Re: a means to an end In-Reply-To: <20081113123241.167F16BE56B@mercury.lcs.mit.edu> References: <20081113123241.167F16BE56B@mercury.lcs.mit.edu> Message-ID: to quote someone who isn't a physicist, we are all living in a material world, and in that world we are limited to light cones within which there are _causality_ principles (as well as entropic) - hence relative locations have a bearing on infrmation flow between objects the ordering of messages on this mail list (and the rate of increase of entropy in the universe) Is bounded at least in part by latency latency shows up quite a lot in distributed algorithms (routing, location/mapping, memory/cpu speed/power, BFT schemes, etc etc:) the internet to date lives in a virtual world and data oriented mnetowkring likes to fool itself it is in some steady state in an "infosphere" where we can plonk down copies of data willynilly, and therefore see no latency. reality bites - a lot more data goes in from, and even more usefully, out to the real world. the points it goes in and out (ingress/egresss_ better be near people/devices/sensors/actuators that want the data since some data ingresses from the real world (my typing) and out (you reading on the screen >-here<-) we better route messages on paths that don't spend too long going arond the 13 dimensional infosphere too many times before they get in/out oh, and the folks "out there" (i.e. the 4billion cellphones) have a better handle on how to do this than the folks "in here (the mere 1billion internet backwoodspeople).... time to get more real...which is why i started this thread. In missive <20081113123241.167F16BE56B at mercury.lcs.mit.edu>, Noel Chiappa typed : >> > From: touch at ISI.EDU >> >> > Why, however, is this relevant? >> >>My thoughts exactly... >> >> Noel cheers jon From Jon.Crowcroft at cl.cam.ac.uk Fri Nov 14 04:34:14 2008 From: Jon.Crowcroft at cl.cam.ac.uk (Jon Crowcroft) Date: Fri, 14 Nov 2008 12:34:14 +0000 Subject: [e2e] [SPAM] Re: a means to an end In-Reply-To: References: <20081113123241.167F16BE56B@mercury.lcs.mit.edu> Message-ID: indeed if we think of this as an Onion with RL as an outer layer, and SL as an inner layer (and as many people have been doing, mining interactions between RL and SL via footprints in the sand in the SL) then one consideration about how one creates mappings from id (in RL) to location (in RL/SL interface) might be privacy, so the onion immediately brings to mind Tor... of course, if all you are interested is SL, then let me onion route you this: http://www.theonion.com/content/video/youtube_contest_challenges_users In missive , Jon Crowcroft typed: >>to quote someone who isn't a physicist, >>we are all living in a material world, >>and in that world we are limited to light cones >>within which there are _causality_ principles >>(as well as entropic) - hence relative locations have >>a bearing on infrmation flow between objects >> >>the ordering of messages on this mail list >>(and the rate of increase of entropy in the universe) >>Is bounded at least in part by latency >>latency shows up quite a lot in distributed algorithms (routing, >>location/mapping, memory/cpu speed/power, BFT schemes, etc etc:) >> >>the internet to date lives in a virtual world and data oriented >>mnetowkring likes to fool itself it is in some steady state in an >>"infosphere" where we can plonk down copies of data willynilly, and >>therefore see no latency. >> >>reality bites - a lot more data goes in from, and even more usefully, >>out to the real world. the points it goes in and out (ingress/egresss_ >>better be near people/devices/sensors/actuators that want the data >> >>since some data ingresses from the real world (my typing) and out (you >>reading on the screen >-here<-) >>we better route messages on paths that don't spend too long going >>arond the 13 dimensional infosphere too many times before they get >>in/out >> >>oh, and the folks "out there" (i.e. the 4billion cellphones) have a >>better handle on how to do this than the folks "in here (the mere >>1billion internet backwoodspeople).... >> >>time to get more real...which is why i started this thread. >> >>In missive <20081113123241.167F16BE56B at mercury.lcs.mit.edu>, Noel Chiappa typed >>: >> >> >> > From: touch at ISI.EDU >> >> >> >> > Why, however, is this relevant? >> >> >> >>My thoughts exactly... >> >> >> >> Noel >> >> cheers >> >> jon >> cheers jon