Task #4734
closed
Redefine Notification Stream procedures without ChildSelector
Added by Junxiao Shi about 6 years ago.
Updated about 6 years ago.
Description
NFD Management protocol's Notification Stream mechanism currently requires the use of deprecated ChildSelector. It should be redefined without using ChildSelector and Exclude.
This issue is protocol definition only. Implementation is in #4664.
- Blocks Bug #4664: NotificationSubscriber uses ChildSelector added
- Status changed from New to In Progress
- Assignee set to Junxiao Shi
- % Done changed from 0 to 10
Notification rev7 gives two subscriber workflows. First workflow requires "ChildSelector=rightmost Exclude=any,last-know-seq-num" in every Interest. Second workflow requires "ChildSelector=rightmost MustBeFresh=yes" in first Interest, and uses incrementing sequence numbers in subsequent Interests.
I think the most straightforward solution is:
- Subscriber sends CanBePrefix=yes MustBeFresh=yes for the first Interest, and uses incrementing sequence numbers in subsequent Interests.
- Publisher sets minimum FreshnessPeriod.
While RDR protocol (#4706) is attractive, it's overkill for Notification Stream. RDR allows high FreshnessPeriod on application Data, and uses a short-lived metadata packet to inform consumers what's the latest application Data. NFD Management's notifications are short-lived and there's no benefit in setting high FreshnessPeriod on notifications, and therefore subscribers can directly retrieve notifications in the same way they retrieve RDR metadata.
PSync is another possible solution, but it's also overkill for Notification Stream. PSync allows subscribers to get updates about multiple data streams, while NFD Management only has a handful of notification streams, so it's not worth the overhead of adopting PSync.
20180926 call approves note-2 design.
- Tags set to Packet03Transition
- Status changed from In Progress to Resolved
- % Done changed from 10 to 100
- Status changed from Resolved to Closed
Also available in: Atom
PDF