[Ndn-interest] NDN Packet Format

[Lixia Zhang]

catching up email on a long flight: Michael, thanks for this long and interesting msg!
below is my own 2 cents on the questions.

On Dec 2, 2013, at 7:03 AM, Michael Weiss <wm at ars.is> wrote:

> Greetings everyone,
> 
> I welcome the decision to revisit the packet format [Spec0.1]. I'm probably missing some aspects, that are not discussed in that document, but here are my thoughts so far:
> 
> VAR-NUMBER: 64 bits for a length field matches the size used in many systems today but, given that the length is field is variable length anyway, I'd rather have he possibilty to use 128 bit length fields, too.

hmm, not sure I fully understand the implication of this comment.
the current encoding allows the length field to go up to 8 bytes (for a value field up to 2^64 byte = 1.8X10^19), are you thinking this is not adequate for reasonable future?

> Interest packet: I have not thought too hard about the computational implications on this one but in general, I'd prefer to have all required fields before the optional fields and thus move to the nonce right after the name and before the selectors.

we discussed that option earlier, however people more familiar with implementation argued that the selector fields should go first to ease the lookup (e.g. do a hash of name+selector as a lookup key)

> PublisherPublicKeyLocator: It has taken me some time to figure out how to handle colliding key names and the only solution I can come up with is to include the digest component in the key name. If that is the intended way, I suggest to be more explicit about it in the specification.

digest can certainly prevent collisions, but given that NDN uses hierarchically structured names including key names, I would like to better understand your scenarios of possible key name collisions first, if you dont mind elaborate a bit.

> On a slightly related note, high on my wishlist for format/protocol redesigns is the ability to directly use public keys in place of digests or locators, especially since implementations with fast operations and 256 bit public keys [NaCl] are available.

this is an interesting suggestion. I think it assumes that some a prior steps already occurred that provided one with the keybits of a trusted key.

> Right next to that wish would be to use the packet format within signatures or any other complex data needed for the core protocols for that matter.
> 
> Now, to a more philosophical discussion: TLV
> I'm not convinced that we need types at the structure level. Explicitly typed values can always be represented with one more level of nesting and a type-value pair inside. My recommendation is to use something semantically equivalent to S-expressions and work out an interchange format for use on the wire. The reasoning behind a typeless (beyond length and value) structure is that types in the structure itself require a high level of agreement and may hide computational complexity. Protocols would still be able to reuse type dictionaries from other protocols but that would not require coordination among all other protocols. Further, types can be omitted if protocols are precise about the set of fields on each level and their order. I argue that the inabilty to erase types is a sign of hidden complexity.

another interesting idea. My thought:
1/ yes the type definition requires agreement, but so does protocols with precise fields on each level and their order, right?

2/ as the 0.1 spec stated, the choice of TLV format is for its flexibility in adding new types and phasing out old types as the protocol evolves over time. a precisely defined protocol would not support incremental changes, right?


> On a more practical note, my suggestion for such a format is to use Variable Length Values as used by MIDI for length fields, meaning one continuation bit and 7 bits of data in each octet in whatever bit and byte order the signaling folks among you favour. The minimum number of octets MUST be used to ensure uniqueness of representation. The null byte could then be used to represent omitted optional fields.

we also considered this encoding format earlier, but rejected it due to the processing (which might not best fit hardwire implementations)

> For more insight on the desire for simple exchange formats, I highly recommend watching "The Science of Insecurity" held on 28C3 and related material on http://langsec.org

thanks for the pointer!  
My flight does not have Internet connection but will watch this when I get a chance.

> Best wishes, m
> 
> [Spec0.1] http://named-data.net/wp-content/uploads/2013/11/packetformat.pdf
> [NaCl] http://nacl.cr.yp.to/sign.html
> _______________________________________________
> Ndn-interest mailing list
> Ndn-interest at lists.cs.ucla.edu
> http://www.lists.cs.ucla.edu/mailman/listinfo/ndn-interest