1.2.8 Retry Probing

Retry Probing is a feature that allows reconfirmation of the initial and already reconfirmed improvements validity.  The feature is applicable to all types of improvements made by the system (Performance, Cost and Commit Control improvements). The improvements that were made more than a retry probing period ago(core.improvements.ttl.retry_probe) are being sent to retry probing. If the probing results confirm that the current improvement is still valid, it stays in the system and its description is updated. Otherwise, it will be removed with the log message further described in this section.

During Retry Probing reconfirmation the improvement details will be updated in the following cases:

• Performance and Cost improvements

→  An old provider has been removed from the system configuration.
Example: “Old provider and performance metrics not known. New packet loss 55%, avg rtt 105 ms.”

• Commit Control improvements

→  An old provider’s has been removed from the system configuration.
Example: “Previous provider not known. Rerouted 1 Mbps to Peer5 [5] (250 Mbps, 50%)”
→  An old provider’s bandwidth statistics are not available.
Example: “Rerouted 6 Mbps from Peer1 1] to Peer5 5] (250 Mbps, 50%)”
→  A new provider’s bandwidth statistics are not available.
Example: “Rerouted 6 Mbps from Peer1 [1] (250 Mbps, 50%) to Peer5 [5]”
→  The old and new providers’ bandwidth statistics are not available.
Example: “Rerouted 6 Mbps from Peer1 [1] to Peer5 [5]“

Commit control improvements are reconfirmed based on their average bandwidth usage (and not on current bandwidth usage). This way if performance characteristics allow it, even when current bandwidth usage is low but the average is still relevant, the improvement is preserved thus anticipating network usage cycles and reducing number of route changes.