RFC 9293: Transmission Control Protocol (TCP) | Hacker News Reader

RFC 9293: Transmission Control Protocol (TCP)

rfc-editor.org

283 pointsq-big59 comments

This is a really big help to anyone trying to implement TCP. At one previous job, we had to wade through ~20 RFCs to figure out how to write a hardware TCP system, paying particular attention to which RFC supersedes which sections of other RFCs. Consolidating to one RFC without the crazy dependency chain is a big improvement!

How did you test for compliance?

With great difficulty and a lot of different hardware on the other side of the link. We didn't need a fully standards-compliant implementation, though, so we cut a lot of corners.

To be fair, that is pretty much the story of early interop testing: the bake-offs, where they put everyone in a room and tested against each other.

I wish government legislature did this with their bills. Reading a piece of legislation is maddening because it's always just a description of diffs, without seeing the final outcome.

I never really realized that this symptom was common with RFCs as well.

Is there something about how governing bodies work that lead to this style of output? Why aren't we using a bit more modern techniques now, more akin to how word processors let you see the diffs inline but also the final format? Or git-style PRs that show the deltas but you can always just view "main"?

This is the natural end result of committee-style work - because if you work on a "diff" you can force the discussion to only touch some small parts of the whole, but if you work on an "updated document", even if everyone kind of agrees the only change necessary is to Section 7, the fact that the whole document is "up for discussion" causes the whole thing to be up for discussion.

In both cases they can still produce the "final document" which the government is often better at than standards bodies.

But what if the changes were proposed as an actual diff to the original document, similar to a pull request, so that once it is approved, it can be combined into a new version that fully replaces the old?

They often are, but the standards groups don't seem to actually produce that changed new version (likely because they wouldn't have a way to reference it?) - governments just implement the diffs in the law.

> likely because they wouldn't have a way to reference it?

Just add a version onto it, like RFC 1234-2022 for the version of RFC 1234 released in 2022 (or use incementing integers it doesn't really matter).

That's basically how language standards like ISO c and c++ and ecmascript are done isn't it?

They often do have version and revision numbers. As well as final release numbers. I find the biggest issue is the lack of ability to trace the document forwards in the repositories.

Usually an update will list which documents it updates but often it's much harder to find if there have been any new updates that have further obsoleted this update.

That's one of the functions of the Federal Register. It applies the diffs so to speak to produce the actual code (by code here I mean law code). But yes in theory you can challenge that in court by showing they applied the changes incorrectly or something.

And FWIW every once in a great while the government does tend to reset the baseline, declaring a specific version of the merged code as the single truth. So even if there are errors or whatever from previous applications of various bills it doesn't matter and courts can't examine that. This prevents every bit of law from potentially being subject to reconstruction from the first congress forward. I believe the current base revision is from 1986.

Not just that, there's also the fact that the result of the committee work will then be put up for vote. That's basically an enormous code review, if not enough representatives press "accept" nothing happens.

Imagine having to review code changes without a diff, e.g. with only the before and after states, on separate computers. Bad idea.

A possible counter model to this kind of organization is how the Nicolas Bourbaki collective organized their work:

"Subcommittees are assigned to write drafts on specific material, and the drafts are later presented, vigorously debated, and re-drafted at the conferences. Unanimous agreement is required before any material is deemed acceptable for publication. A given piece of material may require six or more drafts over a period of several years, and some drafts are never developed into completed work. Bourbaki's writing process has therefore been described as "Sisyphean". Although the method is slow, it yields a final product which satisfies the group's standards for mathematical rigour, one of Bourbaki's main priorities in the treatise."

Source: https://en.wikipedia.org/w/index.php?title=Nicolas_Bourbaki&... (emphasis by me)

* https://www.ocf.berkeley.edu/~lekheng/interviews/ClaudeCheva... (cf. pages 18 and 20)

This can work when you have a defined mathematical result you're trying to get to - in most standard bodies this would result in never releasing a standard, ever.

> In both cases they can still produce the "final document" which the government is often better at than standards bodies.

Not sure I agree that the government is very good at this at all, or maybe I'm just looking in the wrong place?

Example: https://www.congress.gov/bill/117th-congress/house-bill/3967...

> (1) EXPANSION.—Subsection (e) of section 1710, as amended by section 102(c), is further amended— > (A) in paragraph (1), by adding at the end the following new subparagraphs:

You might try the Federal Register¹, which mostly documents the diffs, but links to the full documents at the Code of Federal Regulations²

¹ https://www.federalregister.gov/

² https://www.ecfr.gov/

Your example is a bill that hasn't become law yet; so it has not been integrated into the US code (the "final document"). When the president signs it and it becomes law, the change specified there will be made. You can find the US code, as it is in effect today, among other places, on the site of the House: http://uscode.house.gov/

Thank you for clarifying that.

What I'd love to see is a place where I could view a bill and also the code it impacts, with inline diffs for the relevant bits (but not the dumb formatting / bullet numbering stuff).

Is that too much to ask for?

Is this common in many countries, or just the US?

Yes, it's common. Usually each country has their own cottage industry of providers that mitigate this problem. (By git-ifying the text of legislation.)

Thanks!

> Usually each country has their own cottage industry of providers that mitigate this problem. (By git-ifying the text of legislation.)

We are truly living in the future! And as expected, it's made up of heroic duct-tape to paper over backwards-compatible rough edges.

> Why aren't we using a bit more modern techniques now, ...

because those in power don't care, this problem doesn't really affect them, they don't know about potential solutions (too old and/or not programmers), they are afraid of structural change anyhow, etc, etc.

Your response seems to have a political bent to it, though I could be presuming too much. Assuming you intended for it that way: how does that explain RFCs seemingly behaving the same way? That's about as techie as you can get!

but RFCs are written using "git".

https://www.ietf.org/rfcdiff?url1=draft-ietf-tcpm-rfc793bis-...

sure, maybe IETF uses their homegrown version, but - for example - TC39 uses GitHub https://github.com/tc39/ (here are the proposals for JS https://github.com/tc39/proposals ), whatWG also uses GH https://github.com/whatwg/html

This process pre-dates computing. And the law in general defers to precedent, history, and customs - that's part of what Common Law is.

Eventually the legislative process will catch up and use something akin to version control. But that's just automating what is currently a manual process. And the bottleneck for making progress isn't the difficulty of updating the law - not by a long shot.

FWIW some bills just say something like:

1. Strike 27 Section 2(g) (which is 100 paragraphs) 2. Insert the following under 27 Section 2(g) (followed by an entirely rewritten bit of law)

Even all the sections, paragraphs, etc with the numbers, capital letters, lowercase letters, and so on are really just a manual form of hyperlinking and bookmarking so the code can have cross-references.

That's also something that could be a lot easier to write, update, and read if we had a VCS for writing laws.

Legal case research is is even worse, if you can imagine. Digging through court decisions is all about finding chains and piecing together the current precedent. Oh and in the old days of legal reference texts, you always had to check for the "pocket parts". Updates to the law after the text was published went sent out as small pamphlets, much like errata, and they were literally placed in pockets at the back of the books.

The UK does this (but only since 2006, ish, and it's not guaranteed to be fully up to date everywhere). For example, here's an act made in 1981 and amended many times since:

https://www.legislation.gov.uk/ukpga/1981/69

Inserted or altered text is in heavy square brackets, and removed text is replaced with a row of full stops; both are labelled with a code starting with F, which indexes a reference in a box below the section. The references are hyperlinks to the amending legislation; sometimes there is a link to both an act which enabled the amendment, and a statutory instrument which applied it.

There's a slider at the top which lets you see the legislation as it stood in the past (as far as 1991), before each amendment was made.

Amendments made before 1991 are applied, but not sliderable:

https://www.legislation.gov.uk/aep/Hen3c23/52/23/section/XXI...

> I wish government legislature did this with their bills. Reading a piece of legislation is maddening because it's always just a description of diffs, without seeing the final outcome.

Most governments do maintain a consolidated version of their laws, but that's something different than the bills. Compare it with GitHub: the consolidated version is the head of the repository, while the bills are Pull Requests.

E.g. for the US there's the US code: https://uscode.house.gov/; which for every section has both the text as currently in effect, as well as a list of all historical amendments.

Some governments do. For instance, check Brazil's constitution: http://www.planalto.gov.br/ccivil_03/constituicao/constituic... which has for changed articles both the original text (in strike through), the updated text, and hyperlinks to the legislation which was the source of each change. (And it's not just the constitution, all federal legislation has pages presenting in that format.)

> I wish government legislature did this with their bills. Reading a piece of legislation is maddening because it's always just a description of diffs, without seeing the final outcome.

The state of Washington does. Our legal code is called the "Revised Code of Washington" because there is a state employee, called the Code Reviser, whose job description is "apply the diffs":

http://www.leg.wa.gov/CodeReviser/

It sounds a bit silly at first but having gotten used to having instant access to the end product I think this is an excellent use of my tax dollars.

https://apps.leg.wa.gov/rcw/

They do a great job, too. Each section/subsection of the RCW comes with links to the bills which revised it, and each of those is formatted using strikeouts (removed text) and underlines (added text).

The federal government should be embarrassed by this.

In the IETF's case, this is because, by policy, RFCs are immutable once published. You can update an RFC by publishing a new RFC that specifies the changes, or a new one that obsoletes the original entirely (this document does both to various RFCs). There is also an errata process for simple mistakes.

That means that minor changes tend to accumulate in other documents over the years. You could imagine tooling that automatically incorporates these changes into the presented document, like you suggest, but someone would have to build that tooling. That is a bit challenging, as the format of an RFC that updates another is not designed for such automated processing (e.g., go read this document and tell me what changes should be made to the text of RFC 5961, which it updates), and because the format of a published RFC is not semantic (e.g., adding a new section will not automatically renumber the remaining sections, because it's just a .txt file).

You could also design a different policy, but immutability has its advantages, too, and the current policy has been in use for decades, so the case for switching would have to be pretty compelling.

So for now the "Updated by:" header at the top of each document is what you get.

Technically all "update" RFCs could be "obsolete" RFCs - just copy the whole previous RFC and change the parts you wanted to change. The only advantage of "update" RFCs I can think of is that it tells the reader precisely what is being updated, but that can be done by just a changelog.

Most changes are in self contained documents because they are inherently experimental. After a while they become so useful and widespread that everyone needs them, and hopefully a bis rolls them all up.

This new version of STD 7 (TCP) was adopted yesterday. The previous version of STD 7 (RFC 793) was adopted in September 1981 - nearly 41 years ago.

Thanks for the context! I was wondering why the RFC number was so large…

Crazy if you think about how stable it is

> This new version of STD 7 (TCP) was adopted yesterday.

To give an official source for that: https://datatracker.ietf.org/doc/rfc9293/ says "Last updated: 2022-08-18" which indeed was yesterday.

It is cool to see such a central piece of the Internet puzzle get an updated specification.

This quote from the RFC provides both the context of this document and is an indication as to why it seemingly took so long for this particular update to be published:

> This document is largely a revision of RFC 793, of which Jon Postel was the editor. Due to his excellent work, it was able to last for three decades before we felt the need to revise it.

What a ride!!! Learned it as part of my CS program, using TCP/IP Illustrated (original, vol 1) of the famous W. Richard Stevens

I worked with Gary Wright (vol. 2) around 1998-2000, before he quit the high stress job to hike the Appalachian trail. Living the dream.

I remember enjoying "Sams Teach Yourself TCP/IP in 24 Hours" while in detention.

Are there any new features or minor improvements? It seems to just compile previous RFCs right?

See the Abstract and Section "1. Purpose and Scope":

"Over this time, a number of changes have been made to TCP as it was specified in RFC 793, though these have only been documented in a piecemeal fashion. This document collects and brings those changes together with the protocol specification from RFC 793. This document obsoletes RFC 793, as well as RFCs 879, 2873, 6093, 6429, 6528, and 6691 that updated parts of RFC 793."

"The purpose of this document is to bring together all of the IETF Standards Track changes and other clarifications that have been made to the base TCP functional specification (RFC 793) and to unify them into an updated version of the specification."

Nevertheless, it seems that some updates and clarifications were also done:

"It updates RFCs 1011 and 1122, and it should be considered as a replacement for the portions of those documents dealing with TCP requirements. It also updates RFC 5961 by adding a small clarification in reset handling while in the SYN-RECEIVED state. The TCP header control bits from RFC 793 have also been updated based on RFC 3168."

Isn't this kind of a flaw in the RFC process? Shouldn't we have been amending the original spec this whole time and tagging new versions, source control style?

The legal system has a similar problem, though it's ironically even more obvious because amendments to laws will be something like "Page 143, Paragraph 7, Sentence 4 will now read ..." which is just literally writing out a diff.

I'm feeling salty at the moment because for various reasons I'm deep in the OpenID Connect specifications right now, and while they're available the overall formatting, layout and hyperlinking is just awful for rapidly conveying meaning (and like all things OAuth the spec by everyone else also can't be trusted).

Surely we can and should do better.

Yeah. This is part of the issue that legislative codification is supposed to deal with. A new law is often making a diff to the old one, and you can either keep a pile of diffs in hand and work out what the current state is in your head, or you can try to make sure there is a 'master version' (the Code) which you keep patching and can check out a fresh version of when you need to read it.

England and Wales (my home jurisdiction) doesn't have either criminal or civil codes as such, but it does do a fair number of consolidating statutes - almost exactly like this new RFC. The Sexual Offences Act 2003, for example, made some changes but also consolidated the current state of sexual offences law into a single Act[0]. (You can also now see the 'as amended' versions on the web for all Acts, which is useful. If you want to know which bits of Magna Carta are still in force, well now you can[1]. This Act has the additional problem that source control was fairly shoddy in 1297 and it's not entirely clear what the actual text in force is...)

[0]: https://www.legislation.gov.uk/ukpga/2003/42 [1]: https://www.legislation.gov.uk/aep/Edw1cc1929/25/9

That's mostly just the case of a long-running system: It was a sensible choice in the day, and apparently it's held up, considering we're talking about an RFC revised 41 years later.

I do wish it was more clear how one could engage in the process: I will literally not sleep soundly at night until the HSTS standard is revised to remove it's malicious component (the "no user recourse" clause), but I also... really have no idea where to start on getting it amended.

Now i am waiting for the equivalent for http.

It is the same nightmare of piecemeal changes...

That happened already, no? https://www.mnot.net/blog/2014/06/07/rfc2616_is_dead

No need to wait; HTTP got a similar full overhaul across several RFCs. Read all about it from one of the editors:

- https://www.mnot.net/blog/2022/06/06/http-core

- https://www.mnot.net/blog/2022/06/08/http-extensions

This[1] might be what you're looking for.

[1]: https://www.mnot.net/blog/2022/06/06/http-core

A graph of the evolution of TCP by codenames and functionalities.

I worked with Sally (of ISC) on TCP Westwood.

We used OpNet Simulator (~1.0) to exercise massive pseudo-traffic when testing.

https://egbert.net/blog/articles/tcp-evolution.html

https://opnetprojects.com/opnet-projects/opnet2-1/

Never heard of it. Must be some Web3 thing. /s

In all seriousness, all important technical documents should do this -- as the implementation and use cases evolve, re-define the standard, documenting the canonical changes and clarifying everything.

Perfect reading on a vacation day.

About time they standardised this protocol.

TCP was already standardized in September 1981 in RFC 793:

> https://www.rfc-editor.org/rfc/rfc793

RFC 9293 is a new version of STD 7 (TCP).

New IP stack RFCs are a chicken or the egg problem without a reference implementation to test with. How do you release it into the wild without a say Linux or windows implement one first?

Generally prototype implementations have been tested before the RFC is finalized.

See also the evil bit RFC: https://www.rfc-editor.org/rfc/rfc3514

What does this April fools joke have to do with the revision of the TCP standard?

EDIT: Also consider that the "evil bit" is part of the IPv4 header, and not of the TCP header.

Reply on news.ycombinator.com