[HN Gopher] RFC 9293: Transmission Control Protocol (TCP)
___________________________________________________________________
RFC 9293: Transmission Control Protocol (TCP)
Author : q-big
Score : 239 points
Date : 2022-08-19 10:03 UTC (12 hours ago)
(HTM) web link (www.rfc-editor.org)
(TXT) w3m dump (www.rfc-editor.org)
| netfortius wrote:
| What a ride!!! Learned it as part of my CS program, using TCP/IP
| Illustrated (original, vol 1) of the famous W. Richard Stevens
| bpoyner wrote:
| 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.
| justnotworthit wrote:
| I remember enjoying "Sams Teach Yourself TCP/IP in 24 Hours"
| while in detention.
| q-big wrote:
| 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.
| michaelmior wrote:
| Thanks for the context! I was wondering why the RFC number was
| so large...
| ngcc_hk wrote:
| Crazy if you think about how stable it is
| cesarb wrote:
| > 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.
| [deleted]
| pclmulqdq wrote:
| 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!
| amelius wrote:
| How did you test for compliance?
| pclmulqdq wrote:
| 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.
| adunk wrote:
| 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.
| billpg wrote:
| About time they standardised this protocol.
| q-big wrote:
| 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).
| sgt wrote:
| Perfect reading on a vacation day.
| harvie wrote:
| Are there any new features or minor improvements? It seems to
| just compile previous RFCs right?
| q-big wrote:
| 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."
| XorNot wrote:
| 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.
| pmyteh wrote:
| 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
| ocdtrekkie wrote:
| 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.
| di4na wrote:
| Now i am waiting for the equivalent for http.
|
| It is the same nightmare of piecemeal changes...
| chrisoverzero wrote:
| 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
| anuvrat1 wrote:
| This[1] might be what you're looking for.
|
| [1]: https://www.mnot.net/blog/2022/06/06/http-core
| bradfitz wrote:
| That happened already, no?
| https://www.mnot.net/blog/2014/06/07/rfc2616_is_dead
| olafure wrote:
| See also the evil bit RFC: https://www.rfc-editor.org/rfc/rfc3514
| q-big wrote:
| 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.
| m3kw9 wrote:
| 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?
| wmf wrote:
| Generally prototype implementations have been tested before the
| RFC is finalized.
| lxe wrote:
| 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.
| Lightbody wrote:
| 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"?
| derf_ wrote:
| 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.
| Arnavion wrote:
| 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.
| Denvercoder9 wrote:
| > 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.
| octoberfranklin wrote:
| > 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.
| eru wrote:
| Is this common in many countries, or just the US?
| pas wrote:
| 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.)
| twic wrote:
| 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...
| xenadu02 wrote:
| 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.
| cratermoon wrote:
| 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.
| pas wrote:
| > 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.
| Lightbody wrote:
| 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!
| pas wrote:
| 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
| cesarb wrote:
| 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.)
| bombcar wrote:
| 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.
| Lightbody wrote:
| > 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:
| thwarted wrote:
| You might try the Federal Register1, which mostly documents
| the diffs, but links to the full documents at the Code of
| Federal Regulations2
|
| 1 https://www.federalregister.gov/
|
| 2 https://www.ecfr.gov/
| Denvercoder9 wrote:
| 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/
| q-big wrote:
| 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_Bo
| urbaki&... (emphasis by me)
|
| See also
|
| * https://www.ams.org/notices/199803/borel.pdf (cf. page 375)
|
| * https://www.ocf.berkeley.edu/~lekheng/interviews/ClaudeChev
| a... (cf. pages 18 and 20)
| bombcar wrote:
| 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.
| thayne wrote:
| 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?
| bombcar wrote:
| 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.
| xenadu02 wrote:
| 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.
| thayne wrote:
| > 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?
| usrusr wrote:
| 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.
___________________________________________________________________
(page generated 2022-08-19 23:01 UTC)