RFC-59

by Darius Kazemi, Feb 28 2019

In 2019 I'm reading one RFC a day in chronological order starting from the very first one. More on this project here. There is a table of contents for all my RFC posts.

The case for perfect

RFC-59 is another odd one. It's missing the standard RFC cover page and as such I had to poke around for its title, which is available on page 2 and beyond in the header. It's called “Flow Control – Fixed Versus Demand Allocation”. It is authored by Edwin W. Meyer of MIT's Project MAC and dated June 27th, 1970.

This RFC also features an erratum (correction). Errata are a formal aspect of the RFC series. Since an RFC, once submitted, can never be changed in place, instead corrections happen by appending errata, which are short notes that say, for example, “this section had a typo, it should read xyz instead of abc”. Here is the errata entry for this RFC. The errata entry corrects an incorrect reference to a different RFC number.

The technical content

This RFC is a strongly worded disagreement with the official host-host protocol offering by Crocker et al in RFC-54, particularly the section of that RFC on “Flow Control”.

They list a number of disadvantages with the RFC-54 flow control scheme, which I'll excerpt here verbatim:

(i)  chronic underutilization of resources,

(ii) highly restricted bandwidth,

(iii)considerable overhead under normal operation,

(iv) insufficient flexibility under conditions of increasing load,

(v)  it optimizes for the wrong set of conditions, and

(vi) the scheme breaks down because of message length indeterminacy.

They go on to describe these in detail, but the crux of the document is, the RFC-54 scheme has these six problems, they do their best to prove that the scheme has these problems (and convincingly, I think), and they implore the NWG to use a previously proposed flow control scheme instead.

But even though the technical details of this paper seem correct... well... I'll save it for the analysis section, which is where my opinions come in.

Analysis

Once again this seems like a battle of “good enough” versus “perfect”. In RFC-54, the authors state

[t]his new procedure has demonstrable limitations, but has the advantages that it is more cleanly implementable and will support initial network use.

Specifically, the authors of RFC-54 say “this isn't perfect but we can build it today and it will be fine for now.” The authors of this RFC disagree, opening with what they see as the six major defects of the RFC-54 scheme.

When the authors of this document lay the pros and cons of their scheme side by side with the pros and cons of the RFC-54 scheme, one thing remains curiously absent: ease of implementation, which was very specifically a key advantage laid out by the authors of RFC-54, in fact probably the key advantage.

To my eye, this document is either written in bad faith, or written by authors who are unable to see the social compromises necessary to get things working at all instead of working correctly. Now I might just be fully projecting here and saying this will probably get me some angry emails, but... this does seem like the kind of thing to expect from the Project MAC team, who gave us Multics, where to my knowledge, the abstract idea of technical correctness took precedence over concepts like ease of use.

How to follow this blog

You can subscribe to this blog's RSS feed or if you're on a federated ActivityPub social network like Mastodon or Pleroma you can search for the user “@365-rfcs@write.as” and follow it there.

About me

I'm Darius Kazemi. I'm a Mozilla Fellow and I do a lot of work on the decentralized web with both ActivityPub and the Dat Project.

365 RFCs