Task #1722
closedFaceMgmt: query operation
100%
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.
Updated by Alex Afanasyev over 10 years ago
- Related to Task #1515: nfdc allows FaceUri in place of FaceId added
Updated by Junxiao Shi over 10 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
Updated by Junxiao Shi over 10 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.
Updated by Alex Afanasyev over 10 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?
Updated by Junxiao Shi over 10 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 infaces/list
Updated by Junxiao Shi over 10 years ago
20140718 conference call approves the proposal in note-3.
Updated by Junxiao Shi over 10 years ago
- Status changed from In Progress to Resolved
- % Done changed from 10 to 70
Please review FaceMgmt revision 37.
Updated by Alex Afanasyev over 10 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.
Updated by Junxiao Shi over 10 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.
Updated by Junxiao Shi about 10 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".
Updated by Junxiao Shi about 10 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.
Updated by Junxiao Shi about 10 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.
Updated by Junxiao Shi about 10 years ago
- Status changed from Resolved to Closed
Updated by Junxiao Shi about 10 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.
Updated by Anonymous about 10 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.
Updated by Junxiao Shi about 10 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)?
Updated by Anonymous about 10 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?
Updated by Junxiao Shi about 10 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.
Updated by Anonymous about 10 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.).
Updated by Junxiao Shi about 10 years ago
I would split the implementation into two stages:
- don't respond
- 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.
Updated by Junxiao Shi about 10 years ago
- Blocks Task #1993: Face query operation added
Updated by Alex Afanasyev about 10 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?
Updated by Junxiao Shi about 10 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.
Updated by Anonymous about 10 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?
Updated by Junxiao Shi about 10 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.