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

[Dave Oran (oran)]

> On Jun 10, 2015, at 11:40 AM, Junxiao Shi <shijunxiao at email.arizona.edu> wrote:
> 
> 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.
How? Not by hand on each end I hope? No initialization handshake?

> 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.
> 
> _______________________________________________
> Nfd-dev mailing list
> Nfd-dev at lists.cs.ucla.edu
> http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev