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
- https://www.rfc-editor.org/rfc/rfc8609.html
- https://www.rfc-editor.org/rfc/rfc8569.html
- https://github.com/PARC/Athena/blob/f89da532c8690af88dfb81e708007022833625ca/ccnx/forwarder/athena/athena_PIT.c
Editorial evidence references
The following identifiers refer to research records not included in this public package; they are not public links.
- round434.html
- round245.html
- round391.html
- round400-common-scenario.json
- round400.html
- round433-model.json
- round433-sources.json
- round434-sources.json
- round434-model.json