◇ OpenCyber Academy
Engineering · Chapter 1 · English

Chapter 1 — Calculus I

Open, free learning for anyone who wants to protect people and technology. No account is required to read this text or its worked answers.

Chapter 1 — Calculus I

Lesson map

Lesson 01 published. Map, example, EX001.

flowchart TD
  N0["Learning outcomes"]
  N1["1.1 Rates and accumulations in an engagement"]
  N2["1.2 Finding the peak"]
  N3["1.3 From total to schedule"]
  N4["Synthesis"]
  N0 --> N1 --> N2 --> N3 --> N4
  N4 --> EX["Worked example"]
  EX --> Q["Exercise EX001"]

Logical drawing

flowchart LR
  N0["Learning outcomes"]
  N1["1.1 Rates and accumulations in an engagement"]
  N2["1.2 Finding the peak"]
  N3["1.3 From total to schedule"]
  N4["Synthesis"]
  N0 --> N1 --> N2 --> N3 --> N4 --> Q["EX001"]
[Learning outcomes]
    |
    v
[1.1 Rates and accumulations in an engagement]
    |
    v
[1.2 Finding the peak]
    |
    v
[1.3 From total to schedule]
    |
    v
[Synthesis]
    |
    v
[Worked example] --> [Exercise EX001]

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

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 · Course chapter index · Chapter 02 (draft) →