Back to matrix

G05-CX: Pending

Rationale

RFC 8569 supports hierarchical longest-prefix forwarding and a pending Interest table. This separates two scaling costs: aggregate producer prefix routes and outstanding request state, rather than a mandatory entry for every content name ever accessed. A candidate placement-aligned hierarchy can use the selected static FIB configuration and known names; it does not supply automatic global content discovery. The shared workload implies about 115.74 million originating accesses/second globally when spread evenly over a day. Pending-state accounting is per traversed forwarder: arrival rate multiplied by residence time and bytes/entry. At one million Interests/second, four seconds and an assumed 512 bytes per entry, it is 2.048 GB, excluding other state. Neither this illustrative rate nor the entry-size assumption is an executed implementation measurement. The pinned Athena candidate adds concrete qualifications to the round433 request-state model. athena.c creates the default PIT with capacity 100000. New-key admission checks entryTable size and invokes expired-entry purging only when that capacity has been reached. Thus expiration is not an independently scheduled reclamation event in this PIT source. A matched response removes the matched key from the hash, timeout and link-cleanup indexes. An Interest with a ContentObjectHashRestriction can add a second, nameless entry after the one capacity check. The threshold therefore is not a strict 100000-record allocation bound: with 99999 existing keys, a new named and distinct nameless key can bring the table to 100001. Each entry has six pointers plus separately owned message, key, bit-vector, timestamp and indexing objects. Six pointers are not the total entry memory footprint.

Assessment method

Source lifecycle/admission trace; analytical boundary cases, no execution

Source context

RFC-based round433 model and pinned Athena f89da532 source

Outstanding qualification

Keep G05-CX Pending. The rate-times-residence model remains an abstract active-request estimate; this candidate additionally requires index multiplicity, lazy reclamation, admission and heap allocation accounting. The 100001 case is a source-derived boundary calculation, not a reproduced fault, exploit or unbounded-memory claim. Distinct hash keys and spare allocation capacity are assumptions. No claim that this historical Athena revision implements the selected ECDSA profile completely: E03-CX remains independently Pending. No runtime capacity, global placement, cryptographic throughput or legitimate-service-under-attack result is inferred. These implementation details are not mandatory properties of all CCNx forwarders.

Public sources

Editorial evidence references

The following identifiers refer to research records not included in this public package; they are not public links.