[Nfd-dev] review request: NDNLPv2 NACK, Fragmentation, LocalControlHeader
christian.tschudin at unibas.ch
christian.tschudin at unibas.ch
Thu May 28 07:33:56 PDT 2015
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
>
>
>
More information about the Nfd-dev
mailing list