Lease Renewal¶
Protocol — instantiates Threshold-Refresh State Maintenance
Holds a resource under a time-bounded grant that is automatically revoked unless the holder renews it before the term expires.
A lease is a grant with an expiry stamped on it: the holder may use the resource — an IP address, a lock, a leadership role — but only until the term runs out, and only if it keeps renewing. Lease Renewal is the protocol of extending that term before it lapses. What makes it this mechanism and not a generic refresh is the contract underneath it: an authoritative grantor, an owner who holds the grant, and a default of revocation on lapse. If the renewal doesn't arrive in time, the resource isn't merely stale — it is taken back and handed to someone else. The state is kept alive not by anyone remembering to touch it, but by an expiry that will reclaim it unless actively pushed back.
Example¶
A laptop joins a network and is granted a DHCP address for a lease of, say, ≈24 hours (a real protocol, RFC 2131). It does not wait for the clock to run out. At the halfway point of the term (T1, defined as 50% of the lease) it unicasts a renewal request to the server that granted the address, asking to extend the term. If that server is unreachable, at ~87.5% of the term (T2) it broadcasts to any server that will renew it. If nothing renews the lease before expiry, the laptop must stop using the address entirely and re-acquire one from scratch — and the freed address returns to the pool for another device.
The outcome is a resource that is self-cleaning: an address held by a machine that crashed or wandered off is reclaimed automatically, with no central janitor scanning for dead holders. The expiry does the reclaiming; the holder's job is only to keep renewing while it still wants the grant.
How it works¶
The grant carries an explicit term and an owner. The holder renews proactively, well before expiry, so a failed attempt still leaves room to retry — often with a fallback path (renew from the original grantor first, then from any grantor). Expiry is authoritative: the grantor, not the holder, decides when the lease is dead, and on that boundary the resource is reclaimed. Recovery from a lapse is therefore not a repair of the old grant but the acquisition of a fresh one, with a new term and, where correctness demands it, a new token that invalidates the stale holder.
Tuning parameters¶
- Lease term length — long terms mean fewer renewals and less traffic, but slower reclamation of a resource whose holder died; short terms reclaim fast but pay in constant renewal chatter.
- Renewal lead time — how early in the term the first renewal fires (e.g. at 50%); renewing earlier tolerates more failed attempts before the grant is actually lost.
- Fallback path — renew only from the original grantor, or from any available grantor; broader fallback survives a single grantor's outage.
- Reclaim policy on lapse — immediate revocation versus a grace window; a grace period tolerates transient renewal failures at the cost of holding the resource longer than the term promised.
- Exclusivity — whether the grant is an exclusive lock or a shared reservation; exclusive leases need a fencing guard for the moment a lapsed holder doesn't yet know it lapsed.
When it helps, and when it misleads¶
Its strength is that expiry is a safety property: resources held by crashed, partitioned, or forgotten holders are reclaimed without anyone hunting for them. That makes it the natural fit wherever a grant must not outlive the grantee's liveness.
Its central failure mode is the expired-but-unaware holder — a process paused by a long garbage-collection stall or cut off by a network partition, whose lease has quietly lapsed but which resumes and keeps acting as if it still holds the grant. Two holders now believe they own the same lock, and both write. The classic misuse is stretching the term so long that reclamation is meaningless, or treating a live lease as proof of the holder's health. The discipline that guards against it is fencing — pairing each grant with a monotonic token so the protected resource can reject a stale holder's late write.[n1]
How it implements the components¶
Lease Renewal realizes the grant-and-expiry side of the archetype's machinery — the parts a time-bounded contract can enforce, not the whole set:
refresh_action— the renewal request that extends the lease term is the refresh; without it the grant simply ends.disappearance_threshold— the lease expiry time is the threshold, and it is authoritative: past it, the grant is revoked rather than merely aged.lapse_recovery_rule— on a missed renewal the resource returns to the pool and must be re-acquired under a fresh lease (and a fresh fencing token), not silently resumed.
It does not test whether the underlying state is still valid — that is Refresh Validity Probe; it does not decide when a human should act — the reminder_cue is Reminder Ping; and it does not budget a working set against load — that is Rolling Context Refresh.
Related¶
- Instantiates: Threshold-Refresh State Maintenance — Lease Renewal supplies the expiry-and-reclaim contract the maintenance loop rests on.
- Sibling mechanisms: Cache TTL Refresh · Reminder Ping · Keepalive Signal · Heartbeat Touch · Refresh Validity Probe · Rolling Context Refresh · Attention Refresh Pulse · Checklist Micro-Rehearsal · Subvocal Repetition Loop
Editorial Notes¶
Form Classification¶
Form family: Control, Automation & Runtime
Rationale: The live lease automatically revokes resource access unless the holder renews before its bounded term expires.
Nearest alternative: Rule, Policy & Commitment — Renewal terms are declarative, but automatic expiry and state change are operative.
Review outcome: Adjudicated after independent review; high confidence.
Origin Attribution¶
Primary origin: Computer Science & Software Engineering
Origin pattern: Single lineage
Present-day reach: Specialized
Rationale: Distributed systems developed renewable time-bounded grants whose expiry serves as automatic revocation after holder failure.
Review outcome: Independent reviewer agreement; high confidence.
Notes¶
Lease Renewal assumes clocks that are close enough: the grantor's notion of "expired" and the holder's notion of "still mine" must agree within a bounded skew, or the safety guarantee slips. Where clocks cannot be trusted to that degree, a lease alone is not enough and must be backstopped by fencing at the resource — the expiry decides who should hold the grant, the token decides whose write is accepted.
[n1] A fencing token is a monotonically increasing number issued with each lease; the protected resource records the highest token it has honored and rejects any write bearing a lower one. This is the standard guard, widely discussed in distributed-systems practice, for the case where a holder's lease silently expires but it keeps acting — the stale write is fenced out even though the holder never learned it had lost the grant. ↩