[Nfd-dev] review request: NDNLPv2 NACK, Fragmentation, LocalControlHeader

[christian.tschudin at unibas.ch]

Hi Junxiao,

thanks, nice to see this uptake.

I was (waiting for time to write this up and) thinking about another 
general comment on the NDNLPv2 spec:

Currently it seems that the "protocol in charge" is defined implicitely 
through the presence or absence of some fields. For example, 
IndexedFragmentation could be defined as

"needs Sequence plus at least one of the fields FragIndex and FragCount"

If I introduce a BeginEndFragmentation protocol, the rule would be

"needs the BeginEndFragBits field"

and the implicit assumption that the fields present in a packet must 
violate the previous rules, otherwise the router is confused which 
protocol is in charge. (see also the note below on the "roles" that a 
router should adopt).


My suggestion: the spec should either spell out these rules (and how new 
rules have to be formed), or introduce an explicit protocol demux field 
as is the case with SignatureType.

The latter approach has the benefit that new protocols can reuse 
existing fields (and their type values) and that new protocols do not 
necessarily need a new type-value (to mark their presence).

What do you think?

best, christian


PS: Here is a link on that question of how to organize the header space, 
see Bob Braden et al's "From Protocol Stacks to Protocol Heaps - Role 
Based Architecture" 
http://conferences.sigcomm.org/hotnets/2002/program.html

which is exactly what TLV permits do to, namely to escape the strict 
encapsulation. Dropping the header container was one such step in that 
direction.


On Wed, 10 Jun 2015, Junxiao Shi wrote:

> Hi Christian
> 20150608 NFD call decides to take two of your suggestions.
> 
> NdnlpHeader wrapper
> NdnlpHeader wrapper is eliminated.
> Instead, header fields are placed directly under LpPacket element.
> TLV-TYPE codes [81:99] and [800:959] are reserved for header fields, and
> [960:999] are reserved for trailer fields.
> 
> Unknown Fields
> I have adopted the idea in
> http://www.lists.cs.ucla.edu/pipermail/nfd-dev/2014-July/000282.html
> When an unknown header field appears, if its TLV-TYPE is within [800:959]
> range, the least significant bit determines whether to drop the packet or
> ignore the field. For [81:99] range, the only action is to drop the packet.
> 
> 
> The protocol document has been updated to reflect the above (and other)
> changes.
> http://redmine.named-data.net/projects/nfd/wiki/NDNLPv2
> 
> Yours, Junxiao
> 
> On Thu, May 28, 2015 at 2:28 PM, Junxiao Shi <shijunxiao at email.arizona.edu>
> wrote:
> 
> NdnlpHeader wrapper
> In the full plan NDNLPv2_20150513.pptx page 17-20, we have a header
> and a trailer. The header wrapper makes it easier to define the
> portion covered by HMAC signature (page 53), and permits a padding at
> the end of header (page 24).
> 2-octet overhead is negligible on the link types mentioned in "Goals"
> section. NDNLPv2 is not designed for 20-octet MTU links; those links
> need a different link adaptation layer protocol.
> 
> Unknown Fields
> Excerpt from NDNLPv2_20150513.pptx page 27:
>       Rationale: NdnlpPacket is hop-by-hop. It's feasible to
>       ensure everyone to understand all fields.
> 
> 
> Ignoring an unknown field will cause incorrect operations, see #2520
> note-11.
> 
> A vendor-specific extension can claim a TLV-TYPE as "known field but
> relevant feature is disabled".
> This is not a "unknown field".
> 
> On Thu, May 28, 2015 at 7:33 AM, <christian.tschudin at unibas.ch> wrote:
>       A packet layout question: Isn't the NdnlpHeader wrapper
>       redundant? You can see this in the grammar where no other
>       field can ever follow the outer NDNLP-PACKET-TYPE and
>       -length.
>
>       Or are there plans for other fields coming before or
>       instead of the NdnlpHeader? Else I guess that this was
>       introduced for parsing speed reasons? But the price is
>       considerable: at least 2 mandatory bytes for every Ndnlp
>       packet for carrying no additional information.
> 
>
>       - Isn't the statement that "If an incoming NdnlpPacket
>       contains unknown
>         fields, the receiver MUST drop the packet"
>       evolution-hostile, also
>         against the old principle of "be liberal in what you
>       accept"?
>
>         Or expresses this a stance against the feature
>       interaction problem
>         and wants to prevent vendor-specific extensions? Asked
>       differently:
>         Shouldn't there be a type range reserved for
>       experimental and
>         vendor-specific extensions with an explicit semantics on
>       how to
>         process such packets with unknown extensions (without
>       dropping the
>         packet alltogether)?
> 
> 
>