Index Journeys
RFC 440 UNKNOWN OPERATIONS · HISTORY

Scheduled network software maintenance

Extending the ARPANET's weekly software update window from one to two hours.

On rfc-editor.org ↗
PUBLISHED
January 1973
AUTHORS
D.C. Walden
STREAM
Legacy
PREVIOUS WINDOW
7am-8am Eastern, Tuesdays
NEW WINDOW
7am-9am Eastern, Tuesdays
EFFECTIVE DATE
First Tuesday in February 1973
NETWORK SIZE
About 40 IMPs
DOI
10.17487/RFC0440

RFC text

Original text · RFC Editor View on rfc-editor.org ↗ 
Network Working Group                                    David C. Walden
RFC #440                                                 BBN-NET
NIC #13772                                               January 1973
Updates: 381,406


                 Scheduled Network Software Maintenance
                 --------------------------------------

    As explained in RFC 381, we believe that we can minimize
the disruption caused by the release of new IMP software systems by
doing them on a regularly scheduled basis.  In the past we have
reserved the one hour period from 7am until 8am every Tuesday morning
for our IMP system scheduled software maintenance period.  As the size
of the network has grown to about forty IMPs, we find we can no longer
complete a system release to all IMPs in the one hour scheduled.
Therefore, we are extending our scheduled software maintenance period
to two hours from 7am until 9am eastern time every Tuesday
morning. The extended period will take effect as of the first Tuesday
in February.  As we said in RFC 381, we will not always use the
Tuesday morning period, but we always reserve it.  On Tuesday mornings
when we _do_ use the scheduled software maintenance period, a type 2 IMP
to Host message* will be sent to all Hosts about an hour in advance of
the period.

    We understand that the software maintenance period cannot
continue to grow linearly with the number of IMPs, and we will find a
way around this problem before software releases start taking 168
hours a week.



*An IMP-GOING-DOWN-FOR-SCHEDULED-SOFTWARE-MAINTENANCE message.







       [ This RFC was put into machine readable form for entry ]
       [ into the online RFC archives by Alex McKenzie with    ]
       [ support from GTE, formerly BBN Corp.             9/99 ]

AI ELI5

On this page
PROBLEMBBN needed to distribute new software to every IMP on the network, but as the network grew to about forty IMPs, one hour on Tuesday mornings was no longer sufficient time.
MECHANISMBBN extended the regularly scheduled maintenance window from 7am to 8am to 7am to 9am Eastern Time, still on Tuesday mornings, to accommodate the growing network. Hosts receive advance notice via a type 2 IMP-to-Host message about an hour before the maintenance period.
GROWING PAINSThe expanded window allows timely software updates as the network grows, though BBN acknowledged that linear scaling would eventually become impractical.

§1Scheduled Maintenance

RFC 440 announces a change to the ARPANET's maintenance schedule. BBN, which managed the network's Interface Message Processors (IMPs), had established a regularly scheduled software maintenance period to minimize disruption: Tuesday mornings from 7am to 8am Eastern Time. During this hour, IMPs would receive updated software and host systems knew to expect downtime.

This approach, described in RFC 381, was designed to give the network community predictability: everyone knew when the network would be unavailable, rather than experiencing surprise downtime whenever a software update was needed.

The network managers picked Tuesday mornings for maintenance so everyone would know when the network was going to be down.

§2The Growing Network Problem

As the ARPANET expanded to about forty IMPs, the one-hour maintenance window became insufficient. Distributing new software to every IMP on the network was now taking longer than the reserved slot. Effective the first Tuesday in February 1973, BBN extended the scheduled maintenance window to two hours, from 7am to 9am Eastern Time.

The network still would not necessarily use the full window every week; it remained a reserved slot that was always available for maintenance, but only activated when needed. Hosts would receive advance notice via a type 2 IMP-to-Host message about an hour before a maintenance period was to begin.

With more machines to update, they needed two hours instead of one on Tuesday mornings.

§3Scaling Limitations

Walden's RFC acknowledges a fundamental problem: software maintenance cannot continue to scale linearly. If the one-hour window was barely enough for forty IMPs, and doubling to two hours was necessary, the arithmetic suggests that at some point a two-hour maintenance window would become too small as the network continued to grow.

The RFC expresses confidence that BBN would find a better solution before maintenance windows consumed an entire week of time. Indeed, future network growth would rely on new approaches to software distribution and update management, such as decentralized updates and rolling maintenance windows.

The network leaders knew that this solution would not work forever if the network kept getting bigger.