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

[Junxiao Shi]

Hi Christian

protocol in charge
The protocol in charge is determined by the link, not determined by every
packet.
Before an NDNLPv2 packet is processed, the receiver already knows what
features are enabled.
In the normal case, a link cannot be configured to run two fragmentation
features at the same time.

For example, if IndexedFragmentation is enabled on a link:
The receiver will expect Sequence, FragIndex, and FragCount.
When Sequence is missing, the packet is dropped.
When FragIndex is missing, it implied value 0 is used.
When FragCount is missing, it implied value 1 is used.

When a BeginEndFragBits field is received,
if the receiver understands B-E fragmentation feature but this feature is
disabled on this link, B-E fragmentation feature should define what to do
in this situation (typically, either drop or ignore);
if the receiver does not understand B-E fragmentation feature, the unknown
field procedure is used.

In case some link must run two fragmentation features at the same time, one
may define a new fragmentation feature that is a combination of these two.
It would be "Indexed + B-E fragmentation". It can either declare a demux
field, or dispatch according to what fields are present.
However, such combination fragmentation feature is not recommended. It's
expected for a link to choose at most one fragmentation feature.


Yours, Junxiao

On Wed, Jun 10, 2015 at 1:18 AM, <christian.tschudin at unibas.ch> wrote:

> 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.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/nfd-dev/attachments/20150610/c0fa9dff/attachment.html>