## Chapter 1 — Calculus I ### Learning outcomes You will (1) model a cumulative quantity in an assessment as an integral of a rate; (2) use a derivative to find when a rate peaks; (3) turn both into a rate limit Sam Ito can defend in the rules of engagement (ROE). ### 1.1 Rates and accumulations in an engagement Every authorized test produces traffic, and the client cares about two things: how fast it arrives and how much accumulates. If an enumeration job sends requests at rate r(t) requests per second, the total sent between times a and b is the integral ∫ r(t) dt from a to b. A ROE that says "no more than 5 requests per second" limits r(t); one that says "no more than 20,000 requests per day against the ticketing API" limits the integral. They are different constraints and a schedule can satisfy one while breaking the other. ### 1.2 Finding the peak Suppose TrackScope ramps a scan up and then down, with r(t) = 6t − t² requests per second for 0 ≤ t ≤ 6 minutes (t in minutes, synthetic). The derivative r′(t) = 6 − 2t is zero at t = 3, where r(3) = 9 requests per second. If the ROE ceiling is 5 per second, this schedule breaches it between the two roots of 6t − t² = 5, that is t = 1 and t = 5 minutes. Calculus tells you not just *whether* a plan breaks the limit but *for how long*, which is what the client's operations team asks first. ### 1.3 From total to schedule The total for that ramp is ∫₀⁶ (6t − t²) dt = [3t² − t³/3]₀⁶ = 108 − 72 = 36 request-minutes per second, i.e. 36 × 60 = 2,160 requests. A flat schedule at 5 per second would need 2,160 / 5 = 432 seconds, 7.2 minutes, to send the same volume without any breach. Engineers prefer the flat schedule because its peak equals its average and is trivial to verify from logs. > **Synthetic case — Riverstone Transit.** Sam's draft ramp for the fare-gateway test peaked at 9 req/s; the ROE allowed 5. Sam replaced it with a 5 req/s token bucket (see Chapter 36) and attached the integral calculation to the change request. ### 1.4 Errors and limits Real traffic is bursty, not smooth; a continuous model gives an average-case picture, and the ROE limit must be enforced by a mechanism, not by the calculation. Units cause most mistakes: keep seconds and minutes separate. Enforcement belongs in the scanner configuration and in a network rate limiter the client can see, so a mistake in the schedule cannot silently exceed the agreed limit. When converting between minutes and seconds, write the units next to every number and check the final figure against a rough estimate. Burstiness means a short spike can break a per-second limit even when the hourly average is fine, so Sam Ito sets both a short-window and a long-window ceiling in the ROE and tests them before the engagement starts. ### Exercises - **EX001 — Breach window.** For r(t) = 8t − t² req/s (t in minutes, 0–8) and a ceiling of 7 req/s, find the peak and the interval during which the ceiling is breached. Rubric: 3 = peak 16 at t=4 and breach between t=1 and t=7 (6 minutes); 2 = one slip; 1 = peak only; 0 = none. - **EX002 — Two kinds of limit.** Give one ROE clause that limits a rate and one that limits a total, for the same API, and say which one a log-based check verifies more easily. Rubric: 3 = both clauses with units and justified answer; 2 = clauses without justification; 1 = one clause; 0 = none. - **EX003 — Flat equivalent.** How long does a flat 4 req/s schedule take to send the 2,160 requests of §1.3? Rubric: 3 = 540 s (9 minutes) with working; 2 = right number, no units; 1 = method only; 0 = none. ### Synthesis A rate limit and a volume limit are a derivative and an integral of the same curve. Checking both turns a vague promise of "low impact" into numbers the client can audit. ### Continue studying — chapter 01 of 50 [← Course home](../../README.md) · [Course chapter index](../SUBJECTS.md) · [Chapter 02 (draft) →](#ch-02) ## Worked answers **EX001.** r′(t) = 8 − 2t = 0 at t = 4, so the peak is r(4) = 32 − 16 = 16 req/s. Solving 8t − t² = 7 gives t² − 8t + 7 = 0, t = 1 or t = 7. The ceiling is breached from minute 1 to minute 7, six minutes. Score 3 needs both the peak and the window. **EX002.** Rate: "No more than 5 requests per second to /api/tickets from the assessment source address." Total: "No more than 20,000 requests per calendar day to /api/tickets." The total is easier to verify from logs (a single count per day); the rate needs per-second bucketing and a tolerance for clock skew. **EX003.** 2,160 / 4 = 540 seconds = 9 minutes. The flat schedule is longer than the 6-minute ramp but never exceeds the ceiling.