Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Updates for SVS v2 #14

Draft
wants to merge 3 commits into
base: main
Choose a base branch
from
Draft

Updates for SVS v2 #14

Show file tree
Hide file tree
Changes from 1 commit
Commits
Show all changes
3 commits
Select commit Hold shift + click to select a range
359208f
Updates for SVS v2
pulsejet Jan 9, 2024
49f9a24
Update for review
pulsejet Mar 8, 2024
a119667
Fix typos
pulsejet Mar 30, 2024
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
11 changes: 11 additions & 0 deletions PubSubSpec.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -92,6 +92,17 @@ The following well-known additional blocks are RECOMMENDED.
Timestamp = TimestampNameComponent
```

### Name Mapping Delivery Optimization

To optimize the delivery of mapping data, SVS-PS implementations MAY piggyback mapping data in the Sync Interest's Application Parameters. If present, the mapping data SHOULD be appended as a single block after the StateVector in the Application Parameters. The mapping data MUST be encoded as a TLV block of type `MappingData` as defined above.
pulsejet marked this conversation as resolved.
Show resolved Hide resolved

```
Sync Interest
Application Parameters: StateVector MappingData
```
pulsejet marked this conversation as resolved.
Show resolved Hide resolved

When this optimization is implemented, Mapping Data SHOULD be inserted in every outgoing Sync Interest sent as a result of new data production at the acting node. On receiving a Sync Interest, this mapping data can be utilized only after the Interest signature has been validated.
pulsejet marked this conversation as resolved.
Show resolved Hide resolved

## Subscribers

This section describes the functions performed at data subscribers.
Expand Down
10 changes: 7 additions & 3 deletions Specification.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -2,7 +2,7 @@

This page describes the protocol specification of [State Vector Sync (SVS)](/README.md).

_Last update to specification: 2021-12-15_
_Last update to specification: 2024-01-09_

## 1. Basic Protocol Design

Expand Down Expand Up @@ -40,9 +40,11 @@ seq=11 \

## 2. Format and Naming

**Sync Interest Format**: `/<group-prefix>/<state-vector>/<signature>`
**Sync Interest Format**: `/<group-prefix>/v=2/<signature>`
pulsejet marked this conversation as resolved.
Show resolved Hide resolved

A state vector is appended to the name in TLV format:
The State Vector is encoded in TLV format and included in the Application Parameters of the Sync Interest. The State Vector SHOULD be the first TLV block in the Application Parameters.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Under TLV evolvability guidelines, it's not good to enforce a particular TLV being the first one, without a strong technical reason.
It's better to accept any ordering, with a recommendation that StateVector appearing before MappingData.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

with a recommendation that StateVector appearing before MappingData

why the recommendation? unless a specific order is mandatory, a receiver cannot make any assumptions anyway, so why bother with a recommended order in the first place?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The recommended ordering improves Interest aggregation. It is not enforced.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm not sure interest aggregation is a concern here? it's a signed interest anyway...

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Signing with HMAC key and skipping all random fields in SigInfo => aggregation possible.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We're not debating whether it's possible or not, but whether it's a concern. I'm saying "why bother". Moreover, this may even be application dependent, and the order itself (even if just a recommendation) doesn't matter as long as it's consistent.

Copy link
Member

@Pesa Pesa Jan 13, 2024 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Just to be clear: I'm not against suggesting a specific order in SVS, I just don't think it's very useful or makes a meaningful difference in practice. A consistent order across all ApplicationParameters is more important.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't care honestly. But it's easier / better to recommend a order than recommending consistency for interoperability between vendors.


Application Paramters: StateVector
pulsejet marked this conversation as resolved.
Show resolved Hide resolved

Interest Lifetime: 1 second

Expand Down Expand Up @@ -101,7 +103,9 @@ When a node is in _Steady State_:
- Incoming Sync Interest is up-to-date or newer.
- No indication of inconsistencies. The scheduled Sync Interest can be delayed.
- Eventually update the local state and reset Sync Interest Timer to 30 seconds (±10% uniform)
- If the incoming Sync Interest has newer entries, store the current timestamp as the last update time for each updated node.
- Incoming Sync Interest is outdated: Node moves to _Suppression State_
- If every outdated node was updated within the last suppression period, drop the Sync Interest and move to _Steady State_
pulsejet marked this conversation as resolved.
Show resolved Hide resolved
- Set Sync Interest Timer to 200ms (±50% uniform) - Time represents the suppression interval
- Aggregate the state of consequent incoming Sync Interests in a separate state vector
- On expiration of timer:
Expand Down