Skip to content

Rewrite coords en-route instead of dropping packets due to coord change #353

Open
@Arceliar

Description

@Arceliar

Documenting my late night epiphany here on the off chance that I have an aneurysm in my sleep or something and don't get to write this myself.

Suppose A send a packet to B. Before the packet gets to be (possibly before A sends it), B changes coords. The packet will tend to route until it reaches some last common ancestor L between B's old coords and B's new coords. This could be B's old parent, or a parent of a parent if a change happened upstream, etc...

Now, currently, as soon as a packet hits L, L will see that there's no closer next-hop and drop the packet. But we can do better! L can see that the last common ancestor between itself and the destination is itself, so it knows that the packet reached the stage where it's routing on the tree. This means the next port number after the end of its own coords is a peer that used to be a child, but switched to another parent. So L can check what peer it has associated with that port, and if one exists (i.e. peer didn't drop offline entirely), then L could rewrite the part of the destination coords that match L's own coords with the coords of the new parent of L's former child, and then process the packet again. Now the packet will be forwarded to the correct peer. That peer may need to do run through the same procedure (it is now L in the above example, but the rest of the story is the same). I think this should be loop-free, but I'm too tired/half-asleep to say that with certainty. Something to note: reaching L may involve routing up the tree more than necessary, but L was going to get it anyway, and then routing back down the tree from L to the destination is (or was, presumably) the best path to take, otherwise the destination wouldn't have chosen L as an ancestor in the first place.

Doing this would mean that packets can still reach their destination after a node changes coords, as long as the old path still exists and the root has not changed. We could then be more aggressive about changing coords, which would help the network converge faster (this could be important for mobile nodes).

We would probably want to somehow signal to the receiver that coords were mutated, to make sure they know to send a session ping and fix the coords on the remote side. That could be done by either attaching some magic to the dead space at the end of the coords, or (better yet) adding new packet types that work just like (protocol)traffic but have a different ID number on the wire. Or have nodes just be more pro-active about sending their true coords to the other node in a session (e.g. send the occasional session ping in the background when sending traffic, instead of only doing so if the other side hasn't responded recently). We may want to consider more aggressive pings/searches anyway in the future (and/or improve things about how they work), since that's another place where things need to update quickly for mobility to work well. Tagging philosophical because I'm not sure what approach makes sense for this part.

Metadata

Metadata

Assignees

Labels

enhancementEnhances/improves functionality or UXfeature requestRequest for a new feature or changephilosophicalFor consideration, not a pressing issue

Type

No type

Projects

No projects

Relationships

None yet

Development

No branches or pull requests

Issue actions