<div dir="ltr">Hi Christian<div class="gmail_extra"><br></div><div class="gmail_extra">The statement "NDNLPv2 will be an index-fragment protocol only" is wrong.<br></div><div class="gmail_extra">B-E fragmentation is possible, but B-indicator and E-indicator need to be header fields. The NdnlpFragment type remains the same.</div><div class="gmail_extra"><br></div><div class="gmail_extra">Your assumption is not wrong. NDNLPv2 is designed to be extensible: each feature can add its own header or trailer fields.</div><div class="gmail_extra"><br></div><div class="gmail_extra">Typically, a link should not have multiple link protocols: most links should use NDNLPv2; a link with ultra low MTU (eg. NFC) should use a different link protocol (probably with a fixed header).</div><div class="gmail_extra">Otherwise, it's up to the link implementation to differentiate between a NDNLPv2 packet and a packet of another link protocol.</div><div class="gmail_extra"><br></div><div class="gmail_extra">Yours, Junxiao</div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Jun 1, 2015 at 3:56 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">Hi Junxiao,<br>
<br>
thanks for these answers.<br>
<br>
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?<br>
<br>
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.<br>
<br>
What would you suggest as header structure for bringing LP variants into the type-value-space of NDN packets? A forth outer type?<br>
<br>
best, christian<div class="HOEnZb"><div class="h5"><br>
<br>
<br>
On Thu, 28 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">
Hi Christian<br>
NdnlpHeader wrapper<br>
In the full plan NDNLPv2_20150513.pptx page 17-20, we have a header and a<br>
trailer. The header wrapper makes it easier to define the portion covered by<br>
HMAC signature (page 53), and permits a padding at the end of header (page<br>
24).<br>
2-octet overhead is negligible on the link types mentioned in "Goals"<br>
section. NDNLPv2 is not designed for 20-octet MTU links; those links need a<br>
different link adaptation layer protocol.<br>
<br>
B-E Fragmentation and extra fragment types<br>
No, only NdnlpFragment type is allowed.<br>
3-octet overhead is negligible on the link types mentioned in "Goals"<br>
section. NDNLPv2 is not designed for 20-octet MTU links; those links need a<br>
different link adaptation layer protocol.<br>
<br>
Concatenation in single frame<br>
NDNLPv2 is able to operation on a stream socket, so it can handle<br>
concatenation in a single frame.<br>
However, NDNLPv2 does not define whether concatenation is allowed, and this<br>
is up to face implementation.<br>
Seealso <a href="http://www.lists.cs.ucla.edu/pipermail/ndn-lib/2014-November/000215.ht" target="_blank">http://www.lists.cs.ucla.edu/pipermail/ndn-lib/2014-November/000215.ht</a><br>
ml on a related topic about WebSocket frame vs network layer packets.<br>
<br>
NdnlpSequence width<br>
The width is chosen by link implementation.<br>
Suppose EthernetFace implementation for 100Mbps link has chosen 48-bit, all<br>
NdnlpSequence on this link must be 48-bit.<br>
There's no negotiation.<br>
<br>
Unknown Fields<br>
Excerpt from NDNLPv2_20150513.pptx page 27:<br>
      Rationale: NdnlpPacket is hop-by-hop. It's feasible to ensure<br>
      everyone to understand all fields.<br>
<br>
<br>
Ignoring an unknown field will cause incorrect operations, see #2520<br>
note-11.<br>
<br>
A vendor-specific extension can claim a TLV-TYPE as "known field but<br>
relevant feature is disabled".<br>
This is not a "unknown field".<br>
<br>
Extension fields on first fragment only<br>
This mainly applies to extension fields that decorate a whole network layer<br>
packet.<br>
For example, it's sufficient to add a Network NACK on the first fragment,<br>
and it's unnecessary to repeat the Network NACK field on subsequent<br>
fragments.<br>
<br>
Fields that do not decorate a network layer packet, such as Automated Repeat<br>
reQuest, can be added to any fragment.<br>
<br>
Yours, Junxiao<br>
<br>
On Thu, May 28, 2015 at 7:33 AM, <<a href="mailto:christian.tschudin@unibas.ch" target="_blank">christian.tschudin@unibas.ch</a>> wrote:<br>
      Dear Junxiao,<br>
<br>
      thanks for sharing your design plans and the possibility to<br>
      comment.<br>
<br>
      A packet layout question: Isn't the NdnlpHeader wrapper<br>
      redundant? You can see this in the grammar where no other field<br>
      can ever follow the outer NDNLP-PACKET-TYPE and -length.<br>
<br>
      Or are there plans for other fields coming before or instead of<br>
      the NdnlpHeader? Else I guess that this was introduced for<br>
      parsing speed reasons? But the price is considerable: at least 2<br>
      mandatory bytes for every Ndnlp packet for carrying no<br>
      additional information.<br>
<br>
      Regarding fragmentation, I'm wondering about plans for the B+E<br>
      style mentioned in the slides. Could additional fragment types<br>
      be forseen?<br>
<br>
        fragmentBegin, fragmentMiddle, fragmendEnd and<br>
      fragmentBeginEnd<br>
<br>
      This would bring the overhead from 2 or 3 bytes for a B+E header<br>
      extension down to 0 additional bytes. *)<br>
<br>
      Finally some suggestions where the packet format description<br>
      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<br>
      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<br>
      unknown<br>
        fields, the receiver MUST drop the packet" evolution-hostile,<br>
      also<br>
        against the old principle of "be liberal in what you accept"?<br>
<br>
        Or expresses this a stance against the feature interaction<br>
      problem<br>
        and wants to prevent vendor-specific extensions? Asked<br>
      differently:<br>
        Shouldn't there be a type range reserved for experimental and<br>
        vendor-specific extensions with an explicit semantics on how<br>
      to<br>
        process such packets with unknown extensions (without dropping<br>
      the<br>
        packet alltogether)?<br>
<br>
      - Related: Does the statement (in the indexed fragmentation<br>
      section)<br>
        reading "Unless otherwise specified, header extension fields<br>
      from<br>
        other features shall only appear on the first fragment." mean<br>
      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<br>
      like<br>
        a fragment ack or nack feature running in the other direction)<br>
      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<br>
      be<br>
         an interesting metric to observe in the design. Currently, it<br>
      seems<br>
         that a B+E scheme in NDNLP will vary between 12 and 7 bytes<br>
      of<br>
         overhead, depending on the final design and type allocation<br>
      choices<br>
         that will be made. In a BT low energy context with 20B MTU<br>
      this<br>
         means a change from 8 to 13 bytes payload, a 60% capacity<br>
      increase.<br>
<br>
<br>
      On Tue, 26 May 2015, Junxiao Shi wrote:<br>
<br>
<br>
            Dear folks<br>
<br>
            I have written the protocol spec of first batch of<br>
            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,<br>
            #2763,andhttp://<a href="http://redmine.named-data.net/attachments/download/301/NDNLPv2_20150417" target="_blank">redmine.named-data.net/attachments/download/301/NDNLPv2_20150417</a>.<br>
            ppt<br>
            x<br>
<br>
            I'll appreciate all review comments.<br>
            You don't have to be an expert in order to do a<br>
            design review.<br>
<br>
            Yours, Junxiao<br>
<br>
<br>
<br>
<br>
<br>
</blockquote>
</div></div></blockquote></div><br></div></div>