On Mon, Mar 30, 2009 at 5:09 PM, Scott Brim <[email protected]> wrote: > Excerpts from William Herrin on Mon, Mar 30, 2009 04:47:07PM -0400: >> An [identifier] is a "handle" that our software, at whatever layer of >> the stack, uses to associate the components of a particular >> communication with the communication as a whole. Any handle which >> provides this association function is an [identifier]. > > I'm having to fill in some blanks but that sounds like 'session > control', which is one use, but doesn't cover e.g. most uses of domain > names.
Hi Scott, I'm trying to use "communication" here in a broad, non-technical sense. Reading my newspaper is a "communication." Its identified by the title "Washington Post" and located near the checkout counter at my grocery store. My communication with the Washington Post persists over the many years that I've read it. The individual editions and stories are components of that communication which are associated together under the identifier, "Washington Post." "Communication" isn't exactly the right word. The general idea is that there is some Something involved in moving information and the components of that Something are uniquely and persistently associated with the Something via the Identifier. It's like you have a database with many pairs of tables. In the objects table for each pair you have a unique primary key. In the components table you have a foreign key back to the primary key of objects table. That primary key is the identifier for the object and its components. Each pair of tables corresponds to a different kind of identifier with a different scope and lifetime. >> b. The [identifier] persists unchanged for the duration of its useful >> function. >> >> If it fails to persist, communication will be disrupted, terminated or >> induced to malfunction. > > If I have a session I'm controlling and I periodically change keys and > identifiers, the identifier has changed (or been replaced), but the > change has been managed. I'm not sure how to fit that into your > statement. Show me an example of an identifier change that doesn't have ambiguous corner cases. Shim6 is an interesting guide here. Consider this ambiguous corner case: I am 1.2.3.4 Request TCP connection A to 6.7.8.9 6.7.8.9 changes identity to 9.8.7.6 Request TCP connection B to 6.7.8.9 Should connection B be established to 6.7.8.9 or to 9.8.7.6? Guess wrong for that particular application and you get a malfunction. >> Where we run into problems is: >> >> 1. Some "thing" serving as part of the [identifier] also serves >> another function in which uniqueness adds undesirable complexity. > Can you give an example? Sure. Example #1: We tag the packet with a AS# and an IP address. The AS# persistently identifies the network in which the the IP address resides. All IP addresses at that AS are assigned the same AS#; it isn't unique. Each AS announces it's AS# to the world. At each router, we perform a hash table lookup to find the next hop for the destination AS#. Example #2: We tag the packet with only an IP address. Each AS announces the address prefixes it serves to the world. At each router we perform either a TCAM lookup or a radix-tree lookup to associate the IP address to the prefix to which it belongs and then to the next hop via which that prefix is found. Which was more complex and more expensive? The hash table lookup? Or the radix tree/TCAM lookup? Regards, Bill Herrin -- William D. Herrin ................ [email protected] [email protected] 3005 Crane Dr. ...................... Web: <http://bill.herrin.us/> Falls Church, VA 22042-3004 _______________________________________________ rrg mailing list [email protected] http://www.irtf.org/mailman/listinfo/rrg
