-
Notifications
You must be signed in to change notification settings - Fork 2
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.
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
YS001: Yggdrasil Core Specification #1
base: master
Are you sure you want to change the base?
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I skimmed some parts so I don't know how much stuff I've missed. There goes some comments, though.
hops from the root node down to a given node. | ||
|
||
The root node sends a switch update message to all directly connected peers, | ||
containing a timestamp and its own signing key. The switch update message |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
is timestamp in unix epoch seconds? or maybe milliseconds?
does this mean that nodes need to have synchronized times, or this timestamp is not absolute but relative to node key of node which sends it?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Epoch seconds in practice but I that it just needs to be an increasing number so that an update doesn’t get replayed in the future. This section can definitely be made clearer.
from the sender's public encryption key in the protocol message headers matches | ||
the searched target Node ID (after applying a bitmask to account for any | ||
unknown bits of the Node ID). If it does, the search is considered to be | ||
completed and the node **should not** send any additional search requests |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
They're cached indefinitely? That doesn't sound too good, there should be limit of how long data is cached.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Review is outdated - which lines are you referring to exactly?
3. Continue through the bytes until the initial length value has been reached | ||
|
||
### Message types | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
When a socket connection is initialized with a link, a meta
message is exchanged.
Format of that message is
bytes
['m', 'e', 't', 'a']varu64
Major versionvaru64
Minor versionbytes
Encryption key (32 bytes)bytes
Signing key (32 bytes)bytes
Encryption key for this connection (32 bytes)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is deliberately not in the message types at the moment because it's not really a true protocol message — in our current implementation it is specific to TCP/TLS peerings. I am not sure if it is best to add a section specifically about TCP/TLS, or whether that should really be an extension spec.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Glad to see a document like this taking shape! I'm someone who isn't very familiar with how Yggdrasil works, but I thought giving some feedback to this doc from outsider or fresh perspective may be helpful.
must be specified and known. Byte arrays **must** only be variable-length if | ||
they are the last field in the message. | ||
|
||
#### Coordinates |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Maybe this section could briefly mention the purpose of coordinates. I'm not sure how a node's dynamic locator and coordinates are related based on what I've read here.
The routing scheme is name-independent - that is, that the permanent address of | ||
a given node is not permanently associated with the location of the node on the | ||
network. This allows a certain amount of node mobility without relying on | ||
subnet-based routing. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This section brought up two questions for me. I'm not sure if these questions should be answered in this document, but I'll leave them here in case others have an opinion:
- Node mobility is considered (which is awesome), but are there any known limitations in a node's ability to move and change their location within the network?
- How is the locator assignment related to a node's relative location to other nodes?
Yggdrasil is a greedy routing algorithm. All nodes on the network have the | ||
capacity to forward traffic on behalf of other nodes so long as doing so brings | ||
the traffic closer to the intended destination, using only local knowledge. In | ||
practice, only nodes that are directly connected to more than one peer will | ||
forward traffic on behalf of other nodes. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This section brings up the following questions (feel free to ignore if it isn't relevant):
- Is it possible to merge bandwidth from multiple connected peers in order to have increased bandwidth to some other node?
- How quickly can nodes discover and begin making use of a node connection? Would yggdrasil be suitable for a drone swarm, or an interconnected car network, for example?
Knowing the destination locator of the traffic in question, and the locators of | ||
all directly connected peers, a node can work out which egress peering will take | ||
the traffic closer to the intended destination. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If multiple nodes have a closer connection to a destination, then do nodes persist these possible routes to the destination? If so, then how are these routes prioritized, and how long are they persisted?
Coordinates are an ephemeral identifier which represent the switch's location on | ||
the network graph, relative to the root node. They are not a fixed value and can | ||
change at any time depending on the node's own peers, or changing connectivity | ||
on the path from the node up to the root node. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Maybe this definition of coordinates could be moved up to the Coordinates section starting at L177.
responsibility of an implementation to know the format for a defined message | ||
type and to be able to determine the end of a given field based on the | ||
characteristics of that field type. Further details on this are available in the | ||
base type definitions below. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is not a great design, because it prevents you from defining new packets in a backwards-compatible way.
Any news? It would be useful for everyone who wants to implement ygg router. |
This is the initial draft of the YS001 Yggdrasil Core Specification. It is still a work in progress.
Still to do:
... and probably a number of other things!