Flooded Packet Fragment Tracking for Consistent Remote Databases

Resolve Bottlenecks,
Find Innovative SolutionsGenerate Solutions

Solution Overview

Problem

Networks face database inconsistencies due to the flooding of packet fragments independently, leading to issues like route flapping and traffic loss, as nodes may receive incomplete updates.

Innovation Solution

Implementing a system where nodes identify transaction identifiers and fragment identifiers in packet fragments, ensuring all fragments are received before updating the database to maintain database consistency.

Engineering Contradictions & Design Principles

VSEngineering Contradiction Analysis

1Productivity

If packet fragments are flooded independently without coordination, then network bandwidth utilization is improved and updates can be transmitted efficiently, but database consistency deteriorates as nodes may receive incomplete updates

Engineering Contradiction:

Improveupdate propagation efficiencyVSAvoiddatabase consistency

Core Design Contradiction:

ProductivityVSReliability

Solution Approach 1:

The update is divided into multiple packet fragments, each containing a portion of the update data. This segmentation allows the update to be transmitted in smaller units that can be efficiently flooded across the network while maintaining the ability to reconstruct the complete update when all fragments are received

Inventive Principle:

Principle #1Segmentation

Solution Approach 2:

The system implements a feedback mechanism where nodes track the receipt of packet fragments using sequence numbers and update identifiers. When a node receives fragments, it monitors for the complete set and only applies the update once all fragments are confirmed, preventing premature database updates that would cause inconsistency

Inventive Principle:

Principle #23Feedback

2Reliability

If nodes wait for complete packet fragments before updating, then database consistency is improved, but update application time increases

Engineering Contradiction:

Improvedatabase consistencyVSAvoidupdate application delay

Core Design Contradiction:

ReliabilityVSLoss of time

Solution Approach 1:

Nodes perform preliminary actions by pre-allocating buffer space and preparing update processing mechanisms before fragments arrive. This allows the system to immediately process and apply updates once all fragments are received, reducing the effective delay without compromising consistency

Inventive Principle:

Principle #10Preliminary action

Solution Approach 2:

The patent replaces the mechanical waiting process with an event-driven architecture using callbacks and asynchronous notification systems. When the final fragment is received, the system triggers an immediate update application through pre-configured event handlers, significantly reducing the perceived waiting time while maintaining the requirement for complete fragment reception

Inventive Principle:

Principle #28Mechanics substitution (Replace mechanical system)

3Device complexity

If packet fragments are transmitted without fragment identifiers, then packet structure simplicity is improved, but the ability to track and assemble complete updates deteriorates

Engineering Contradiction:

Improvepacket structure complexityVSAvoidfragment tracking information

Core Design Contradiction:

Device complexityVSLoss of information

Solution Approach 1:

The packet fragment structure uses multi-functional fields that serve multiple purposes: the update identifier tracks which database update the fragment belongs to, the sequence number indicates fragment order and completeness, and the payload contains the actual update data. This universal structure enables fragment tracking, assembly verification, and update application all within a single packet format

Inventive Principle:

Principle #6Universality (Multi-functionality)

Solution Approach 2:

The system dynamically adjusts packet fragment parameters based on network conditions and update size. Fragment identifiers and sequence numbers are included only when necessary (i.e., when updates are fragmented), and the packet structure adapts to include or exclude certain fields based on whether the update fits within a single packet, optimizing the balance between tracking capability and structural simplicity

Inventive Principle:

Principle #35Parameter changes

Data Source

PatentUS12411837B2Devices, systems, and methods for updating remote databases via flooded packet fragments

Publication Date: 2025.09.09 JUNIPER NETWORKS INC

AI summary

A disclosed computing device may include (1) a storage device configured to store a database that identifies states of nodes included in a network and (2) circuitry configured to (A) receive one or more packet fragments that account for at least one change made to a state of one of the nodes in a transaction, (B) identify, among the packet fragments, a transaction identifier corresponding to the transaction and an indication of a total number of packet fragments representing the transaction, and (C) update the database to account for the change upon ensuring receipt of all the packet fragments representing the transaction based at least in part on the transaction identifier and the indication. Various other devices, systems, and methods are also disclosed.