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

[Junxiao Shi]

Hi Christian

NdnlpHeader wrapper
In the full plan NDNLPv2_20150513.pptx
<http://redmine.named-data.net/attachments/download/327/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.
See also
http://www.lists.cs.ucla.edu/pipermail/ndn-lib/2014-November/000215.html 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
<http://redmine.named-data.net/attachments/download/327/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
>>
>>
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/nfd-dev/attachments/20150528/240e4449/attachment.html>