[Ndn-interest] any comments on naming convention?

Mon Sep 15 14:09:26 PDT 2014

>From a general perspective we gave a short description of the changes from
CCN 0.x to 1.x at the last IETF.  You can find the slides at
http://www.ietf.org/proceedings/90/slides/slides-90-icnrg-10.pdf

Nacho

--
Nacho (Ignacio) Solis
Protocol Architect
Principal Scientist
Palo Alto Research Center (PARC)
+1(650)812-4458
Ignacio.Solis at parc.com

On 9/15/14, 1:56 PM, "Tai-Lin Chu" <tailinchu at gmail.com> wrote:

>@Marc,
>Do you mind giving a link to parc's tlv definition so that people will
>know the exact difference?
>
>Thanks.
>
>On Mon, Sep 15, 2014 at 12:23 PM,  <Marc.Mosko at parc.com> wrote:
>> If you wish to maintain the current NDN definition of canonical order,
>> having the T before the L will not work, if the T can have different
>>values.
>>
>> How do you do exclusions?  Are the not based on canonical order?  And
>>prefix
>> matching in general for ³left most child² versus ³right most child²?
>>That
>> is all affected by the canonical order.  You can change the definition
>>of
>> the canonical order to make these things work, but it will ripple
>>through
>> the stack and forwarder.
>>
>> I would also disagree with the statement "because most applications
>>won't
>> have different markers under the same prefix.²  What is that based on?
>>Of
>> course you need to match the markers and octet strings.  Also, the
>>forwarder
>> has no idea of ³the application.²  It has to treat all these things as
>> opaque values, it will be comparing the entire values to determine
>>canonical
>> ordering for content to interest matching.
>>
>> Marc
>>
>>
>> On Sep 15, 2014, at 12:12 PM, Thompson, Jeff <jefft0 at remap.ucla.edu>
>>wrote:
>>
>> Hi Marc. You say "if the T comes before the L, then the short-lex
>>ordering
>> does not work" meaning that the ordering will not depend on the length
>>of
>> the name component "value" but on the type.
>>
>> It seems Junxiao worried about this too when he said "It's unnecessary
>>to
>> compare marker code and BYTE* individually, because most applications
>>won't
>> have different markers under the same prefix."
>>
>> Is there a use case where it matters that short-lex odering is thrown
>>off
>> when comparing two name components with different types?  Is it safe to
>> assume that an application will always be doing short-lex comparison of
>>two
>> name components of the same type (for example, leftmost child of two
>>version
>> components)?
>>
>> - Jeff T
>>
>>
>> From: "Marc.Mosko at parc.com" <Marc.Mosko at parc.com>
>> Date: Monday, September 15, 2014 11:50 AM
>> To: Jeff Thompson <jefft0 at remap.ucla.edu>
>> Cc: "shijunxiao at email.arizona.edu" <shijunxiao at email.arizona.edu>,
>> "ndn-interest at lists.cs.ucla.edu" <ndn-interest at lists.cs.ucla.edu>
>> Subject: Re: [Ndn-interest] any comments on naming convention?
>>
>> On Sep 15, 2014, at 11:33 AM, Thompson, Jeff <jefft0 at remap.ucla.edu>
>>wrote:
>>
>> Hi Mark,
>>
>> Thanks for the clear summary.  You say "it became clear that it is
>>difficult
>> to have a ³strcmp()² style comparison over the raw TLV bytes with a
>> variable-length T and L encoding."  Can you say more about why
>> varible-length encoding makes strcmp difficult?
>>
>>
>> At the time, we were having discussions about is a 2-byte ³0² different
>>than
>> a 1-byte ³0², for example.  If they are the same meaning, but one is
>>just
>> incorrectly encoded in 2-bytes, then do we have to validate each T and
>>throw
>> away the ones that are mis-encoded?
>>
>> Also, if the T comes before the L, then the short-lex ordering does not
>> work.  Short-lex says that name component A is less than B if then
>>length of
>> A is less than B or of |A| = |B| and A sorts before B.  If the T comes
>> before the L, then you cannot simply do a strcmp() because the variable
>> length T¹s will throw things off.  All you can say is that within a T
>>value,
>> you use short-lex.
>>
>> Marc
>>
>> - Jeff T
>>
>> From: "Marc.Mosko at parc.com" <Marc.Mosko at parc.com>
>> Date: Monday, September 15, 2014 11:20 AM
>> To: "shijunxiao at email.arizona.edu" <shijunxiao at email.arizona.edu>
>> Cc: "ndn-interest at lists.cs.ucla.edu" <ndn-interest at lists.cs.ucla.edu>
>> Subject: Re: [Ndn-interest] any comments on naming convention?
>>
>> This is an interesting discussion.  At PARC, when we went away from
>>ccnb to
>> TLV-based name components, we agreed with the Cisco position that
>>different
>> types of name components should have different TLV types.
>>
>> Anything that used to be a command marker was moved to a TLV type and
>>we no
>> longer use command markers.  We see having TLV types in the name as
>> redundant with command markers, so long as there is a type space for
>> applications to use to generate their own application-dependent types.
>>
>> We use one general name (binary) name component, one for versions, one
>>for
>> segments (chunks), one for nonces (in the name, not an Interest nonce),
>>one
>> for keys.  In our re-implementation of the 0.x repo protocol, those repo
>> command-markers became their own application-dependent name TLV types.
>>In
>> our sync protocol, we use other application-dependent TLV types instead
>>of
>> command markers.
>>
>> Our ordering is defined as the lexicographic compare of each TLV,
>>including
>> the T and L.  Because we use a fixed type and fixed length value, this
>> ordering is always well-defined.  About a year ago, when we were
>>considering
>> different variable length TLV schemes, it became clear that it is
>>difficult
>> to have a ³strcmp()² style comparison over the raw TLV bytes with a
>> variable-length T and L encoding.  There are some T and L encoding
>>schemes
>> that still allow comparison over the raw bytes, but they have their own
>> drawbacks.
>>
>> One solution is to declare many new TLV types: VersionComponent,
>> SegmentComponent, TimestampComponent, etc.
>> This can guarantee unambiguity, but this restricts the introduction of
>>new
>> convention, because when we want to introduce another convention in the
>> future, old consumer applications would not understand the new TLV type.
>>
>>
>> I would disagree with this statement.  Anytime you introduce a new
>> command-marker, old applications will not understand it.  If the new
>> command-marker is required for application execution, then all
>>applications
>> must be updated.  If the new command-marker (or tlv type) is not
>>required,
>> then the old application should continue just fine treating the type as
>> opaque.
>>
>> Marc Mosko
>>
>>
>> On Sep 15, 2014, at 10:49 AM, Junxiao Shi <shijunxiao at email.arizona.edu>
>> wrote:
>>
>> Dear folks
>>
>> I agree with @MarkStapp that Naming Conventions rev1 does not guarantee
>> version/segment components to be unambiguous.
>> One alternate proposal was to use an additional NameComponent before the
>> number as a marker, such as "_v/<version>" "_s/<segment>". This
>>alternate
>> proposal is also unable to make version/segment components unambiguous,
>>and
>> it doesn't work well with ChildSelector.
>>
>> One easy solution to this problem is: restrict the octets to be used in
>> regular names.
>> In rev1, we could require regular NameComponent to start with a valid
>>UTF8
>> character.
>> In alternate proposal, we could forbid regular NameComponent to start
>>with
>> "_".
>> However, this solution is undesirable, because some applications do
>>need to
>> operate with binary components (eg. SignatureBits component in signed
>> Interest).
>>
>> NDN-TLV 0.2.0 (unapproved spec) introduces NumberComponent to indicate a
>> component is a number.
>> This is insufficient because it doesn't say the meaning of a number: is
>>it a
>> version number or a segment number?
>>
>> One solution is to declare many new TLV types: VersionComponent,
>> SegmentComponent, TimestampComponent, etc.
>> This can guarantee unambiguity, but this restricts the introduction of
>>new
>> convention, because when we want to introduce another convention in the
>> future, old consumer applications would not understand the new TLV type.
>>
>>
>> If I'm to redesign the convention, I would introduce a MarkedComponent
>>TLV
>> type.
>> The MarkedComponent TLV can appear in place of NameComponent.
>> The value part of a MarkedComponent contains a VAR-NUMBER which is a
>>marker
>> code, followed by zero or more arbitrary octets.
>>
>> Name ::= NAME-TYPE TLV-LENGTH (NameComponent | MarkedComponent)*
>> FinalBlockId ::= FINAL-BLOCK-ID-TYPE TLV-LENGTH (NameComponent |
>> MarkedComponent)
>> MarkedComponent ::= MARKED-COMPONENT-TYPE TLV-LENGTH VAR-NUMBER BYTE*
>>
>> The canonical order is defined as:
>>
>> A MarkedComponent is less than any NameComponent.
>> Two MarkedComponents are compared by their length and value, in the
>>same way
>> as NameComponent.
>>
>>
>> The benefits of this solution is:
>>
>> Version/segment/etc components are distinguished from regular
>>NameComponent,
>> because they have a distinct TLV-TYPE: MarkedComponent.
>> Adding a new convention only needs allocation of a marker code. No new
>>TLV
>> type is introduced, so that old consumer can continue to work.
>> Encoding marker code as VAR-NUMBER allows much larger marker space than
>> restricting to one-octet marker.
>> Canonical order evaluation is efficient. It's unnecessary to compare
>>marker
>> code and BYTE* individually, because most applications won't have
>>different
>> markers under the same prefix.
>>
>>
>>
>> Yours, Junxiao
>> _______________________________________________
>> Ndn-interest mailing list
>> Ndn-interest at lists.cs.ucla.edu
>> http://www.lists.cs.ucla.edu/mailman/listinfo/ndn-interest
>>
>>
>>
>>
>>
>> _______________________________________________
>> Ndn-interest mailing list
>> Ndn-interest at lists.cs.ucla.edu
>> http://www.lists.cs.ucla.edu/mailman/listinfo/ndn-interest
>>
>
>_______________________________________________
>Ndn-interest mailing list
>Ndn-interest at lists.cs.ucla.edu
>http://www.lists.cs.ucla.edu/mailman/listinfo/ndn-interest