6 ms·

RFC 9293: Transmission Control Protocol (TCP)

283 points by q-big 4y ago

oeoe 4y ago
See also the evil bit RFC: https://www.rfc-editor.org/rfc/rfc3514 https://www.rfc-editor.org/rfc/rfc3514
- q-big 4y ago
  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.
egberts1 4y ago
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://egbert.net/blog/articles/tcp-evolution.html https://opnetprojects.com/opnet-projects/opnet2-1/ https://opnetprojects.com/opnet-projects/opnet2-1/
q-big 4y ago
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 4y ago
  Thanks for the context! I was wondering why the RFC number was so large…
  - ngcc_hk 4y ago
    Crazy if you think about how stable it is
- cesarb 4y ago
  > This new version of STD 7 (TCP) was adopted yesterday. To give an official source for that: https://datatracker.ietf.org/doc/rfc9293/ https://datatracker.ietf.org/doc/rfc9293/ says "Last updated: 2022-08-18" which indeed was yesterday.
- deleted 4y ago
  [deleted]
netfortius 4y ago
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 4y ago
  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 4y ago
  I remember enjoying "Sams Teach Yourself TCP/IP in 24 Hours" while in detention.
harvie 4y ago
Are there any new features or minor improvements? It seems to just compile previous RFCs right?
- q-big 4y ago
  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 4y ago
    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 4y ago
      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 https://www.legislation.gov.uk/ukpga/2003/42 [1]: https://www.legislation.gov.uk/aep/Edw1cc1929/25/9 https://www.legislation.gov.uk/aep/Edw1cc1929/25/9
pclmulqdq 4y ago
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 4y ago
  How did you test for compliance?
  - pclmulqdq 4y ago
    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.
    - jdougan 4y ago
      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.
m3kw9 4y ago
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 4y ago
  Generally prototype implementations have been tested before the RFC is finalized.
adunk 4y ago
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.
Lightbody 4y ago
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"?
- bombcar 4y ago
  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.
  - thayne 4y ago
    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 4y ago
      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.
      - thayne 4y ago
        > 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?
billpg 4y ago
About time they standardised this protocol.
- q-big 4y ago
  TCP was already standardized in September 1981 in RFC 793: > https://www.rfc-editor.org/rfc/rfc793 https://www.rfc-editor.org/rfc/rfc793 RFC 9293 is a new version of STD 7 (TCP).
sgt 4y ago
Perfect reading on a vacation day.
lxe 4y ago
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.

283 points by q-big 4y ago

oeoe 4y ago

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

q-big 4y ago
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.

egberts1 4y ago

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://egbert.net/blog/articles/tcp-evolution.html https://opnetprojects.com/opnet-projects/opnet2-1/ https://opnetprojects.com/opnet-projects/opnet2-1/

q-big 4y ago

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 4y ago
Thanks for the context! I was wondering why the RFC number was so large…
- ngcc_hk 4y ago
  Crazy if you think about how stable it is
cesarb 4y ago
> This new version of STD 7 (TCP) was adopted yesterday. To give an official source for that: https://datatracker.ietf.org/doc/rfc9293/ https://datatracker.ietf.org/doc/rfc9293/ says "Last updated: 2022-08-18" which indeed was yesterday.
deleted 4y ago
[deleted]

netfortius 4y ago

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 4y ago
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 4y ago
I remember enjoying "Sams Teach Yourself TCP/IP in 24 Hours" while in detention.

harvie 4y ago

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

q-big 4y ago
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 4y ago
  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 4y ago
    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 https://www.legislation.gov.uk/ukpga/2003/42 [1]: https://www.legislation.gov.uk/aep/Edw1cc1929/25/9 https://www.legislation.gov.uk/aep/Edw1cc1929/25/9

pclmulqdq 4y ago

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 4y ago
How did you test for compliance?
- pclmulqdq 4y ago
  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.
  - jdougan 4y ago
    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.

m3kw9 4y ago

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 4y ago
Generally prototype implementations have been tested before the RFC is finalized.

adunk 4y ago

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.

Lightbody 4y ago

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"?

bombcar 4y ago
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.
- thayne 4y ago
  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 4y ago
    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.
    - thayne 4y ago
      > 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?

billpg 4y ago

About time they standardised this protocol.

q-big 4y ago
TCP was already standardized in September 1981 in RFC 793: > https://www.rfc-editor.org/rfc/rfc793 https://www.rfc-editor.org/rfc/rfc793 RFC 9293 is a new version of STD 7 (TCP).

sgt 4y ago

Perfect reading on a vacation day.

lxe 4y ago

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.