<div dir="ltr">Hi Christian<div><br></div><div><font size="4">NdnlpHeader wrapper</font></div><div>In the full plan <a href="http://redmine.named-data.net/attachments/download/327/NDNLPv2_20150513.pptx" target="_blank">NDNLPv2_20150513.pptx</a> 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).</div><div>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.</div><div><br></div><div><font size="4">B-E Fragmentation and extra fragment types</font></div><div>No, only NdnlpFragment type is allowed.</div><div><div>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.</div></div><div><br></div><div><font size="4">Concatenation in single frame</font></div><div>NDNLPv2 is able to operation on a stream socket, so it can handle concatenation in a single frame.<br></div><div>However, NDNLPv2 does not define whether concatenation is allowed, and this is up to face implementation.</div><div>See also <a href="http://www.lists.cs.ucla.edu/pipermail/ndn-lib/2014-November/000215.html">http://www.lists.cs.ucla.edu/pipermail/ndn-lib/2014-November/000215.html</a> on a related topic about WebSocket frame vs network layer packets.</div><div><br></div><div><font size="4">NdnlpSequence width</font></div><div>The width is chosen by link implementation.</div><div>Suppose EthernetFace implementation for 100Mbps link has chosen 48-bit, all NdnlpSequence on this link must be 48-bit.</div><div>There's no negotiation.</div><div><br></div><div><div style="font-size:12.8000001907349px"><font size="4">Unknown Fields</font></div><div style="font-size:12.8000001907349px">Excerpt from <a href="http://redmine.named-data.net/attachments/download/327/NDNLPv2_20150513.pptx" target="_blank">NDNLPv2_20150513.pptx</a> page 27:</div><blockquote style="font-size:12.8000001907349px;margin:0px 0px 0px 40px;border:none;padding:0px">Rationale: NdnlpPacket is hop-by-hop. It's feasible to ensure everyone to understand all fields.</blockquote><div style="font-size:12.8000001907349px"><br></div><div style="font-size:12.8000001907349px">Ignoring an unknown field will cause incorrect operations, see #2520 note-11.</div></div><div><br></div><div>A vendor-specific extension can claim a TLV-TYPE as "known field but relevant feature is disabled".</div><div>This is not a "unknown field".</div><div><br></div><div><font size="4">Extension fields on first fragment only</font></div><div>This mainly applies to extension fields that decorate a whole network layer packet.</div><div>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.</div><div><br></div><div>Fields that do not decorate a network layer packet, such as Automated Repeat reQuest, can be added to any fragment.</div><div><br></div><div>Yours, Junxiao</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, May 28, 2015 at 7:33 AM, <span dir="ltr"><<a href="mailto:christian.tschudin@unibas.ch" target="_blank">christian.tschudin@unibas.ch</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Dear Junxiao,<br>
<br>
thanks for sharing your design plans and the possibility to comment.<br>
<br>
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.<br>
<br>
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.<br>
<br>
Regarding fragmentation, I'm wondering about plans for the B+E style mentioned in the slides. Could additional fragment types be forseen?<br>
<br>
fragmentBegin, fragmentMiddle, fragmendEnd and fragmentBeginEnd<br>
<br>
This would bring the overhead from 2 or 3 bytes for a B+E header extension down to 0 additional bytes. *)<br>
<br>
Finally some suggestions where the packet format description could benefit from clarifications regarding operational aspects:<br>
<br>
- NDNLP packet stuffing (concatenation) inside the same frame:<br>
ok or not?<br>
<br>
- mixed NDNLP/Interest/Data stuffing inside the same frame: ok or not?<br>
<br>
- fixed width of sequence number field: can the sender choose<br>
unilateraly or will be there a link negotiation protocol? Can<br>
the sender change the width on the fly?<br>
<br>
- Isn't the statement that "If an incoming NdnlpPacket contains unknown<br>
fields, the receiver MUST drop the packet" evolution-hostile, also<br>
against the old principle of "be liberal in what you accept"?<br>
<br>
Or expresses this a stance against the feature interaction problem<br>
and wants to prevent vendor-specific extensions? Asked differently:<br>
Shouldn't there be a type range reserved for experimental and<br>
vendor-specific extensions with an explicit semantics on how to<br>
process such packets with unknown extensions (without dropping the<br>
packet alltogether)?<br>
<br>
- Related: Does the statement (in the indexed fragmentation section)<br>
reading "Unless otherwise specified, header extension fields from<br>
other features shall only appear on the first fragment." mean that<br>
in general a link feature can/will squat the link for some<br>
self-chosen duration?<br>
For example, a hypothetical "urgent msg feature" (or signals like<br>
a fragment ack or nack feature running in the other direction) would<br>
have to wait until a fragment train has ended?<br>
<br>
best, christian<br>
<br>
<br>
*) Looking at the "minimum Ndnlp packet fragment overhead" might be<br>
an interesting metric to observe in the design. Currently, it seems<br>
that a B+E scheme in NDNLP will vary between 12 and 7 bytes of<br>
overhead, depending on the final design and type allocation choices<br>
that will be made. In a BT low energy context with 20B MTU this<br>
means a change from 8 to 13 bytes payload, a 60% capacity increase.<div class="HOEnZb"><div class="h5"><br>
<br>
<br>
On Tue, 26 May 2015, Junxiao Shi wrote:<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Dear folks<br>
<br>
I have written the protocol spec of first batch of features in NDNLPv2, and<br>
I need someone to review the design.<br>
<br>
<a href="http://redmine.named-data.net/projects/nfd/wiki/NDNLPv2" target="_blank">http://redmine.named-data.net/projects/nfd/wiki/NDNLPv2</a><br>
<br>
If you don't know what this is about, see #2520, #2763, andhttp://<a href="http://redmine.named-data.net/attachments/download/301/NDNLPv2_20150417.ppt" target="_blank">redmine.named-data.net/attachments/download/301/NDNLPv2_20150417.ppt</a><br>
x<br>
<br>
I'll appreciate all review comments.<br>
You don't have to be an expert in order to do a design review.<br>
<br>
Yours, Junxiao<br>
<br>
<br>
<br>
</blockquote>
</div></div></blockquote></div><br></div>