Project

General

Profile

Task #1722

FaceMgmt: query operation

Added by Alex Afanasyev over 7 years ago. Updated almost 7 years ago.

Status:
Closed
Priority:
Normal
Assignee:
Category:
Protocol
Target version:
Start date:
Due date:
% Done:

100%

Estimated time:
3.00 h

Description

In FaceMgmt, define a query operation, which takes a filter as an argument, and returns a StatusDataset that contains FaceStatus elements for faces that satisfies the filter.

The filter should support filtering on:

  • FaceId
  • underlying protocol (scheme part of local FaceUri)
  • remote FaceUri
  • local FaceUri
  • isMultiAccess

Each condition uses exact match; multiple conditions are combined by AND operator.


Related issues

Related to NFD - Task #1515: nfdc allows FaceUri in place of FaceIdClosedSyed Amin

Actions
Blocks NFD - Task #1993: Face query operationClosedChengyu Fan

Actions
#1

Updated by Alex Afanasyev over 7 years ago

  • Related to Task #1515: nfdc allows FaceUri in place of FaceId added
#2

Updated by Junxiao Shi over 7 years ago

  • Subject changed from Add support for "query" command into Face Management protocol to FaceMgmt: query operation
  • Description updated (diff)
  • Assignee set to Junxiao Shi
  • Start date deleted (07/01/2014)
  • Estimated time set to 3.00 h
#3

Updated by Junxiao Shi over 7 years ago

  • Status changed from New to In Progress
  • % Done changed from 0 to 10

I plan to design this protocol as:

  • Interest Name: /localhost/nfd/faces/query/<filter>
    • filter is a TLV block of conditions, such as: UnderlyingProtocol=udp AND isMultiAccess=false
    • UnderlyingProtocol condition is presented as the scheme name, "udp" means "udp4 OR udp6"
    • Conditions are concatenated with AND; an omitted condition means any
    • If filter is empty, this is equivalent to faces/list operation
  • Data Name: /localhost/nfd/faces/query/<filters>/<version>/<segment>

Please suggest.

#4

Updated by Alex Afanasyev over 7 years ago

Do we really need "query" operation be that complex? The only usage I know for now it to be used during "unregister" in nfdc. What's a point of this complexity?

#5

Updated by Junxiao Shi over 7 years ago

This filter will be useful:

  • nfdc operations can take all kinds of FaceUris with remoteUri and localUri conditions
  • a monitoring tool can retrieve the counters on a single face with FaceId condition; it's more efficient than requesting faces/list, when only one face is needed
  • ndn-autoconfig can use isMultiAccess condition to find out all multicast faces without filtering itself in faces/list
#6

Updated by Junxiao Shi over 7 years ago

20140718 conference call approves the proposal in note-3.

#7

Updated by Junxiao Shi over 7 years ago

  • Status changed from In Progress to Resolved
  • % Done changed from 10 to 70

Please review FaceMgmt revision 37.

#8

Updated by Alex Afanasyev about 7 years ago

IsMultiAccess? should probably replaced with Flags?. This would include ability to select multi-access links, but would also provide ability to select faces based on other flags.

#9

Updated by Junxiao Shi about 7 years ago

I thought about using Flags and defining isMultiAccess as a flag.

The problem is, the filter could specify one of the following for each flag:

  • 1
  • 0
  • don't care

With a single Flags field, there is only one bit per flag, and it's not possible to represent three possible values in one bit.

One option is to have a FlagsMask field in addition to Flags, but that's less understandable.

#10

Updated by Junxiao Shi about 7 years ago

20140818 conference call decides to eliminate FaceFlags field.

  • In FaceStatus block, FaceFlags field is replaced with three boolean fields.
  • In FaceQueryFilter block, presence of a boolean field indicates a condition, omission of a boolean field indicates "don't care".
#11

Updated by Junxiao Shi about 7 years ago

Please review FaceMgmt revision 39.

#12

Updated by Junxiao Shi about 7 years ago

  • % Done changed from 70 to 100

20140819 conference call reviews the document. Changes are made.

Another question I can think about is: Uri and LocalUri requires precise match:

FaceUri must precisely match what would appear in face dataset: use either "tcp4" or "tcp6" instead of "tcp", use IP address instead of DNS name, include port number

In order to benefit nfdc register /example udp://router.example.net command, nfdc would have to perform DNS resolution to convert hostname into IP addresses.

I'm not sure whether it's the right thing to do.

The alternate is to allow Uri and LocalUri conditions to contain any FaceUri.
NFD would have to resolve those FaceUris before determining whether a face can match the condition.

A further complication is: a hostname can be resolved to multiple IPv4 and IPv6 addresses; if we let NFD resolve FaceUris, a face that has any of those resolved addresses should match the condition.

#13

Updated by Junxiao Shi about 7 years ago

20140820 conference call approves the design for face query operation.

We have further decided that DNS resolution should not be performed within NFD.
Therefore, DNS names are not supported in face query operation.

DNS names are currently allowed in faces/create command, but it's not recommended.

#14

Updated by Junxiao Shi about 7 years ago

  • Status changed from Resolved to Closed
#15

Updated by Junxiao Shi almost 7 years ago

  • Status changed from Closed to Feedback

A question is raised during implementation:

If the <filter> in Interest Name is invalid (eg. non-parseable), what should the producer do?

My opinion is:

  • for v0.3, the producer should not respond.
    Remember that this is a StatusDataset. Unlike a ControlCommand, StatusDataset doesn't support negative response.
  • for future version, the producer should respond with a producer-generated NACK.
#16

Updated by Anonymous almost 7 years ago

How important is it for the response to be defined as a StatusDataset? Can we define a new protocol type (query) that uses unsigned requests?

I think not responding sets a bad precedent and I'm not sure a NACK would be the right thing either. If there's an error, then the response should be an error so that the application/user can correct the issue.

#17

Updated by Junxiao Shi almost 7 years ago

It's desirable to minimize the number of artifacts in a protocol.

What's wrong with responding with producer-generated NACK (suppose it's available in packet format)?

#18

Updated by Anonymous almost 7 years ago

My answer to this problem would have been an appropriate error control response if the protocol was not a StatusDataset. The query feels like a command: you're asking NFD to do something on your behalf (but it's not modifying its state).

I don't have a good answer for why not producer NACK so much as control response seems like the natural answer to me. This may be due to me not understanding the exact usage of the NACK in this scenario. If the NACK informs the sender there is a specific error rather than just a generic error state, then I guess it would be equivalent/better. I just want to make sure there is meaningful feedback.

Are you planning to change the error control responses for ControlCommand protocols to producer NACKs, too?

#19

Updated by Junxiao Shi almost 7 years ago

Producer generated NACK indicates the authentic non-existence of some Data.
The reason could be carried in the NACK packet.

ControlCommand shouldn't use producer generated NACK for most errors, because the error condition is due to some execution failure, not the non-existence of a command processor.

#20

Updated by Anonymous almost 7 years ago

Junxiao Shi wrote:
Producer generated NACK indicates the authentic non-existence of some Data.
The reason could be carried in the NACK packet.

Is the producer generated NACK just a "NACK" type field/flag in a Data packet? If so, would an acceptable temporary solution be to respond with a "normal" Data packet with the reason? The requester could identity the failure by recognizing that the response doesn't begin with a FaceStatus TLV and maybe some sanity checks on the message (ex: begins with "Error", null terminated, etc.).

#21

Updated by Junxiao Shi almost 7 years ago

I would split the implementation into two stages:

  1. don't respond
  2. respond with producer generated NACK

The second stage is blocked by ndn-cxx's support of producer generated NACK.

This could be included as an experimental feature in ndn-cxx without NDN-TLV spec update; an example of such an update is #2021.

It's NOT ACCEPTABLE to represent producer generated NACK with BLOB Data, because that sets a bad example.

#22

Updated by Junxiao Shi almost 7 years ago

#23

Updated by Alex Afanasyev almost 7 years ago

Why NACK is blocked? There is nothing that prevents us from creating a producer-generated NACK by assigning NACK code to MetaInfo.ContentType and leaving content empty. Wouldn't that be sufficient?

#24

Updated by Junxiao Shi almost 7 years ago

The only choices for ContentType are: BLOB, LINK, KEY.

Other codes are forbidden.

I'm fine with adding this as a protocol-violating experimental feature in ndn-cxx.
But the producer behavior in this case cannot be defined in NFD Management protocol; it is rather an implementation choice.

#25

Updated by Alex Afanasyev almost 7 years ago

Fine with me.

#26

Updated by Anonymous almost 7 years ago

+1 for experimenting with the NACK code in ndn-cxx.

To echo Alex's earlier question, what is blocking us from standardizing the producer NACK? Is there really much more to discuss for this specific NACK type or are we trying to hold off until we have all NACK related things decided?

#27

Updated by Junxiao Shi almost 7 years ago

  • Status changed from Feedback to Closed

Closing this Task because no change is needed here.

Please discuss producer generated NACK in Task #2111.

Also available in: Atom PDF