[Ndn-interest] NDN Packet Format
Michael Weiss
wm at ars.is
Mon Dec 2 07:03:38 PST 2013
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.
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.
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.
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. 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.
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.
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
Best wishes, m
[Spec0.1] http://named-data.net/wp-content/uploads/2013/11/packetformat.pdf
[NaCl] http://nacl.cr.yp.to/sign.html
More information about the Ndn-interest
mailing list