NFD

LocalControlInfo contains FaceId which is ambiguous. It could mean:

• the FaceId on which this Interest / Data arrives in forwarder
• the FaceId of the source face in a packet sniffing session
• the FaceId through which this Interest should be sent out

FaceId shall be renamed IncomingFaceId for the first meaning.

Hmm.. I agree that there is ambiguity, but not sure that we need to define a separate type for faces.. May be there should be explicit type or description of the context (ControlType)?

Also. If we allow specifying faceid for outgoing interests, do we want to allow a list of faceIDs as well?

Alex Afanasyev wrote:

Also. If we allow specifying faceid for outgoing interests, do we want to allow a list of faceIDs as well?

Yes, to specify nexthops, a non-empty set of FaceIds should be supplied.

do we have the concept of direction here? i.e., for all the packets received from applications, the FaceId is interpreted as outgoing face, for all the packets received by application, the FaceId is interpreted as the arriving face. I did not quite understand "the source face in a packet sniffing session"? any more details?

Yingdi Yu wrote:

do we have the concept of direction here? i.e., for all the packets received from applications, the FaceId is interpreted as outgoing face, for all the packets received by application, the FaceId is interpreted as the arriving face. I did not quite understand "the source face in a packet sniffing session"? any more details?

Yes, FaceId can have three different semantics, so that it should be given better names for those purposes:

• IncomingFaceId indicates the Face on which this packet arrives at the local forwarder
• NextHopFaceId indicates an app-chosen nexthop of an Interest. This field can be repeated to specify multiple nexthops. These app-chosen nexthops is a suggestion to the strategy on the namespace; if the strategy supports this field, it will forward Interests according to this suggestion.
• SnifferSourceFaceId indicates the Face on which the captured packet is transmitted. A separate SnifferDirection field indicates the direction on which the captured packet is transmitted.

I'm leaving out specification for Sniffer, but keeping it general. I feel that in sniffer mode, the daemon may tell something else about the incoming packets, besides the FaceId.

Updated. I commented out the sniffer-related info and reserved TLV type code for it.

Comment on revision 12:

Add a section header for LocalControlHeader enabling protocol.

"the control header allows applications to request bypassing the Interest forwarding strategy by directly specify FaceId to which the Interest should be forwarded" is inaccurate, because NextHopFaceIds are passed to the effective strategy as a suggestion, and the Interest does not bypass the strategy.

I updated the document to revision 16 to make the enabling procedure more clear.