<html><head><meta http-equiv="Content-Type" content="text/html charset=euc-kr"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;">I think Tai-Lin＊s example was just fine to talk about discovery. /blah/blah/value, how do you discover all the ※value§s? Discovery shouldn＊t care if its email messages or temperature readings or world cup photos.<div><br></div><div>I described one set of problems using the exclusion approach, and that an NDN paper on device discovery described a similar problem, though they did not go into the details of splitting interests, etc. That all was simple enough to see from the example.</div><div><br></div><div>Another question is how does one do the discovery with exact match names, which is also conflating things. You could do a different discovery with continuation names too, just not the exclude method.</div><div><br></div><div>As I alluded to, one needs a way to talk with a specific cache about its ※table of contents§ for a prefix so one can get a consistent set of results without all the round-trips of exclusions. Actually downloading the ※headers§ of the messages would be the same bytes, more or less. In a way, this is a little like name enumeration from a ccnx 0.x repo, but that protocol has its own set of problems and I＊m not suggesting to use that directly.</div><div><br></div><div>One approach is to encode a request in a name component and a participating cache can reply. It replies in such a way that one could continue talking with that cache to get its TOC. One would then issue another interest with a request for not-that-cache.</div><div><br></div><div>Another approach is to try to ask the authoritative source for the ※current§ manifest name, i.e. /mail/inbox/current/<nonce>, which could return the manifest or a link to the manifest. Then fetching the actual manifest from the link could come from caches because you how have a consistent set of names to ask for. If you cannot talk with an authoritative source, you could try again without the nonce and see if there＊s a cached copy of a recent version around.</div><div><br></div><div>Marc</div><div><br></div><div><br><div><div>On Sep 24, 2014, at 5:46 PM, Burke, Jeff <<a href="mailto:jburke@remap.ucla.edu">jburke@remap.ucla.edu</a>> wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div style="font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;"><br><br>On 9/24/14, 8:20 AM, "<a href="mailto:Ignacio.Solis@parc.com">Ignacio.Solis@parc.com</a>" <<a href="mailto:Ignacio.Solis@parc.com">Ignacio.Solis@parc.com</a>><br>wrote:<br><br><blockquote type="cite">On 9/24/14, 4:27 AM, "Tai-Lin Chu" <<a href="mailto:tailinchu@gmail.com">tailinchu@gmail.com</a>> wrote:<br><br><blockquote type="cite">For example, I see a pattern /mail/inbox/148. I, a human being, see a<br>pattern with static (/mail/inbox) and variable (148) components; with<br>proper naming convention, computers can also detect this pattern<br>easily. Now I want to look for all mails in my inbox. I can generate a<br>list of /mail/inbox/<number>. These are my guesses, and with selectors<br>I can further refine my guesses.<br></blockquote><br>I think this is a very bad example (or at least a very bad application<br>design). You have an app (a mail server / inbox) and you want it to list<br>your emails? An email list is an application data structure. I don＊t<br>think you should use the network structure to reflect this.<br></blockquote><br>I think Tai-Lin is trying to sketch a small example, not propose a<br>full-scale approach to email. (Maybe I am misunderstanding.)<br><br><br>Another way to look at it is that if the network architecture is providing<br>the equivalent of distributed storage to the application, perhaps the<br>application data structure could be adapted to match the affordances of<br>the network. Then it would not be so bad that the two structures were<br>aligned. <br><br><blockquote type="cite"><br>I＊ll give you an example, how do you delete emails from your inbox? If an<br>email was cached in the network it can never be deleted from your inbox?<br></blockquote><br>This is conflating two issues - what you are pointing out is that the data<br>structure of a linear list doesn't handle common email management<br>operations well. Again, I'm not sure if that's what he was getting at<br>here. But deletion is not the issue - the availability of a data object<br>on the network does not necessarily mean it's valid from the perspective<br>of the application.<br><br><blockquote type="cite">Or moved to another mailbox? Do you rely on the emails expiring?<br><br>This problem is true for most (any?) situations where you use network name<br>structure to directly reflect the application data structure.<br></blockquote><br>Not sure I understand how you make the leap from the example to the<br>general statement.<span class="Apple-converted-space"> </span><br><br>Jeff<br><br><br><br><blockquote type="cite"><br>Nacho<br><br><br><br><blockquote type="cite">On Tue, Sep 23, 2014 at 2:34 AM, <<a href="mailto:Marc.Mosko@parc.com">Marc.Mosko@parc.com</a>> wrote:<br><blockquote type="cite">Ok, yes I think those would all be good things.<br><br>One thing to keep in mind, especially with things like time series<br>sensor<br>data, is that people see a pattern and infer a way of doing it. That＊s<br>easy<br>for a human :) But in Discovery, one should assume that one does not<br>know<br>of patterns in the data beyond what the protocols used to publish the<br>data<br>explicitly require. That said, I think some of the things you listed<br>are<br>good places to start: sensor data, web content, climate data or genome<br>data.<br><br>We also need to state what the forwarding strategies are and what the<br>cache<br>behavior is.<br><br>I outlined some of the points that I think are important in that other<br>posting. While ※discover latest§ is useful, ※discover all§ is also<br>important, and that one gets complicated fast. So points like<br>separating<br>discovery from retrieval and working with large data sets have been<br>important in shaping our thinking. That all said, I＊d be happy<br>starting<br>from 0 and working through the Discovery service definition from<br>scratch<br>along with data set use cases.<br><br>Marc<br><br>On Sep 23, 2014, at 12:36 AM, Burke, Jeff <<a href="mailto:jburke@remap.ucla.edu">jburke@remap.ucla.edu</a>><br>wrote:<br><br>Hi Marc,<br><br>Thanks 〝 yes, I saw that as well. I was just trying to get one step<br>more<br>specific, which was to see if we could identify a few specific use<br>cases<br>around which to have the conversation. (e.g., time series sensor data<br>and<br>web content retrieval for "get latest"; climate data for huge data<br>sets;<br>local data in a vehicular network; etc.) What have you been looking at<br>that's driving considerations of discovery?<br><br>Thanks,<br>Jeff<br><br>From: <<a href="mailto:Marc.Mosko@parc.com">Marc.Mosko@parc.com</a>><br>Date: Mon, 22 Sep 2014 22:29:43 +0000<br>To: Jeff Burke <<a href="mailto:jburke@remap.ucla.edu">jburke@remap.ucla.edu</a>><br>Cc: <<a href="mailto:tailinchu@gmail.com">tailinchu@gmail.com</a>>, <<a href="mailto:ndn-interest@lists.cs.ucla.edu">ndn-interest@lists.cs.ucla.edu</a>><br>Subject: Re: [Ndn-interest] any comments on naming convention?<br><br>Jeff,<br><br>Take a look at my posting (that Felix fixed) in a new thread on<br>Discovery.<br><br><br><a href="http://www.lists.cs.ucla.edu/pipermail/ndn-interest/2014-September/00020">http://www.lists.cs.ucla.edu/pipermail/ndn-interest/2014-September/00020</a><br>0<br>.html<br><br>I think it would be very productive to talk about what Discovery should<br>do,<br>and not focus on the how. It is sometimes easy to get caught up in the<br>how,<br>which I think is a less important topic than the what at this stage.<br><br>Marc<br><br>On Sep 22, 2014, at 11:04 PM, Burke, Jeff <jburke@remap.ucla.edu><br>wrote:<br><br>Marc,<br><br>If you can't talk about your protocols, perhaps we can discuss this<br>based<br>on use cases. What are the use cases you are using to evaluate<br>discovery?<br><br>Jeff<br><br><br><br>On 9/21/14, 11:23 AM, "Marc.Mosko@parc.com" <Marc.Mosko@parc.com><br>wrote:<br><br>No matter what the expressiveness of the predicates if the forwarder<br>can<br>send interests different ways you don't have a consistent underlying<br>set<br>to talk about so you would always need non-range exclusions to discover<br>every version.<br><br>Range exclusions only work I believe if you get an authoritative<br>answer.<br>If different content pieces are scattered between different caches I<br>don't see how range exclusions would work to discover every version.<br><br>I'm sorry to be pointing out problems without offering solutions but<br>we're not ready to publish our discovery protocols.<br><br>Sent from my telephone<br><br>On Sep 21, 2014, at 8:50, "Tai-Lin Chu" <tailinchu@gmail.com> wrote:<br><br>I see. Can you briefly describe how ccnx discovery protocol solves the<br>all problems that you mentioned (not just exclude)? a doc will be<br>better.<br><br>My unserious conjecture( :) ) : exclude is equal to [not]. I will soon<br>expect [and] and [or], so boolean algebra is fully supported. Regular<br>language or context free language might become part of selector too.<br><br>On Sat, Sep 20, 2014 at 11:25 PM, <Marc.Mosko@parc.com> wrote:<br>That will get you one reading then you need to exclude it and ask<br>again.<br><br>Sent from my telephone<br><br>On Sep 21, 2014, at 8:22, "Tai-Lin Chu" <tailinchu@gmail.com> wrote:<br><br>Yes, my point was that if you cannot talk about a consistent set<br>with a particular cache, then you need to always use individual<br>excludes not range excludes if you want to discover all the versions<br>of an object.<br><br><br>I am very confused. For your example, if I want to get all today's<br>sensor data, I just do (Any..Last second of last day)(First second of<br>tomorrow..Any). That's 18 bytes.<br><br><br>[1]http://named-data.net/doc/ndn-tlv/interest.html#exclude<br><br>On Sat, Sep 20, 2014 at 10:55 PM, <Marc.Mosko@parc.com> wrote:<br><br>On Sep 21, 2014, at 1:47 AM, Tai-Lin Chu <tailinchu@gmail.com> wrote:<br><br>If you talk sometimes to A and sometimes to B, you very easily<br>could miss content objects you want to discovery unless you avoid<br>all range exclusions and only exclude explicit versions.<br><br><br>Could you explain why missing content object situation happens? also<br>range exclusion is just a shorter notation for many explicit<br>exclude;<br>converting from explicit excludes to ranged exclude is always<br>possible.<br><br><br>Yes, my point was that if you cannot talk about a consistent set<br>with a particular cache, then you need to always use individual<br>excludes not range excludes if you want to discover all the versions<br>of an object. For something like a sensor reading that is updated,<br>say, once per second you will have 86,400 of them per day. If each<br>exclusion is a timestamp (say 8 bytes), that＊s 691,200 bytes of<br>exclusions (plus encoding overhead) per day.<br><br>yes, maybe using a more deterministic version number than a<br>timestamp makes sense here, but its just an example of needing a lot<br>of exclusions.<br><br><br>You exclude through 100 then issue a new interest. This goes to<br>cache B<br><br><br>I feel this case is invalid because cache A will also get the<br>interest, and cache A will return v101 if it exists. Like you said,<br>if<br>this goes to cache B only, it means that cache A dies. How do you<br>know<br>that v101 even exist?<br><br><br>I guess this depends on what the forwarding strategy is. If the<br>forwarder will always send each interest to all replicas, then yes,<br>modulo packet loss, you would discover v101 on cache A. If the<br>forwarder is just doing ※best path§ and can round-robin between cache<br>A and cache B, then your application could miss v101.<br><br><br><br>c,d In general I agree that LPM performance is related to the number<br>of components. In my own thread-safe LMP implementation, I used only<br>one RWMutex for the whole tree. I don't know whether adding lock for<br>every node will be faster or not because of lock overhead.<br><br>However, we should compare (exact match + discovery protocol) vs<br>(ndn<br>lpm). Comparing performance of exact match to lpm is unfair.<br><br><br>Yes, we should compare them. And we need to publish the ccnx 1.0<br>specs for doing the exact match discovery. So, as I said, I＊m not<br>ready to claim its better yet because we have not done that.<br><br><br><br><br><br><br>On Sat, Sep 20, 2014 at 2:38 PM, <Marc.Mosko@parc.com> wrote:<br>I would point out that using LPM on content object to Interest<br>matching to do discovery has its own set of problems. Discovery<br>involves more than just ※latest version§ discovery too.<br><br>This is probably getting off-topic from the original post about<br>naming conventions.<br><br>a. If Interests can be forwarded multiple directions and two<br>different caches are responding, the exclusion set you build up<br>talking with cache A will be invalid for cache B. If you talk<br>sometimes to A and sometimes to B, you very easily could miss<br>content objects you want to discovery unless you avoid all range<br>exclusions and only exclude explicit versions. That will lead to<br>very large interest packets. In ccnx 1.0, we believe that an<br>explicit discovery protocol that allows conversations about<br>consistent sets is better.<br><br>b. Yes, if you just want the ※latest version§ discovery that<br>should be transitive between caches, but imagine this. You send<br>Interest #1 to cache A which returns version 100. You exclude<br>through 100 then issue a new interest. This goes to cache B who<br>only has version 99, so the interest times out or is NACK＊d. So<br>you think you have it! But, cache A already has version 101, you<br>just don＊t know. If you cannot have a conversation around<br>consistent sets, it seems like even doing latest version discovery<br>is difficult with selector based discovery. From what I saw in<br>ccnx 0.x, one ended up getting an Interest all the way to the<br>authoritative source because you can never believe an intermediate<br>cache that there＊s not something more recent.<br><br>I＊m sure you＊ve walked through cases (a) and (b) in ndn, I＊d be<br>interest in seeing your analysis. Case (a) is that a node can<br>correctly discover every version of a name prefix, and (b) is that<br>a node can correctly discover the latest version. We have not<br>formally compared (or yet published) our discovery protocols (we<br>have three, 2 for content, 1 for device) compared to selector based<br>discovery, so I cannot yet claim they are better, but they do not<br>have the non-determinism sketched above.<br><br>c. Using LPM, there is a non-deterministic number of lookups you<br>must do in the PIT to match a content object. If you have a name<br>tree or a threaded hash table, those don＊t all need to be hash<br>lookups, but you need to walk up the name tree for every prefix of<br>the content object name and evaluate the selector predicate.<br>Content Based Networking (CBN) had some some methods to create data<br>structures based on predicates, maybe those would be better. But<br>in any case, you will potentially need to retrieve many PIT entries<br>if there is Interest traffic for many prefixes of a root. Even on<br>an Intel system, you＊ll likely miss cache lines, so you＊ll have a<br>lot of NUMA access for each one. In CCNx 1.0, even a naive<br>implementation only requires at most 3 lookups (one by name, one by<br>name + keyid, one by name + content object hash), and one can do<br>other things to optimize lookup for an extra write.<br><br>d. In (c) above, if you have a threaded name tree or are just<br>walking parent pointers, I suspect you＊ll need locking of the<br>ancestors in a multi-threaded system (※threaded" here meaning LWP)<br>and that will be expensive. It would be interesting to see what a<br>cache consistent multi-threaded name tree looks like.<br><br>Marc<br><br><br>On Sep 20, 2014, at 8:15 PM, Tai-Lin Chu <tailinchu@gmail.com><br>wrote:<br><br>I had thought about these questions, but I want to know your idea<br>besides typed component:<br>1. LPM allows "data discovery". How will exact match do similar<br>things?<br>2. will removing selectors improve performance? How do we use<br>other<br>faster technique to replace selector?<br>3. fixed byte length and type. I agree more that type can be fixed<br>byte, but 2 bytes for length might not be enough for future.<br><br><br>On Sat, Sep 20, 2014 at 5:36 AM, Dave Oran (oran)<br><oran@cisco.com> wrote:<br><br>On Sep 18, 2014, at 9:09 PM, Tai-Lin Chu <tailinchu@gmail.com><br>wrote:<br><br>I know how to make #2 flexible enough to do what things I can<br>envision we need to do, and with a few simple conventions on<br>how the registry of types is managed.<br><br><br>Could you share it with us?<br><br>Sure. Here＊s a strawman.<br><br>The type space is 16 bits, so you have 65,565 types.<br><br>The type space is currently shared with the types used for the<br>entire protocol, that gives us two options:<br>(1) we reserve a range for name component types. Given the<br>likelihood there will be at least as much and probably more need<br>to component types than protocol extensions, we could reserve 1/2<br>of the type space, giving us 32K types for name components.<br>(2) since there is no parsing ambiguity between name components<br>and other fields of the protocol (sine they are sub-types of the<br>name type) we could reuse numbers and thereby have an entire 65K<br>name component types.<br><br>We divide the type space into regions, and manage it with a<br>registry. If we ever get to the point of creating an IETF<br>standard, IANA has 25 years of experience running registries and<br>there are well-understood rule sets for different kinds of<br>registries (open, requires a written spec, requires standards<br>approval).<br><br>- We allocate one ※default" name component type for ※generic<br>name§, which would be used on name prefixes and other common<br>cases where there are no special semantics on the name component.<br>- We allocate a range of name component types, say 1024, to<br>globally understood types that are part of the base or extension<br>NDN specifications (e.g. chunk#, version#, etc.<br>- We reserve some portion of the space for unanticipated uses<br>(say another 1024 types)<br>- We give the rest of the space to application assignment.<br><br>Make sense?<br><br><br>While I＊m sympathetic to that view, there are three ways in<br>which Moore＊s law or hardware tricks will not save us from<br>performance flaws in the design<br><br><br>we could design for performance,<br><br>That＊s not what people are advocating. We are advocating that we<br>*not* design for known bad performance and hope serendipity or<br>Moore＊s Law will come to the rescue.<br><br>but I think there will be a turning<br>point when the slower design starts to become "fast enough§.<br><br>Perhaps, perhaps not. Relative performance is what matters so<br>things that don＊t get faster while others do tend to get dropped<br>or not used because they impose a performance penalty relative to<br>the things that go faster. There is also the ※low-end§ phenomenon<br>where impovements in technology get applied to lowering cost<br>rather than improving performance. For those environments bad<br>performance just never get better.<br><br>Do you<br>think there will be some design of ndn that will *never* have<br>performance improvement?<br><br>I suspect LPM on data will always be slow (relative to the other<br>functions).<br>i suspect exclusions will always be slow because they will<br>require extra memory references.<br><br>However I of course don＊t claim to clairvoyance so this is just<br>speculation based on 35+ years of seeing performance improve by 4<br>orders of magnitude and still having to worry about counting<br>cycles and memory references’<br><br>On Thu, Sep 18, 2014 at 5:20 PM, Dave Oran (oran)<br><oran@cisco.com> wrote:<br><br>On Sep 18, 2014, at 7:41 PM, Tai-Lin Chu<br><tailinchu@gmail.com> wrote:<br><br>We should not look at a certain chip nowadays and want ndn to<br>perform<br>well on it. It should be the other way around: once ndn app<br>becomes<br>popular, a better chip will be designed for ndn.<br><br>While I＊m sympathetic to that view, there are three ways in<br>which Moore＊s law or hardware tricks will not save us from<br>performance flaws in the design:<br>a) clock rates are not getting (much) faster<br>b) memory accesses are getting (relatively) more expensive<br>c) data structures that require locks to manipulate<br>successfully will be relatively more expensive, even with<br>near-zero lock contention.<br><br>The fact is, IP *did* have some serious performance flaws in<br>its design. We just forgot those because the design elements<br>that depended on those mistakes have fallen into disuse. The<br>poster children for this are:<br>1. IP options. Nobody can use them because they are too slow<br>on modern forwarding hardware, so they can＊t be reliably used<br>anywhere<br>2. the UDP checksum, which was a bad design when it was<br>specified and is now a giant PITA that still causes major pain<br>in working around.<br><br>I＊m afraid students today are being taught the that designers<br>of IP were flawless, as opposed to very good scientists and<br>engineers that got most of it right.<br><br>I feel the discussion today and yesterday has been off-topic.<br>Now I<br>see that there are 3 approaches:<br>1. we should not define a naming convention at all<br>2. typed component: use tlv type space and add a handful of<br>types<br>3. marked component: introduce only one more type and add<br>additional<br>marker space<br><br>I know how to make #2 flexible enough to do what things I can<br>envision we need to do, and with a few simple conventions on<br>how the registry of types is managed.<br><br>It is just as powerful in practice as either throwing up our<br>hands and letting applications design their own mutually<br>incompatible schemes or trying to make naming conventions with<br>markers in a way that is fast to generate/parse and also<br>resilient against aliasing.<br><br>Also everybody thinks that the current utf8 marker naming<br>convention<br>needs to be revised.<br><br><br><br>On Thu, Sep 18, 2014 at 3:27 PM, Felix Rabe <felix@rabe.io><br>wrote:<br>Would that chip be suitable, i.e. can we expect most names<br>to fit in (the<br>magnitude of) 96 bytes? What length are names usually in<br>current NDN<br>experiments?<br><br>I guess wide deployment could make for even longer names.<br>Related: Many URLs<br>I encounter nowadays easily don't fit within two 80-column<br>text lines, and<br>NDN will have to carry more information than URLs, as far as<br>I see.<br><br><br>On 18/Sep/14 23:15, Marc.Mosko@parc.com wrote:<br><br>In fact, the index in separate TLV will be slower on some<br>architectures,<br>like the ezChip NP4. The NP4 can hold the fist 96 frame<br>bytes in memory,<br>then any subsequent memory is accessed only as two adjacent<br>32-byte blocks<br>(there can be at most 5 blocks available at any one time).<br>If you need to<br>switch between arrays, it would be very expensive. If you<br>have to read past<br>the name to get to the 2nd array, then read it, then backup<br>to get to the<br>name, it will be pretty expensive too.<br><br>Marc<br><br>On Sep 18, 2014, at 2:02 PM, <Ignacio.Solis@parc.com><br><Ignacio.Solis@parc.com> wrote:<br><br>Does this make that much difference?<br><br>If you want to parse the first 5 components. One way to do<br>it is:<br><br>Read the index, find entry 5, then read in that many bytes<br>from the start<br>offset of the beginning of the name.<br>OR<br>Start reading name, (find size + move ) 5 times.<br><br>How much speed are you getting from one to the other? You<br>seem to imply<br>that the first one is faster. I don易t think this is the<br>case.<br><br>In the first one you易ll probably have to get the cache line<br>for the index,<br>then all the required cache lines for the first 5<br>components. For the<br>second, you易ll have to get all the cache lines for the first<br>5 components.<br>Given an assumption that a cache miss is way more expensive<br>than<br>evaluating a number and computing an addition, you might<br>find that the<br>performance of the index is actually slower than the<br>performance of the<br>direct access.<br><br>Granted, there is a case where you don易t access the name at<br>all, for<br>example, if you just get the offsets and then send the<br>offsets as<br>parameters to another processor/GPU/NPU/etc. In this case<br>you may see a<br>gain IF there are more cache line misses in reading the name<br>than in<br>reading the index. So, if the regular part of the name<br>that you易re<br>parsing is bigger than the cache line (64 bytes?) and the<br>name is to be<br>processed by a different processor, then your might see some<br>performance<br>gain in using the index, but in all other circumstances I<br>bet this is not<br>the case. I may be wrong, haven易t actually tested it.<br><br>This is all to say, I don易t think we should be designing the<br>protocol with<br>only one architecture in mind. (The architecture of sending<br>the name to a<br>different processor than the index).<br><br>If you have numbers that show that the index is faster I<br>would like to see<br>under what conditions and architectural assumptions.<br><br>Nacho<br><br>(I may have misinterpreted your description so feel free to<br>correct me if<br>I易m wrong.)<br><br><br>--<br>Nacho (Ignacio) Solis<br>Protocol Architect<br>Principal Scientist<br>Palo Alto Research Center (PARC)<br>+1(650)812-4458<br>Ignacio.Solis@parc.com<br><br><br><br><br><br>On 9/18/14, 12:54 AM, "Massimo Gallo"<br><massimo.gallo@alcatel-lucent.com><br>wrote:<br><br>Indeed each components' offset must be encoded using a fixed<br>amount of<br>bytes:<br><br>i.e.,<br>Type = Offsets<br>Length = 10 Bytes<br>Value = Offset1(1byte), Offset2(1byte), ...<br><br>You may also imagine to have a "Offset_2byte" type if your<br>name is too<br>long.<br><br>Max<br><br>On 18/09/2014 09:27, Tai-Lin Chu wrote:<br><br>if you do not need the entire hierarchal structure (suppose<br>you only<br>want the first x components) you can directly have it using<br>the<br>offsets. With the Nested TLV structure you have to<br>iteratively parse<br>the first x-1 components. With the offset structure you cane<br>directly<br>access to the firs x components.<br><br>I don't get it. What you described only works if the<br>"offset" is<br>encoded in fixed bytes. With varNum, you will still need to<br>parse x-1<br>offsets to get to the x offset.<br><br><br><br>On Wed, Sep 17, 2014 at 11:57 PM, Massimo Gallo<br><massimo.gallo@alcatel-lucent.com> wrote:<br><br>On 17/09/2014 14:56, Mark Stapp wrote:<br><br>ah, thanks - that's helpful. I thought you were saying "I<br>like the<br>existing NDN UTF8 'convention'." I'm still not sure I<br>understand what<br>you<br>_do_ prefer, though. it sounds like you're describing an<br>entirely<br>different<br>scheme where the info that describes the name-components is<br>...<br>someplace<br>other than _in_ the name-components. is that correct? when<br>you say<br>"field<br>separator", what do you mean (since that's not a "TL" from a<br>TLV)?<br><br>Correct.<br>In particular, with our name encoding, a TLV indicates the<br>name<br>hierarchy<br>with offsets in the name and other TLV(s) indicates the<br>offset to use<br>in<br>order to retrieve special components.<br>As for the field separator, it is something like "/".<br>Aliasing is<br>avoided as<br>you do not rely on field separators to parse the name; you<br>use the<br>"offset<br>TLV " to do that.<br><br>So now, it may be an aesthetic question but:<br><br>if you do not need the entire hierarchal structure (suppose<br>you only<br>want<br>the first x components) you can directly have it using the<br>offsets.<br>With the<br>Nested TLV structure you have to iteratively parse the first<br>x-1<br>components.<br>With the offset structure you cane directly access to the<br>firs x<br>components.<br><br>Max<br><br><br>-- Mark<br><br>On 9/17/14 6:02 AM, Massimo Gallo wrote:<br><br>The why is simple:<br><br>You use a lot of "generic component type" and very few<br>"specific<br>component type". You are imposing types for every component<br>in order<br>to<br>handle few exceptions (segmentation, etc..). You create a<br>rule<br>(specify<br>the component's type ) to handle exceptions!<br><br>I would prefer not to have typed components. Instead I would<br>prefer<br>to<br>have the name as simple sequence bytes with a field<br>separator. Then,<br>outside the name, if you have some components that could be<br>used at<br>network layer (e.g. a TLV field), you simply need something<br>that<br>indicates which is the offset allowing you to retrieve the<br>version,<br>segment, etc in the name...<br><br><br>Max<br><br><br><br><br><br>On 16/09/2014 20:33, Mark Stapp wrote:<br><br>On 9/16/14 10:29 AM, Massimo Gallo wrote:<br><br>I think we agree on the small number of "component types".<br>However, if you have a small number of types, you will end<br>up with<br>names<br>containing many generic components types and few specific<br>components<br>types. Due to the fact that the component type specification<br>is an<br>exception in the name, I would prefer something that specify<br>component's<br>type only when needed (something like UTF8 conventions but<br>that<br>applications MUST use).<br><br>so ... I can't quite follow that. the thread has had some<br>explanation<br>about why the UTF8 requirement has problems (with aliasing,<br>e.g.)<br>and<br>there's been email trying to explain that applications don't<br>have to<br>use types if they don't need to. your email sounds like "I<br>prefer<br>the<br>UTF8 convention", but it doesn't say why you have that<br>preference in<br>the face of the points about the problems. can you say why<br>it is<br>that<br>you express a preference for the "convention" with problems ?<br><br>Thanks,<br>Mark<br><br>.<br><br>_______________________________________________<br>Ndn-interest mailing list<br>Ndn-interest@lists.cs.ucla.edu<br>http://www.lists.cs.ucla.edu/mailman/listinfo/ndn-interest<br><br>_______________________________________________<br>Ndn-interest mailing list<br>Ndn-interest@lists.cs.ucla.edu<br>http://www.lists.cs.ucla.edu/mailman/listinfo/ndn-interest<br><br>_______________________________________________<br>Ndn-interest mailing list<br>Ndn-interest@lists.cs.ucla.edu<br>http://www.lists.cs.ucla.edu/mailman/listinfo/ndn-interest<br><br><br><br>_______________________________________________<br>Ndn-interest mailing list<br>Ndn-interest@lists.cs.ucla.edu<br>http://www.lists.cs.ucla.edu/mailman/listinfo/ndn-interest<br><br><br><br>_______________________________________________<br>Ndn-interest mailing list<br>Ndn-interest@lists.cs.ucla.edu<br>http://www.lists.cs.ucla.edu/mailman/listinfo/ndn-interest<br><br><br>_______________________________________________<br>Ndn-interest mailing list<br>Ndn-interest@lists.cs.ucla.edu<br>http://www.lists.cs.ucla.edu/mailman/listinfo/ndn-interest<br><br><br>_______________________________________________<br>Ndn-interest mailing list<br>Ndn-interest@lists.cs.ucla.edu<br>http://www.lists.cs.ucla.edu/mailman/listinfo/ndn-interest<br><br><br><br>_______________________________________________<br>Ndn-interest mailing list<br>Ndn-interest@lists.cs.ucla.edu<br>http://www.lists.cs.ucla.edu/mailman/listinfo/ndn-interest<br><br><br><br><br></blockquote><br>_______________________________________________<br>Ndn-interest mailing list<br><a href="mailto:Ndn-interest@lists.cs.ucla.edu">Ndn-interest@lists.cs.ucla.edu</a><br>http://www.lists.cs.ucla.edu/mailman/listinfo/ndn-interest<br></blockquote><br><br>_______________________________________________<br>Ndn-interest mailing list<br><a href="mailto:Ndn-interest@lists.cs.ucla.edu">Ndn-interest@lists.cs.ucla.edu</a><br><a href="http://www.lists.cs.ucla.edu/mailman/listinfo/ndn-interest">http://www.lists.cs.ucla.edu/mailman/listinfo/ndn-interest</a></blockquote></div></blockquote></div><br></div></body></html>