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

Mon Jun 1 03:56:03 PDT 2015

Hi Junxiao,

thanks for these answers.

So it seems that NDNLPv2 will be an index-fragment protocol only, for 
the link-types mentioned in "Goals" only, and no B-E variant ever?

My assumption was that NDNLP would be a "framework" that various 
sub-network-layer protocols would share for their task-specific headers. 
But it seems that this is quite wrong.

What would you suggest as header structure for bringing LP variants into 
the type-value-space of NDN packets? A forth outer type?

best, christian

On Thu, 28 May 2015, Junxiao Shi wrote:

> Hi Christian
> 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.
> 
> B-E Fragmentation and extra fragment types
> No, only NdnlpFragment type is allowed.
> 3-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.
> 
> Concatenation in single frame
> NDNLPv2 is able to operation on a stream socket, so it can handle
> concatenation in a single frame.
> However, NDNLPv2 does not define whether concatenation is allowed, and this
> is up to face implementation.
> Seealso http://www.lists.cs.ucla.edu/pipermail/ndn-lib/2014-November/000215.ht
> ml on a related topic about WebSocket frame vs network layer packets.
> 
> NdnlpSequence width
> The width is chosen by link implementation.
> Suppose EthernetFace implementation for 100Mbps link has chosen 48-bit, all
> NdnlpSequence on this link must be 48-bit.
> There's no negotiation.
> 
> 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".
> 
> Extension fields on first fragment only
> This mainly applies to extension fields that decorate a whole network layer
> packet.
> For example, it's sufficient to add a Network NACK on the first fragment,
> and it's unnecessary to repeat the Network NACK field on subsequent
> fragments.
> 
> Fields that do not decorate a network layer packet, such as Automated Repeat
> reQuest, can be added to any fragment.
> 
> Yours, Junxiao
> 
> On Thu, May 28, 2015 at 7:33 AM, <christian.tschudin at unibas.ch> wrote:
>       Dear Junxiao,
>
>       thanks for sharing your design plans and the possibility to
>       comment.
>
>       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.
>
>       Regarding fragmentation, I'm wondering about plans for the B+E
>       style mentioned in the slides. Could additional fragment types
>       be forseen?
>
>         fragmentBegin, fragmentMiddle, fragmendEnd and
>       fragmentBeginEnd
>
>       This would bring the overhead from 2 or 3 bytes for a B+E header
>       extension down to 0 additional bytes. *)
>
>       Finally some suggestions where the packet format description
>       could benefit from clarifications regarding operational aspects:
>
>       - NDNLP packet stuffing (concatenation) inside the same frame:
>         ok or not?
>
>       - mixed NDNLP/Interest/Data stuffing inside the same frame: ok
>       or not?
>
>       - fixed width of sequence number field: can the sender choose
>         unilateraly or will be there a link negotiation protocol? Can
>         the sender change the width on the fly?
>
>       - 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)?
>
>       - Related: Does the statement (in the indexed fragmentation
>       section)
>         reading "Unless otherwise specified, header extension fields
>       from
>         other features shall only appear on the first fragment." mean
>       that
>         in general a link feature can/will squat the link for some
>         self-chosen duration?
>         For example, a hypothetical "urgent msg feature" (or signals
>       like
>         a fragment ack or nack feature running in the other direction)
>       would
>         have to wait until a fragment train has ended?
>
>       best, christian
> 
>
>       *) Looking at the "minimum Ndnlp packet fragment overhead" might
>       be
>          an interesting metric to observe in the design. Currently, it
>       seems
>          that a B+E scheme in NDNLP will vary between 12 and 7 bytes
>       of
>          overhead, depending on the final design and type allocation
>       choices
>          that will be made. In a BT low energy context with 20B MTU
>       this
>          means a change from 8 to 13 bytes payload, a 60% capacity
>       increase.
> 
>
>       On Tue, 26 May 2015, Junxiao Shi wrote:
> 
>
>             Dear folks
>
>             I have written the protocol spec of first batch of
>             features in NDNLPv2, and
>             I need someone to review the design.
>
>             http://redmine.named-data.net/projects/nfd/wiki/NDNLPv2
>
>             If you don't know what this is about, see #2520,
>             #2763,andhttp://redmine.named-data.net/attachments/download/301/NDNLPv2_20150417.
>             ppt
>             x
>
>             I'll appreciate all review comments.
>             You don't have to be an expert in order to do a
>             design review.
>
>             Yours, Junxiao
> 
> 
> 
> 
> 
>