[Nfd-dev] review request: NDNLPv2 NACK, Fragmentation, LocalControlHeader
Junxiao Shi
shijunxiao at email.arizona.edu
Thu Jun 4 12:00:20 PDT 2015
Hi Christian
The statement "NDNLPv2 will be an index-fragment protocol only" is wrong.
B-E fragmentation is possible, but B-indicator and E-indicator need to be
header fields. The NdnlpFragment type remains the same.
Your assumption is not wrong. NDNLPv2 is designed to be extensible: each
feature can add its own header or trailer fields.
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).
Otherwise, it's up to the link implementation to differentiate between a
NDNLPv2 packet and a packet of another link protocol.
Yours, Junxiao
On Mon, Jun 1, 2015 at 3:56 AM, <christian.tschudin at unibas.ch> wrote:
> 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
>>
>>
>>
>>
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/nfd-dev/attachments/20150604/60ac45c4/attachment.html>
More information about the Nfd-dev
mailing list