=== ppt/slides/slide1.xml === Post-quantum TLS acceleration | Experiment plan, methodology, and measurement set | Isolating the contribution of Intel QAT, AVX-512, and GPU batching to TLS 1.3 handshake rate and bulk throughput | Draft 2026-08-18 === ppt/slides/slide2.xml === What the experiment must answer | Each question maps to exactly one pair of arms differing by one variable | 1 | Transition cost | What does hybrid post-quantum TLS cost per core against a classical TLS 1.3 baseline, in handshakes per second and in cycles per handshake? | 2 | QAT recovery | Intel QAT accelerates only the classical leg of a hybrid handshake. How much of the transition cost does that offload recover? | 3 | AVX-512 uplift | What do AVX-512 optimised ML-KEM and ML-DSA kernels add over a generic build of the same primitives? | 4 | GPU batching | Does batched ML-KEM and ML-DSA on the GPU beat AVX-512 once queueing latency is charged to the p99? | Every arm SHOULD be reducible to one of these four questions. An arm that answers none of them SHOULD be cut from the matrix. === ppt/slides/slide3.xml === Configuration matrix | Five arms. Adjacent arms differ by one controlled variable | Arm | Key exchange | Authentication | Intel QAT | PQC engine | A1 | X25519 | RSA-3072 and ECDSA P-256 | Enabled | not applicable | B1 | X25519MLKEM768 | RSA-3072 and ECDSA P-256 | Disabled | CPU, AVX-512 | B2 | X25519MLKEM768 | RSA-3072 and ECDSA P-256 | Enabled | CPU, AVX-512 | C1 | ML-KEM-768 only | ML-DSA-65 chain | Disabled | CPU, AVX-512 | D1 | X25519MLKEM768 | RSA-3072 and ECDSA P-256 | Enabled | GPU, batched | A1 to B2 | Transition cost of hybrid PQC with the accelerator already engaged | B1 to B2 | QAT contribution in isolation. Identical cryptography, offload toggled | B2 to C1 | Cost of removing the classical leg entirely, which also removes all QAT work | B2 to D1 | GPU contribution in isolation. Identical cryptography, PQC engine swapped | Hybrid signature schemes remain IETF drafts, so each arm records its certificate chain construction explicitly rather than assuming a composite certificate. === ppt/slides/slide4.xml === Where the work actually lands | The accelerator has no lattice datapath, so the split is fixed before any tuning begins | Fixed by architecture | The accelerator public-key unit performs modular arithmetic on large integers, which covers RSA, ECDH and ECDSA | ML-KEM and ML-DSA need small-modulus number theoretic transforms and Keccak sampling, which that unit cannot express | Post-quantum operations therefore stay on the core, or move to the GPU, in every arm | Offload also has to earn its transport cost, and the lattice operations are too cheap for it to do so | Arms B1 and B2 differ only in whether the classical leg is offloaded, which is what makes the pair interpretable. === ppt/slides/slide5.xml === System under test | Every version and firmware setting is recorded per run, not per campaign | Platform | Xeon 6 SoC with integrated QAT, model and stepping | Core count, SMT state | Turbo policy and any frequency pin | C-state and P-state governor | Hardware prefetcher settings | NUMA node count and snoop mode | DDR5 population and speed | NIC model, port count, link rate | PCIe generation and lane width per device | RTX 6000 Pro, slot and root complex | Software stack | Distribution and kernel build | Intel QAT out-of-tree driver version | QAT device configuration file in use | QAT_Engine build, provider mode | OpenSSL version and provider list | liboqs version, minimum 0.14.0 | oqs-provider version | NGINX version and worker model | cuPQC and CUDA driver versions | Load generator build and version | Fixed controls | TLS 1.3 only, one cipher suite | Session resumption and tickets off | OCSP stapling off | HTTP keep-alive off for handshake runs | Identical certificate key sizes across arms | Interrupt affinity and RPS map pinned | Firewall and conntrack disabled on path | Same client fleet for every arm | Ambient inlet temperature logged | Idle baseline captured before each arm | A run whose manifest is incomplete is discarded rather than corrected after the fact. Firmware and driver revisions are captured by script, not by hand. === ppt/slides/slide6.xml === Workloads | Three workloads. Handshake rate is the primary, the other two guard against a misleading headline | W1 | Handshake rate | Full TLS 1.3 handshakes with no application payload. Resumption disabled so every connection pays the asymmetric cost. Reported as connections per second per core, then per socket. | Primary metric for arms A1, B1, B2, C1 | W2 | Bulk throughput | Repeated GET of a 10 MB object over established sessions. Exercises the record layer and AES-256-GCM rather than the key exchange. | Detects whether an arm trades handshake gain for record-layer loss | W3 | Handshake latency | Sequential single-connection handshakes at low concurrency, then at target concurrency. Full distribution, not an average. | The only workload that exposes GPU batching cost in arm D1 === ppt/slides/slide7.xml === Run protocol | The procedure is fixed before the first measurement and does not change mid-campaign | 1 | Warm up | 30 seconds of load discarded before any counter is read. Accelerator rings and page cache MUST be warm. | 2 | Measure | 300 seconds of steady-state load per run. Telemetry collection starts before load and stops after it. | 3 | Repeat | Five runs per arm. Report median with interquartile spread. Never report a single best run. | 4 | Randomise | Arm order is shuffled across repetitions so thermal drift does not correlate with arm identity. | 5 | Restart | Service and driver state reset between arms. Confirm the idle baseline returns before the next run. | 6 | Prove headroom | Client fleet doubled on one run per arm. If the result moves, the client was the bottleneck and the run is void. === ppt/slides/slide8.xml === Cryptographic metrics | Recorded at both the connection level and the primitive level so results can be attributed | Connection level | Connections per second, per core and per socket. | Handshake latency at p50, p95, p99, p99.9. | Bulk throughput in Gbps and Gbps per core. | Failed and renegotiated handshake count. | Bytes on the wire per handshake, by flight. | TCP segments and retransmissions per handshake. | Primitive level | ML-KEM-768 keygen, encapsulate, decapsulate. | ML-DSA-65 keygen, sign, verify. | ML-DSA sign rejection-loop iteration count. | RSA-3072 sign and verify. | X25519 and P-256 ECDH. | AES-256-GCM at 1 KB, 8 KB, 64 KB records. | Primitive costs are captured on the same host, in the same session, as the connection-level run | openssl speed -provider oqsprovider -kem-algorithms | openssl speed -provider oqsprovider -signature-algorithms | openssl speed -provider qatprovider -async_jobs 72 rsa3072 ecdsap256 | openssl speed -evp aes-256-gcm -bytes 1024,8192,65536 | openssl s_time -connect $DUT:443 -new -time 300 -verify 0 -groups X25519MLKEM768 | Primitive results are the consistency check on the connection-level results. A handshake rate that cannot be reconstructed from the primitive costs plus protocol overhead indicates a measurement fault. === ppt/slides/slide9.xml === CPU and memory telemetry | Cycles per handshake is the comparable unit across arms. Everything here feeds it or explains it | Core utilisation | Per-core busy percentage, user against kernel split, softirq and system time, context switches and involuntary migrations. | Execution efficiency | Instructions per cycle, retired instructions per handshake, branch mispredict rate, front-end and back-end stall breakdown. | Achieved frequency | Actual core frequency under load, not the nameplate. Turbo licence level residency, since heavy AVX-512 use lowers the licence and the clock. | Cache and memory | L1, L2 and last-level cache miss rates, memory read and write bandwidth, DRAM latency under load, page faults. | Power and thermals | Package and core RAPL energy, DRAM energy, package temperature, any thermal or power throttle event count. | NUMA behaviour | Remote memory access ratio, cross-socket traffic, worker to NIC queue locality. === ppt/slides/slide10.xml === Accelerator and interconnect telemetry | Without these counters an offload run cannot be distinguished from a software fallback | Intel QAT | Requests submitted and completed per second per engine. Ring depth and occupancy. Submission retries and ring-full events. Polling against interrupt mode. Per-service breakdown for asymmetric, symmetric, and compression. Firmware counter deltas from device debug interfaces. | PCIe and fabric | Read and write bandwidth per device per direction. Transaction rate and average payload size. Completion latency. Any correctable error counter movement during a run. | GPU, arm D1 only | Streaming multiprocessor occupancy and kernel duration. Effective batch size actually dispatched against the configured maximum. Host to device and device to host copy volume. Submission queue depth and time spent waiting to fill a batch. Board power and memory clock. | Network path | Packets and bytes per second per queue. Interrupt rate per core. Receive queue drops. Segments per handshake, which rises sharply once post-quantum certificates fragment across frames. === ppt/slides/slide11.xml === One handshake, five instrumented layers | A regression is only attributable if the same request is observable at every layer it touches | Application | Handshake outcome, latency, connection count | Core | Cycles, instructions per cycle, achieved frequency, cache behaviour | Uncore | Memory bandwidth, last-level cache traffic, cross-socket transfer | PCIe | Payload volume and completion latency per direction | Device | Accelerator ring occupancy, or GPU kernel duration and batch fill | A counter that cannot be joined to a specific run and a specific layer is telemetry that will not survive review. === ppt/slides/slide12.xml === Collection tooling and sampling | One NTP-synchronised clock. Every sample tagged with the run identifier | Tool | Captures | Interval | Runs on | perf stat, emon | Core counters, IPC, cache, stall breakdown | 1 s | Every run | turbostat | Achieved frequency, C-state residency, RAPL energy | 1 s | Every run | pcm, pcm-memory, pcm-pcie | Uncore, memory bandwidth, PCIe traffic | 1 s | Every run | mpstat, sar, /proc/interrupts | Per-core utilisation, softirq, interrupt distribution | 1 s | Every run | QAT device debug counters | Ring occupancy, request rate, retries | 5 s | QAT arms | nvidia-smi dmon, DCGM | GPU occupancy, power, copy volume, queue depth | 1 s | Arm D1 | Load generator logs | Connections per second, latency histogram, errors | 1 s | Every run | perf record with call graph | Hotspot attribution and symbol-level cost | one run per arm | Profiling pass only | Sampling overhead is measured, not assumed. One arm is repeated with collection disabled; if handshake rate moves by more than two percent, the sampling interval is relaxed and the campaign restarts. === ppt/slides/slide13.xml === Derived metrics and analysis | The raw counters are inputs. These are the numbers that answer the four questions | Derived metric | Definition | Answers | Cycles per handshake | Achieved frequency times active cores times busy fraction, divided by connections per second | Cross-arm comparison free of clock effects | Post-quantum tax | One minus the ratio of arm B2 to arm A1 handshake rate | Question 1, transition cost | QAT recovery ratio | Gain from B1 to B2 divided by the loss from A1 to B1 | Question 2, offload contribution | Kernel uplift | Handshake rate with optimised liboqs against a generic build of the same version | Question 3, AVX-512 contribution | Batch efficiency | Effective GPU batch size plotted against added p99 handshake latency | Question 4, GPU viability | Offload fidelity | QAT asymmetric operations per second divided by handshakes per second | Detects silent fallback to software | Handshakes per watt | Connections per second divided by package plus board power | Deployment economics | Bytes and segments per handshake | Wire volume and frame count per completed handshake | Explains loss on constrained paths | Offload fidelity has an expected value derived from the protocol, so a measured value below it is a defect in the configuration rather than a result about the hardware. === ppt/slides/slide14.xml === Validity controls | Each of these has silently invalidated a published acceleration result. All are checked per run | ✓ | Offload actually engaged | Accelerator request counters MUST increment in proportion to handshake count. A flat ring is a software run wearing the wrong label. | ✓ | No silent provider fallback | A missing algorithm in the selected provider MUST fail the handshake, not degrade to a default implementation. Verified by deliberately breaking one arm. | ✓ | Optimised kernels present | The post-quantum library build is confirmed to contain the vectorised code paths. A generic build understates the result and looks like a hardware finding. | ✓ | Client is not the limit | Doubling client capacity MUST not change the measured rate. Applies to every arm, not just the fastest. | ✓ | Frequency held constant | Achieved clock is compared across arms before any rate is compared. A frequency difference is reported separately, never folded into the result. | ✓ | Distributions, not means | Signature generation has a variable-iteration loop and GPU batching adds queueing, so both are reported as percentiles. === ppt/slides/slide15.xml === The GPU arm is a latency experiment | Throughput on the accelerator is not the question. The queue in front of it is | What arm D1 measures | Batched lattice operations only reach their published rates at large batch sizes | A TLS terminator must therefore hold connections in a queue until a batch fills | That wait is charged to first-byte latency, which is the one number a handshake exists to minimise | So the deliverable is a curve of batch size against p99 latency, not a single throughput figure | The arm passes only if a batch size exists where throughput rises and p99 does not | Report D1 separately from the CPU arms. It changes the latency contract, so it is not comparable on handshake rate alone. === ppt/slides/slide16.xml === Published anchors for sanity checking | Vendor figures used only as order-of-magnitude checks. Every arm is measured independently | 15% and 21% | Reported cost of moving to hybrid post-quantum key exchange against a classical baseline, for RSA and for ECDSA P-256 respectively, on a Xeon 6 SoC | Intel, 2025 | 2,926 | Full post-quantum TLS handshakes per second on a single core with the highest parameter set, ML-DSA-87 with ML-KEM-1024 | Intel, 2025 | 9.0 million | Batched ML-KEM-768 encapsulations per second on a datacentre GPU, against roughly ninety thousand on one CPU core | NVIDIA, cuPQC-PK | If a measured arm lands far from the matching anchor, the configuration is investigated before the result is written up. Anchors are not targets and are never quoted as our own findings. === ppt/slides/slide17.xml === Companion demo | A browser page that makes the work split visible and the cost model editable | 1 | Shows the split | Steps through one server-side handshake and marks which engine performs each operation, for any of the five arms. | 2 | Makes the model explicit | Every per-operation cost is an editable field. Handshake rate, cycles per handshake and latency recompute on each edit. | 3 | Separates core from device time | Offloaded work is shown as device time, so the accelerator gain is visible as reclaimed core time rather than as magic. | 4 | Frames the GPU trade | Batch fill wait is a first-class input, so the latency cost of batching appears next to the throughput gain. | The demo ships with placeholder costs and says so on screen. Its purpose is to hold measured values once phase P1 produces them, so it MUST NOT be presented as a source of results. === ppt/slides/slide18.xml === Demo, visual design | Dark instrumentation surface, hairline rules, gradient reserved for data | Design rules | Square corners and hairline rules, no card shadows | Gradient carries data only, never decoration | One numeral per metric panel, unit set beside it | Sequence view reads top to bottom, one row per step | Colour is always paired with a shape so it is never the only cue | Monospace for every figure so columns align === ppt/slides/slide19.xml === Demo, layout and accessibility | Conformance target is WCAG 2.2 level AA | Configuration tabs, A1 to D1 | Single tablist, arrow-key traversal, one arm selected at a time | Playback: play, step, reset | Motion is pausable and steppable | Speed control | Labelled range input, value echoed as text | Handshake sequence view | One row per step. Engine marked by both colour and shape: square for the accelerator, circle for the core, diamond for the GPU. Row label states the operation in words. | Modelled result | Handshake rate, core time, cycles, latency, device time, rate per watt. Live region announces changes politely. | Per-step table and editable cost model | Every figure in the graphics is also present as text in a table with row and column headers | Accessibility requirements | Text contrast at least 4.5 to 1, interface boundaries and graphics at least 3 to 1 | Every control reachable and operable by keyboard, with a visible focus indicator | Animation can be paused, and honours the reduced-motion preference | Interactive targets at least 24 by 24 pixels | Meaning never carried by colour alone: each engine also has a distinct shape and a text label | Every graphic has a text alternative, and every chart is duplicated as a data table | All inputs have persistent visible labels, grouped under a legend | Layout reflows to a single column without loss of content or function | Conformance is verified before the demo is shared, not after. === ppt/slides/slide20.xml === Demo, cost model inputs | Placeholder values, shipped to be overwritten by phase P1 measurements | Input | Engine | Placeholder | Replaced by | Parse ClientHello and transcript | Core | 8 µs | Profiling pass | X25519 ECDH | Core | 45 µs | openssl speed, ecdhx25519 | X25519 ECDH, offloaded | Accelerator | 6 µs core, 30 µs device | Accelerator counters plus openssl speed | ML-KEM-768 encapsulate | Core, AVX-512 | 12 µs | openssl speed, kem algorithms | ML-KEM-768 encapsulate | GPU, batched | 3 µs core, 8 µs device | GPU kernel duration | RSA-3072 sign | Core | 1300 µs | openssl speed, rsa3072 | RSA-3072 sign, offloaded | Accelerator | 20 µs core, 420 µs device | Accelerator counters plus openssl speed | ML-DSA-65 sign | Core, AVX-512 | 180 µs | openssl speed, signature algorithms | GPU batch fill wait | Queue | 120 µs | Batch size against latency sweep | Core frequency and power per core | Platform | 2.4 GHz, 6.5 W | turbostat during a measured run | Handshake rate is derived, never entered. Core time per handshake is summed from these inputs, so any figure the demo reports can be traced back to a measurement or to a placeholder. === ppt/slides/slide21.xml === Phases and deliverables | Instrumentation is validated before any comparative number is produced | 0 | Bring-up | Stack installed and version-pinned. Telemetry pipeline validated against a known load. Sampling overhead quantified. Idle baseline captured. | 1 | Primitives | Per-operation costs for every algorithm in the matrix, on the target host. Establishes the floor that connection-level results must be consistent with. | 2 | Handshake and bulk | Arms A1, B1, B2 and C1 across all three workloads. Single core first, then socket scale-out. | 3 | GPU arm | Arm D1 plus the batch size against latency sweep. Reported separately because it changes the latency contract. | Deliverables | Run manifest per run, capturing every version and firmware setting | Raw telemetry in a columnar store, one row per sample per counter | Primitive cost table for the target host | Per-arm results with median and interquartile spread | Derived metric notebook, reproducible from raw data | Two-page findings memo with the four questions answered | Companion demo page, cost model loaded with measured values | A result without its run manifest is not a result and is not reported.