Bravo - well done.
Edit - Also worth adding that this article is a rarity in that the details are actually accurate! Even things I read in networking books and trades often have egregious errors - usually due to the breadth of the topic matter.
BGP is the routing protocol on the internet, and it's a fairly common one to see inside enterprise networks as well - iBGP is for routing inside an AS. Describing OSPF, IS-IS, etc would have just made things a little more complicated without adding anything.
You should consider reading Kurose/Ross: http://eclass.uth.gr/eclass/modules/document/file.php/INFS13...
Inside the major network to your cable headend or similar: OSPF or IS-IS or something else - in the largest ISPs, a combination of iBGP to get things to right area and then OSPF, IS-IS or EIGRP in medium areas.
Inside your house: almost always static routes, no protocol for exchanging reachability info.
This book is targeted at working programmers:
Most books on systems—computer architecture, compilers,
operating systems, and networking—are written as if the
reader were going to design and implement such a system.
We call this the “builder's persepective.” We believe
that students should first learn about systems in terms
of how they affect the behavior and performance of their
programs—a “programmer's perspective.”
Here is a photo of my copy of the book: http://i.imgur.com/2sd5ivf.jpg. Don't the front look nice? :)
https://www.coursera.org/learn/build-a-computer - This is a fantastic no-prerequisites course that has you actually implementing a functional CPU in 6 weeks starting from building basic logic gates out of NAND gates. There's a hands-on project every week to help you solidify your understanding of the lectures. The resources are also all available at their site: http://www.nand2tetris.org/. In case that sounds intimidating, I have no formal CS education either and couldn't implement any of the basic logic gates before I took the course, and I built a CPU by the end so I'm confident others can too. They have a "Part 2" to this course which has you build from the CPU to a functional operating system which would get you an introduction to how kernels work in general, although they recommend some programming experience for that part.
Hacking: The Art of Exploitation - Despite the name, this book is actually an excellent introduction to low-level behavior both on the CPU and on networks (it's split into distinct sections to cover each topic). I would recommend picking this up after the course linked above, because it's somewhat brief with its explanation of CPU architecture. A beginner's course in C programming might also be advisable since this does use some basic C code which might be challenging if you've never been exposed to it before.
Perhaps you should first try to get familiar with the Linux kernel's way of doing OO in C (if you are unfamiliar with this style; if you have done any modern C programming, it should not be a problem).
(Do not start with the platform startup code; this would probably be too much for the start.)
 https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/lin... (maybe a bit too complex, since it uses DMA)
 To be fair, the serial I/O layer has the tty layer as intermediary, so it's admittedly only slightly better
The screencasts are fantastic as well.
As a front end developer there is actually a lot of networking involved making requests to the servers. It's really helpful to have a high level picture of how http works, and what common networking failure modes are, so you can use better abstractions in your code, expect common failures and shown nice error messages or retry requests, test your app's connections using wirshark to make sure there aren't extra round trips slowing it down, etc.
It's mainly aimed at people interested in ASP.NET Core but there are a lot of general performance tips in there. I have a EEE background and I think understanding things down to the transistor level can really help you write better software.
BTW Gary's WAT video is great fun if you haven't seen it.
It was my goto book when I worked on BGP-4 odds and sods.
There are things you don't know that you don't know. And those always get you.
Worth noting that the region from 1.67 V to 3.33 V is undefined and systems in practice will not behave nicely for signals in this range. A CMOS logic 1 needs to be above 2/3 Vdd to be reliably recognized.
Any practical binary logic scheme is going to have an undefined zone in the middle because the gain of the devices used for the logic is not infinite and there would be problems caused if the gain was too high.
He has done a lot of work on TCP congestion control, especially the fast retransmission idea by using duplicate ACKs.
There is an interesting thing about TCP. A lot of popular TCP implementation use city names, e.g. TCP Reno, TCP Vegas, TCP Westwood.
TCP Westwood is a very interesting implementation. It has very intelligent way to estimate bandwidth, (not just based on duplicate ACKs). You may find this paper very interesting.
1. IPv4 fragmentation & reassembly
2. Centralized (Dijkstra/OSPF) vs. Distributed routing (distance vector/RIP) - stuff you see in Algorithms class
3. TCP mechanisms: congestion control mechanisms that the user can configure (Cubic/westwood/new reno), flow control, retransmission timer calculation (exponential weighted moving average)
4. explicit congestion notification and other add-ons, which can be enabled in the OS by the user
5. Active Queue Management and enabling QoS on your system: stochastic fair queueing for example
6. the recently introduced TCP Fast Open mechanism
7. TCP auto tuning: http://kb.pert.geant.net/PERTKB/TCPBufferAutoTuning
8. Ethernet physical layer: you've left out modulation, and only discussed encoding
9. Multicast and spanning tree protocols
As a student/learning resource, it seems quite steep. Yet, compared to traditional education, it's a screaming steal.
Pricing is hard.
I just think people tend to underestimate the ROI on buying and working through a textbook.
BGP transmits reachability information by building paths of AS that are neighbors. Then, typically, it selects the shortest path of AS hops. (There are a lot of knobs to twiddle with here, both on the advertising side and on the deciding side.)
BGP doesn't care or know about numbers of router hops, just the number of AS between here and there.
There are lots of "network engineer in a box" products that map out performance and then twiddle knobs on your BGP router to select for best performance (or least cost, if some of your paths are more expensive than others.)
Even that's an unfair simplification, though. Cisco has a pretty good page that shows how path choices are made: http://www.cisco.com/c/en/us/support/docs/ip/border-gateway-...
There are products, though, that tweak these settings to pick for best performance, or lowest bandwidth cost.
BGP itself is actually a relatively simple protocol. The complexity really comes from all the available configuration options.
Why is that a better idea than just normal text?
"What I really want to do is tell CSS to make text a certain width, but technology is not yet advanced enough!"
So the benefit appears to be text that is guaranteed to fit a particular pixel-width (minus any anti-aliasing discrepancies among browsers). The cost would be baking one particular OS's font-rendering idiosyncrasies into the SVG-path page titles, but that's partially hidden by the choice of thick bold-faced fonts that hide hinting discrepancies (plus using all caps).
Makes me wonder if one could infer which OS he used to generate the SVG title by converting the text to a path on each platform where Inkscape runs, then comparing each to his SVG title.
So I would guess it's a just a personal preference for that typography that they felt they couldn't get some other way.
The svg images do have correct alt tags with the right text.
Secondly, those can actually be selected with mouse (and copied), accessed by a screen reader and even `innerText`ed.
My guess, that I'd love to see explicitly confirmed, is that it goes back to the internet as the internetwork—lingua franca between existing networks an idea predating the more technically-motivated concept of layed protocols providing compounding abstractions.
I don't want to sound like a nit of an otherwise great piece, but without criticism the history seems inevitable. Alternatives and hypotheticals are good to keep design space from atrophing in the face of collective amnesia.
Since they have to be fragmented back down to 1500 for devices that don't support them, however, it's typically only used in closed internal networks, like a SAN. People typically see about a 5% to 10% bump in performance.
I love this article because of the depth and detail which can be expected of his work, but also because you get all the way to the last sentence before he reveals the question which inspired him to do the deep dive.
So if you are enjoying this article consider purchasing a subscription and supporting more work like this.
You can share this article! This URL can be posted anywhere you like, including in public. Anyone clicking on it can read the article without logging in. The URL is specific to your subscribed account, but no one outside of Destroy All Software can identify your account simply from the URL.
> This article is part of The Programmer's Compendium.
> You can get access to the full Programmer's Compendium by subscribing to Destroy All Software.