Project

General

Profile

Task #1731

Interest NACK

Added by Junxiao Shi about 5 years ago. Updated about 4 years ago.

Status:
Abandoned
Priority:
Normal
Assignee:
Start date:
Due date:
% Done:

30%

Estimated time:

Description

Define the packet format for Interest NACK.

Interest NACK, aka "negative acknowledgement", is sent from upstream to downstream to inform that Data could not be retrieved in response to an Interest.
It contains the Interest packet that triggered this NACK, and a reason code.
Commonly used reason codes include Duplicate, Congestion, NoData.

The semantics of Interest NACK is described in A case for stateful forwarding plane.

nack_20140718.pptx (54.8 KB) nack_20140718.pptx Junxiao Shi, 07/18/2014 02:01 AM
nack_20140727.pptx (67 KB) nack_20140727.pptx Junxiao Shi, 07/27/2014 11:22 PM
nack_20140731.pptx (80.9 KB) nack_20140731.pptx Junxiao Shi, 07/31/2014 03:17 PM

History

#1 Updated by Junxiao Shi about 5 years ago

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.

#2 Updated by Junxiao Shi about 5 years ago

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.

#3 Updated by Junxiao Shi almost 5 years ago

I've written the straw man design as attached slides.

#4 Updated by Alex Afanasyev almost 5 years ago

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?
  • ?

#5 Updated by Junxiao Shi almost 5 years ago

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.

#6 Updated by Junxiao Shi almost 5 years ago

Proposal is updated with alternative designs, as suggested by Beichuan.

#7 Updated by Lan Wang almost 5 years ago

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.

#8 Updated by Lan Wang almost 5 years ago

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.

#9 Updated by Junxiao Shi almost 5 years ago

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").

#10 Updated by Junxiao Shi almost 5 years ago

20140731 conference call reviewed 20140727 slides.
Corrections are made.

Points that I don't fully agree or need further discussion are enclosed in callout blocks.

#11 Updated by Lan Wang almost 5 years ago

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.

#12 Updated by Junxiao Shi almost 5 years ago

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.

#13 Updated by Lixia Zhang almost 5 years ago

#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.

#14 Updated by Junxiao Shi almost 5 years ago

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.

#15 Updated by Junxiao Shi almost 5 years ago

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.

#16 Updated by Junxiao Shi about 4 years ago

  • Status changed from In Progress to Abandoned

As decided in 20150213 conference call, Interest NACK should not be a network layer packet type. Instead, it is carried in a hop-by-hop header to be designed in #2520.

Also available in: Atom PDF