NFD » NDN Specifications

There are several proposals on how an Interest NACK should be encoded as a packet:

• (ndnSIM) Add a NackCode field in Interest. This field contains the NACK code. If this field is missing, the packet is a regular Interest.
• (NDNFD) Define a new top level packet type. The packet contains a NACK code field, and an Interest field.
• (self-learning experiment in NFD v0.1) Represent NACK as an Interest under a special namespace. ndn:/localhop/NACK/<interest/name/components>/<code>/<selectors>/<nonce>

I prefer to define a new top level packet type:

NACK-TYPE TLV-LENGTH
  NACK-CODE-TYLE TLV-LENGTH <NackCode>
  <Interest>

I prefer this approach because the processing path of an Interest NACK is different from either Interest or Data.

20140708 conference call decides that @Junxiao should produce slides of a straw man design for broader discussion.

The design should include:

• what's the packet type, and why
• the semantics of NACK
• how forwarding pipelines process NACK

The design does not need to include how strategy reacts to NACK.

There should a different slide deck. Interest NACK is only one among the possible options:

Per-packet NACKs:

• interest-based NACK
• data-based NACK
• new packet type NACK
• link-layer NACK

Aggregate NACKs:

• link-layer?
• ?

The term Interest NACK appears in the paper because this type of NACK is in response to an Interest.
It doesn't imply the packet is encoded as an Interest; indeed, my proposal doesn't encode it as an Interest.

Link-layer NACK appears in NDNLP, and it's unrelated to this proposal.

Aggregate NACK is something reasonable, but I don't know about any NDN paper covering this topic.

What about a fourth option: think of NACK as a control application between neighbor routers and use a naming convention for the NACK? For example, if an upstream wants to NACK an Interest from a downstream node, it sends an Interest /<downstream_node_name>/<marker_for_nack>/<original_interest_info> on the face to the downstream node (or use for multiaccess link). The downstream node can send a Data response if necessary.

Sorry the Interest name didn't show up. Here it is again: What about a fourth option: think of NACK as a control application between neighbor routers and use a naming convention for the NACK? For example, if an upstream wants to NACK an Interest from a downstream node, it sends an Interest /<downstream_node_name>/<marker_for_nack>/<original_interest_info> on the face to the downstream node (or use <downstream_link_name> for multiaccess link). The downstream node can send a Data response if necessary.

The format in note-8 works, and it is easy to hack into a current forwarder without major changes in all the places.
The fundamental problem with this option is: Interest NACK is a network-layer message, so it shouldn't be confused with an application-layer message (the Interest with NACK marker).
The other problem is: the Data response is useless, but not sending a Data response causes the Interest to remain in PIT and wastes memory (unless there is a classifier before PIT insertion, which implies Interest NACK is not a "control application").

I do not fully agree with Note #9 and the slide #22 in the new slide deck. First, at a high level, I feel that the NACK achieves a network management functionality and should be handled by a management application on the nodes. Second, even if the performance may not be as good as a third packet type, this should not be a major consideration at this stage of the architectural development. I hope that we can try to keep just the two packet types Interest/Data as long as possible. As to the Data response, it doesn't hurt to send a response (even if it is dropped) just for informational purpose, e.g., indicate how much the flow will be slowed down.

20140805 conference call agrees that an Interest NACK packet should contain the Interest, and a reason code.

We are leaning towards encoding NACK as a Data with new ContentType, and forwarder needs separate processing rules for Data-NACK.

There's dispute on whether producer generated NACK should have the same format as a network generated NACK.

#12 seems to give an inaccurate description about the outcome of 20140805 conference call.
First, the discussion focused on what kind of packet this NACK should be; we did not go down to the level of the content of the NACK (we only agreed that the NACK should be able to provide an indication of reason)

Second, the discussion did NOT conclude with any preference ("lead towards" is a mis-statement). Rather, the discussion exposed the tradeoffs: if we go with #11 suggestion, the advantage is keeping name opaqueness to forwarding plane; the con is that the NACK ends in management app, while we want it to influence settings in the strategy and forwarding plane -- It seems complex to achieve by the management.

There was a debate on whether producer and router generate same type of NACK packet, just with different causes (encoded in some error code), i.e. producer generated NACK should be fully understood by NDN forwarding layer so the latter knows how to handle it.

20140807 conference call discussed Beichuan's new proposal:

the combination of a few mechanisms:

• simply returning the interest back to downstream without any modification. this is the easiest and quickest way, can be done now without any change to the protocol. it doesn't tell the cause, but simply reject the interest. this can be used as quick NACKs for temporary causes.
• app-level control protocol between two neighboring nodes. they can exchange more information, and about causes that may last longer than "transient", e.g., NACK due to policy, link failure, etc.
• adding the NACKs generated by authoritative producers. this is a subtype of data packet, will consume the PIT entry and can be cached.

Two questions are raised about out of band, control protocol level NACKs:

• Who is responsible for sending those control protocol level NACKs?
  • The direct sender is the control application / module. But who instructs the control module to send the NACKs?
  • NACK due to policy: the policy module, according to a rule in the FIB, can send this NACK
  • link failure: even if a link failure may affect a prefix, the strategy can probably find an alternate path so that no NACK is needed, so strategy needs to send NACK
  • congestion: measurements are taken by the strategy, so strategy needs to send NACK
• How can the strategy obtain the information in the control protocol level NACKs?
  • It's incorrect to let the control module "mark a face as yellow" because that makes the control module part of the strategy, and conflicts with namespace-based strategy choice.
  • Having the control module setting some flags on tables may not be sufficient.
  • It's desirable to pass the information to strategy directly, but there's difficulty in this coordination.

A reasonless NACK, aka "simply returning the interest back to downstream without any modification", is insufficient in some scenarios.
Bug #1966 note-2 has an example.