7 ms·
> I tend to think this is an outlier- for the most part, CS theory back in the 1970's did not hard math. CS theory always had hard math. Software engineering d
by kevmo314 5y ago
> I tend to think this is an outlier- for the most part, CS theory back in the 1970's did not hard math.
CS theory always had hard math. Software engineering didn't (and still mostly doesn't) but also in the 1970's software didn't exist so you could literally do anything and it would become the standard if it was pushed hard enough.
It's not like there's an intrinsic reason TCP packets are the way they are now, it's largely an arbitrary choice that we standardized on.
- throwvirtever 5y ago> [I]n the 1970's software didn't exist There actually was software in the 1970s, and earlier.
- titzer 5y ago> It's not like there's an intrinsic reason TCP packets are the way they are now, it's largely an arbitrary choice that we standardized on. IP and TCP were very carefully designed and were not much like the networking standards of the time. It wasn't an arbitrary choice any more than designing a rocket engine is an "arbitrary choice".
- dahart 5y agoParent wasn’t taking away from the intention of design; they were talking about what designs got canonized by accident. This happens everywhere: very good and very intentional designs become the de facto standard for arbitrary reasons, often just being first. Electrons being negative, Leibniz notation, musical notation and the four piece band, binary digital circuits, hamburgers, the car, and even the structure of TCP packets, are all things that got overwhelmingly popular despite the presence of good and intentional alternatives, they are largely arbitrary choices for standardization.
- bbulkow 5y agoDefinition of arbitrary: 'based on random choice or personal whim, rather than any reason or system.' (Google) Being first is not arbitrary. It is hard to achieve, and valuable. It is a reason. There were networking systems before TCP and alongside TCP, TCP was clearly superior for a large number of reasons. Given that everyone on hacker news's livelihood stems from the awesome of TCP (not an over statement), I propose a bit more respect.
- titzer 5y agoEven still, I don't agree that IP became a standard for arbitrary reasons. For the most part, IP did not "compete" with other protocols; it encapsulates and bridges other protocols, from ethernet to IPX to what-have-you. TCP is properly understood as a layer above IP, the connection-oriented stream protocol to match with the UDP, the packet-oriented protocol. Both are encapsulated in IP packets. IP was specifically designed to bridge heterogenous networks and thus its name inter-network protocol.
- dahart 5y agoI hear your point, and you’re right about TCP. I’m only clarifying that even though you disagree, I (and parent I believe) don’t disagree with you. There’s a lot room for vagueness and potential for miscommunication hidden behind the word “arbitrary” - it can be a shorthand for too many or too complex or too ad hoc to account for. The point was basically that history is ‘arbitrary’, at a larger scale than the intention of the TCP design or the reasons it got chosen for standardization. Maybe the primary reason that TCP stuck is because the military committed to it first, and that signaled to the rest of the world that it was good enough. It doesn’t necessarily require competition for something to be arbitrarily canonized or standardized, things just happen the way they happen. There can be good reasons all along the way, but it still could have happened a different way, and just didn’t. TCP does choose some specific tradeoffs, it’s not the only way the internet could have come about. Being first without competition is one way it happens. When this happens it adds enormous friction to later alternatives that have or make different tradeoffs.
- titzer 5y ago> There’s a lot room for vagueness and potential for miscommunication hidden behind the word “arbitrary” - it can be a shorthand for too many or too complex or too ad hoc to account for. Yeah, I get that, and of course everything is a spectrum, including the level of arbitrariness. But I am just going by the definition of arbitrary in a dictionary: > arbitrary, adj. based on random choice or personal whim, rather than any reason or system. Whereas my analogy with rocket engines was meant to illustrate that IP was designed to solve a very specific problem given a set of constraints. Most (let's say, liquid-fueled) rocket engines end up with very similar designs and engineering decisions are made to optimize performance rather than whim. It's a very empirically-driven engineering exercise. And for the OP's mentioning of the TCP packet format, I still think we shouldn't regard that as arbitrary. The location of the source and destination fields, for example, was carefully chosen so that routers of the time could minimize the logic necessary to decode them and start to make routing decisions before even most of the header had arrived. It was literally optimized down to the bit position. Now, the choice of byte order (big endian), we might be considered somewhat arbitrary (maybe even wrong) now, but even that was motivated by the machines of the time, as most were big endian while nowadays almost all remaining architectures are little endian (causing no end of confusion to poor networking students). I don't disagree that history overall, and computer history in particular is full of arbitrary choice points, but I think TCP/IP isn't a good example of that.
- JohnHaugeland 5y ago> Parent wasn’t taking away from the intention of design Yes they were, very literally, and incorrectly to boot
- deleted 5y ago[deleted]
- bbulkow 5y agoI fought in the networking wars. Implemented a lot of protocols and a lot of protocol gateways. Calling the reason for TCP winning 'arbitrary' or even softening that to 'not based entirely on technical merit' does not do justice to the entire land war in Asia that happened between about '85 and '95. If anyone cares about that period, they can do some research, otherwise, I would propose not uttering unfounded opinions.
- kazinator 5y ago> IP and TCP were very carefully designed How did it happen that the byte order of the multi-byte numeric fields in TCP/IP headers is big endian, which is opposite of what most machines use now? Back then, did it look as if big endian would become prevalent? Today, almost every host attached to an IP network has to byte swap. The IPv6 people definitely ought to have designed a little more carefully.
- lanstin 5y agoWhen IP and TCP were deployed, most machines were big-endian.
- tuatoru 5y ago> Back then, did it look as if big endian would become prevalent? Yes. Big endian was "natural" and x86 was weird and awkward, and a niche low end design that woud never be connected to networks.
- GuB-42 5y agoBig endian is better for routing applications. In the same way that little endian is better for addition. For example let's say I send a message to 1.2.3.4, the first router will decide what will be the next node based on the first number, the next one on the second, the next on the third, etc... Because it is big endian, the first router only has to read the first number to do its job, if it was little endian, it would have to read the entire address fist. Of course, it is a detail, I mean, the words "little/big endian" is a parallel to the the pointless fights in Gulliver's travels. But even if it could have gone either way, for IP, big endian is more natural.
- Fellshard 5y agoI believe what's being stated is that TCP isn't some mathematical inevitability, falling out of some discovered law, but rather a tool that was adopted because it had utility, and was certainly based on more formal findings or hypotheses.
- deleted 5y ago[deleted]
- convolvatron 5y agoIP is somewhat arbitrary. TCP on the other hand really gets down the fundamentals of what's going on. its kind of like a 'from the book' protocol. I've designed several transport protocols (don't ask) - and they are really just minor riffs on TCP. if aliens had a fault-prone wire they wanted to send a message across over some distance - it seems quite likely they would end up with TCP
- bo1024 5y agoThe author may have a different definition of "hard math" than you...
- fragmede 5y agoI think it's a reference to the kind of math involved, like hard science vs soft science. Not that I'm sure what soft math would be. Probabilities?
- hammock 5y agoStatistics. Accounting. Etc
- Ar-Curunir 5y agoNo, the difference is whether you require deep theorems from algebra, measure theory, combinatorics, etc.
- deleted 5y ago[deleted]
- thanatos519 5y agoEconomics.
- Nasrudith 5y agoSoft math vs hard math has me thinking aproximations, estimations, and heuristics as opposed to exact solutions. Neither type of solution is inherently easy or difficult of course.
- leoc 5y ago'Hard' is meant as an antonym of 'easy' rather than 'soft' here.
- aduitsis 5y agoBut let us please note that the choice of α (low pass filter gain constant) in the original round trip estimator of the TCP congestion avoidance algorithm by Van Jacobson is not arbitrary.
- jessriedel 5y agoThe author explains pretty clearly what he means by "hard math" and cites many specific developments that introduced sophisticated techniques into academic CS where they weren't used before.
- NikolaNovak 5y agoI found math depends on location as well. I moved around in the 90's during my University years; what was billed as exactly the same 3rd year networking course: * University of Toronto, ON, Canada: HEAVY math; queuing theory; no computer lab, no mention on any specific stack or technology * University of Athabasca, AB, Canada: No math; discussion on OSI Layers, TCIP/IP, SMTP, Ethernet; gateways routers switches, virtualization; lots of fun computer labs. Not technology specific - it wasn't doing Cisco certs or anything. But good working understanding of what's happening in networking world. I always felt one university taught working software engineers; other university taught the dozen people worldwide who need to create next IPv8 :D
- naasking 5y agoThat's weird, because I was at U of T engineering in the late 90s, took networking and they covered some math for various calculations on ring and wireless networks, had labs, and covered everything the Athabasca course covered as well. Was that for computer science or engineering?
- NikolaNovak 5y agoComputer Science; by all accounts, Computer Engineering was less ivory tower / theory oriented.
- JohnHaugeland 5y ago> It's not like there's an intrinsic reason TCP packets are the way they are now What are you talking about? It was a three year argument based extremely heavily on prior knowledge Why does everyone think that just because they don't know what craft went into something, there wasn't any?
- Ar-Curunir 5y agoNo. NP-Completeness was first defined in the 70s. That’s literally a foundation of much subsequent work. The depth of techniques used back then was mostly just elementary combinatorics, probability, and number theory. In comparison, much work nowadays require complex algebra, advanced combinatorics, and deeper mathematics like measure theory. (This is not to downplay the work of the pioneers who discovered these foundational concepts; just to point out that they used less sophisticated mathematical tools)
- AnimalMuppet 5y agoWhat in computer science requires measure theory?
- Ar-Curunir 5y agoEg: https://simons.berkeley.edu/talks/michael-mislove-2016-08-30 https://simons.berkeley.edu/talks/michael-mislove-2016-08-30
- AnimalMuppet 5y agoNo, I'm not going to watch an hour-long video for the answer. The intro seems to be saying that "domains" (undefined) are related to CS, and also related to measure theory. That's... not much to go on...
- bidirectional 5y agoThere's an abstract right there: > Measure theory has played an important role for domains in modeling probabilistic computation.
- AnimalMuppet 5y agoYup. Read it. Without a definition or context for "domains", it doesn't tell me much.
- SavantIdiot 5y agoFeynman used a differential equation to prove the correct size of the buffers on the first connection machine [1]. [1] https://en.wikipedia.org/wiki/Connection_Machine#Designs https://en.wikipedia.org/wiki/Connection_Machine#Designs
- rabite 5y ago>It's not like there's an intrinsic reason TCP packets are the way they are now, it's largely an arbitrary choice that we standardized on. This is incredibly off-base. There was a huge effort to force an OSI-designed networking protocol stack that was designed by a committee of government bureaucrats and big blue sales engineers. It was a total disaster, but the vast amount of resources that were dedicated to forcing the OSI memes was in the billions of dollars. Large amounts of actual physical hardware were produced conforming to protocol standards nobody doing anything real actually wanted to use because a lot of government agencies required all network equipment to be compatible with the OSI protocol stack. TCP, UDP, and the modern routing protocols (BGP, OSPF, etc) and their associated address resolution systems were not an arbitrary choice -- they represented orders of magnitude level improvements over the government-backed OSI standards and getting them to succeed was the product of intense collective effort of some of the most brilliant minds of the past century. https://en.wikipedia.org/wiki/Protocol_Wars https://en.wikipedia.org/wiki/Protocol_Wars
- walshemj 5y agoAs a former OSI person (UK third line X.400/500 support ) I think that TCP/IP won as it was simpler and good enough. TCP/IP was in no way an technical improvement over OSI
- rabite 5y agoX.400 was actually pretty great and was definitely better designed than the disaster of SMTP (I spent my youth in the email deliverability industry and know all the ingredients of that sausage), but it wasn't a network transport protocol. There is no way that the Internet could have been built on the OSI transport and routing implementations. They were not good. Nothing has stood up to as much scrutiny and scale as TCP/IP. The simplicity is definitely an important part of it. Protocols that are used by trillions of devices need to be simple, and the equipment used to switch and route their traffic have to defer as much handling of state to the clients as possible. The more state that routers have to maintain, the less reliable they will be. TCP/IP accomplished that and that's why it was better.