Why the internet only just works (2006) | Hacker News Reader

Why the internet only just works (2006)

fermatslibrary.com

198 pointsllamport84 comments

As one of the early workers on network congestion, much of what he says is right. We really have no idea how to deal with congestion in the middle of the network. The best we can do is have more bandwidth in the middle than at the edges. Fortunately, the fiber optic and hardware router people have done so well at providing bandwidth that the backbone has mostly been able to keep ahead of the edges.

We never dreamed of a connection with over 10,000 packets in flight. Cutting the congestion window in half on a packet loss and ramping it back up one packet at a time was something I came up with around 1984. That does need to be rethought, and it has been.

Hopefully HN readers know that Animats is the inventor of https://en.wikipedia.org/wiki/Nagle%27s_algorithm

I must admit that spending time on NH is like spending time on usenet of old. You never know who will show up to discuss a topic.

:o. I didn't. Thanks!

Every time he posts we identify him as the author of Nagle's and someone that's done pioneering research in TCP/IP.

It would be great if HN had some sort of annotation for distinguished commentators.

We would have the same problem as the black bar. But this is a great(?) idea for a browser extension...

But not everyone would have the extension.

Isn't that precisely the point, though? If you want it, you can have it. If you don't, then you aren't bothered by it.

So schoen's comment should become

"Hopefully HN readers ++without the famous chrome extension++ know that Animats is the inventor of https://en.wikipedia.org/wiki/Nagle%27s_algorithm"

...

Reminds me of snooker i.e. "and for those of you who are watching in black and white, the pink is next to the green"

No, it should become "". Animats has his name in his account's "about" for anyone who's interested, and if we had an extension, anyone could annotate the account name as they please. Anyone who isn't interested might not care who's commenting anyhow.

When someone's identity is pertinent, it seems like they tend to state it eventually anyhow.

What is the black bar?

When someone "notable" in the tech community dies, sometimes the staff adds a small black bar to the top of the layout.

They never mention whose death it's meant to commemorate, though, you're just supposed to know.

Usually the news about that death are on the front page, so it's easy to figure it out...

It must not be that easy (or intuitive,) since every time it goes up someone posts a thread asking what it is and what it's for.

edit: and now that I think about it, a thread is a far more fitting memorial for someone than a minor alteration of the stylesheet, so why even have the black bar to begin with?

> It must not be that easy (or intuitive,) since every time it goes up someone posts a thread asking what it is and what it's for.

I'd say it's a feature. HN is a place with its customs, some of them are not documented and you get to learn them as you participate.

> why even have the black bar to begin with

For the same reason people wear / display black ribbons.

I like the extension idea. Actually, I'd really like to see reading tools which addressed a number of end-user needs:

1. Tracking content stats: how much have I read today, how does this compare to trend, what is my trend?

2. Some sort of "spendable ratings currency" that would indicate quality of an item. Ideally that would be some sort of compound metric. Time, commentary, re-shares, multiple re-visits over time, references in other items (from others, from you) as part of that. Also perhaps a specific metric of how good or bad something was (probably on a 5 or 7 point scale), though I'd tend to discount that. Flags for problematic content (bullshit, clickbait, etc.) These are only personal interest metrics. At best they'd be shared with a few trusted friends.

3. Attribution and reputation tracking by both author and publisher. Find someone whose stuff is really, really good, though they publish rarely? Note that. Find someone who couldn't tell a black eye if you gave them one? Note that. You'd end up with a set of ranked sources by quality and credibility.

4. Filters / indicators to note content's likely quality. Based on previous reputation.

5. A tagging / classification system. Having thought about this a lot, I'm inclined to go with an extant ontology, probably the USLOCCS, as that's been developed, is widely used, and isn't constained by IP restrictions as Dewey Decimal is. (USLOCCS: U.S. Library of Congress Catalog Classification System).

6. Uniform presentation + user editing. A Readability / Pocket like standard page presentation model. The ability to edit that (either in stock ways or specific elements) to further clean it up. Export to other formats (ePub, PDF, text).

7. Page annotations. I want to be able to keep notes on things.

I find it curious that the Web today is so metrics driven, but nobody has saw fit to provide metrics to end users themselves.

One thing I always wanted for HN extension (and regularly think about writing) is notes attached to users. I'd like to be able to note down stuff about a particular user (like, "that Cloudflare guy; knows a lot about DNSSEC", or "that rocket scientist from NASA with interest in birds", etc.), and have them easily viewed later by e.g. hovering over their name.

G+ in one of its many failed implementations had something vaguely like that. It was overloaded with Gmail contacts, and resulted in G+ profiles being added to your mail-related address book.

Since I was using this in large part (though not exclusively) to keep tabs on annoying gits online, this was a less than salubrious "feature". Sigh.

Reddit + RES offers tags. I'll note specific individuals, here usually focusing on clueful. Though it's limited to a word or two, and isn't inherently shared across systems (RES uses local storage).

But yes, generally, this is another of those "why aren't Web developers providing users with a pretty obviously useful tool". It's more than clear who's paying the piper here, and it ain't us.

Apparently we do, it's just sort of... manual.

I'm actually kind of happy with it how it is now.

Reading the comment without knowing the commenters "notability" let's the comment stand on its own. After the comment I can read that the person did X or Y.

But having the comment distinguished somehow would give it more "weight" than it necessarily deserves. After all, just because someone is notable doesn't make them infallible.

I wonder how you deal with remarks made by known people in real life where there isn't this obscuring mechanism. If you have a plan to deal with that, the same can be applied here.

Personally, having a "blue tick" like thing for distinguished posters is helpful psychologically as it reassures me that I am not reading comments by newly minted young adult or a 20+ years experienced person doing mostly rote work. Now, there is nothing inherently bad about comments made by such posters, just that it would be far more reassuring to know that a poster is, hopefully, bringing in his publicly acknowledged experience into what he is saying, especially on topics in which that person is known for. To make it clear, they could even be a 20 something distinguished person! The point is not about age but about accomplishment.

If it's important to the conversation, the commenter can point out their own past experience (which Animats did by saying "As one of the early workers on network congestion").

Just because it's difficult to remove the "person" from the "message" in face-to-face conversation doesn't mean we can't strive for something better online.

I have a very relevant example! A few days ago I was reading a comment here about someone that drinks tap water and how (anecdotally) they are fine, and they didn't understand the craze with bottled water. Being completely honest, I made a "mental picture" of him as a mid 20's "hipster" silicon-valley type. And I agreed with his overall message. But halfway through his comment, he had a link to his "beverage container of choice" that he drinks water from. I read the whole comment before opening that link. I had assumed that it would point to a glass and leather "artisan" water bottle... The link pointed to something similar to this:

http://assets.suredone.com/1766/media-photos/sd009014-vintag...

After opening the link, my whole view changed. Suddenly that "mental image" changed into a mid 40's overweight sysadmin, and (as much as I'm ashamed to say it), I suddenly "trusted" their message less...

I realized what had just happened, and I realized that just thinking I knew who this person was affected my thinking. If I had known that person's age, size, gender, profession, etc... Would I have given their message a second thought? Honestly I don't think I would have. And that makes me feel like shit. I have prejudisms (is that a word?) that I don't consciously know I have, and if possible I'd like to not apply them. Reading HN comments as faceless-nameless comments helps me read the message with none of that "baggage". And if I later read about the person behind the comment (and learn that it's not what I expected), it can go a long way toward reducing the prejudice that I may have that I don't even know I have.

It seems we have quite different ways of looking at things, so it would be futile, and honestly unnecessary, to debate on that.

> If it's important to the conversation, the commenter can point out their own past experience (which Animats did by saying "As one of the early workers on network congestion").

This is basically what I was trying to convey. By making it known via some mechanism, HN would help posters from repeatedly posting their credentials before saying something deep and insightful or unpopular. A mechanism that isn't obvious, as in a button that makes something else visible that shows something about a distinguished poster, would benefit both parties I think.

> prejudisms

Are you looking for "prejudices"?

> it reassures me that I am not reading comments by newly minted young adult or a 20+ years experienced person doing mostly rote work.

What does that matter, if the comment is good? Nothing is inherently bad about those comments, just like nothing is inherently good about others.

Rather than a blue tick in the comment thread, it might be useful to have something like that inside their user profile. For example, animats has "John Nagle" in his "about" field. Having the information available but not initially visible might be valuable to help support claims like "As one of the early workers on network congestion" without coloring the interpretation of statements outside of his area of expertise (basically, avoiding attaching an "argument to authority" fallacy to every celebrity-posted comment).

edit: Bah, just saw your later comment where you suggested a similar mechanism. Sorry.

You quoted me "it reassures me that I am not reading comments by newly minted young adult or a 20+ years experienced person doing mostly rote work." and said "What does that matter, if the comment is good? Nothing is inherently bad about those comments, just like nothing is inherently good about others."

I can't believe you were so eager to respond to me that you didn't continue reading my post. I answer your query like in the very next sentence.

I read the whole post several times before responding, and re-read over parts of it while responding. I just don't think that you provided a well-justified reason. Why is reassurance a good thing? That seems like it'd imply that you're relaxing your guard when considering their opinion.

> I just don't think that you provided a well-justified reason

I was implying something like why reading something from a textbook is better than a random answer on reddit or yahoo answers. Mind you, I am talking about posters talking about specific things, not giving opinions on a variety of things, which is why I mentioned "topics in which they are known for".

> Why is reassurance a good thing?

I prefaced my post with "personally" specifically to avoid this line of discussion. It is a personal perception, and as I said elsewhere it is futile to argue about perceptions. The answer is, it just is.

> That seems like it'd imply that you're relaxing your guard when considering their opinion.

That's reaching.

Sounds like an interesting story, you were working with Van Jacobsen, and made the suggestion to him? (since he's usually credited with that form of congestion control, folks might appreciate a little more explanation).

Was there an unstated assumption that packet sizes might scale up with network speeds? (and not get trapped at the original 10mbit ethernet frame size as it turned out). Today we send teeny micropackets relative to link speeds, and increasing by one packet at a time is (in retrospect) a weird outcome. But like Chesterton's fence, it's nice to know how it got there.

See RFC896, "Congestion Control in IP/TCP Internetworks" (1984) [1] and RFC 970, "On Packet Switches With Infinite Storage" (1985).[2] I wrote both. The first one introduced adjusting the offered window based on congestion. The second RFC introduced "fair queuing" and "congestion collapse". I coined both terms.

Back then, there were ICMP Source Quench packets, which told the sender to slow down. We used those, but Berkeley didn't, and they eventually were abandoned.

The second paper is more philosophical. Back then, the big issue in networking was running out of buffers. Memory was expensive, and everything had tiny buffers by modern standards. Running out of buffer space had been a big problem in the ARPANET, and the original ARPANET protocols focused on not running out of buffers. (The original ARPANET had hard backpressure - if there wasn't enough buffer space in the network nodes, you couldn't send. Packets were never dropped for congestion reasons.) I pointed out that even with infinite buffer space, congestion was still possible. This is now conventional wisdom (see "bufferbloat"), but back then, it was a new idea.

The other new idea was viewing congestion as a closed-loop game theory problem. See the section "Game Theoretic Aspects of Network Congestion" in RFC970. Today everybody involved with networking traffic management thinks about router strategy and end node strategy interacting. But classical queuing theory was about stochastic arrival rates. The classic paper back then was Kleinrock's "Message delay in communication nets with storage"[3], which is considered part of the theoretical underpinnings of the ARPANET. Kleinrock also wrote the classic text on queuing theory. But Kleinrock wasn't studying the ARPANET; he was studying Western Union Plan 55-A, a distributed message switching system. (Think of a system that works like email forwarding over fixed links, with lots of forwarding. Plan 55-A was like Sendmail, built out of paper tape punches and readers and phone-type switchgear. A switching node was a large building.) Plan 55-A had no influence over the rate at which people submitted telegrams. That model didn't consider behavior of senders (end nodes) at all.

So looking at the problem as a game-theory problem was new. Somehow, the network had to not reward the sender who sends the most. A FIFO queue rewards the sender who sends the most. (Hence "bufferbloat", which is what happens when you have a huge, dumb FIFO queue.) That leads to everybody over-sending, long queues, and many dropped packets. So I devised fair queuing, with a queue for each sender, to eliminate the reward for over-sending. If you're sending into a fair router, your optimal strategy is to send just enough that your own private queue has 1 or 2 packets. Now the job is to make the end node (at the TCP level) try to do that. Hence congestion windows and other forms of end node traffic shaping.

I got out of networking in 1986; I was involved with a startup doing something else. So I was out of this before Van Jacobson really got into it.

[1] https://tools.ietf.org/html/rfc896 [2] https://tools.ietf.org/html/rfc970 [3] https://dspace.mit.edu/bitstream/handle/1721.1/11562/3384053...

I just wanted to chime in and say thank-you. Your technical answers are always very interesting.

Yes, John's work is seminal, and fair (flow) queuing is essential in cleaning up the bufferbloat mess. Flow queuing has a bigger effect on end user experience than mark/drop algorithms to signal TCP (though that is also needed to keep TCP from losing its mind). I distinguish flow queuing from fair queuing as it has aspects that are not "fair", but the fundamentals are the same.

The recent BBR work at Google is another key to solving bufferbloat.

I finally think we have the tools needed to really solve the problem, between flow queuing and new mark drop agorithms (e.g. Codel, CAKE, PIE, fq_codel, etc.) and BBR.

So again thanks to John for his key work.

Jim Gettys (who coined the word bufferbloat).

What feels comfortable now is going to feel uncomfortable in like a decade. Especially if VR stuff begins to hit. The abominable Comcast is already enacting data caps, maybe due to limits already being reached.

"Cutting the congestion window in half on a packet loss and ramping it back up one packet at a time was something I came up with around 1984"

We can call you the Saw Tooth Guy, or the Additive Increase Multiplicative Decrease Guy. We'll let you pick.

Interesting to see this paper making HN. I think it has stood the test of time reasonably well - it was written in about four hours one morning under rather unfortunate circumstances - I was stuck on a train that hit a vehicle at a crossing.

I'm interested in what HN folks think has changed. What are today's urgent problems, and what are just annoying ones that will cost time and money to work around, but aren't critical? How do they differ from those of 10 years ago? Arguably, some I discussed back then have only grown in importance, with no solution in sight - for example, DDoS attacks. Whereas some, like address space exhaustion, look like being adequately addressed, as IPv6 is finally rolling out (only took 20 years!).

I'm wondering if your opinions on the difficulty of introducing new protocols have changed over the past decade. For example, Bittorrent has taken off, and while I used to have to manually configure ports on my NAT to allow Bittorrent to pass through, I no longer need to do so. Universal PnP seems to have taken care of that (at the cost of some security).

STUN/TURN/ICE have enabled NAT hole-punching to become fairly reliable, but the complexity involved is horrible. Try reading RFC 5245 and its companions - this isn't a sane way to design an Internet. It does work though.

New protocols are still an issue, but the problems differ depending on whether we're taking about the transport layer or the application layer. We've tried and largely failed to deploy alternatives to TCP and UDP. My effort, DCCP, for multimedia traffic is dead in the water due in part to NAT/Firewall traversal problems, and is now essentially tunneled over UDP. SCTP is successful in some limited circles, but you're very unlikely to see it end-to-end across the Internet for the same reasons.

Even TCP is really hard to extend. If you're interested, we did some work on this a few years ago: http://www0.cs.ucl.ac.uk/staff/M.Handley/papers/extend-tcp.p... It's amazing what some middleboxes do to TCP.

At the application layer, it's somewhat easier. You can deploy new protocols over UDP, as BitTorrent did and as Google has done with QUIC, and they'll work in most places, but you'll still need a fallback. The universal fallback these days seems to be to tunnel over TLS on TCP port 443, because that's rarely blocked. The fact that we need to do this is an admission of failure on the part of the Internet architecture. The fact that it just about works is the reason we've not needed to address the underlying problem, which is the tension between security and extensibility.

Security, if you ask me.

No disagreement there - see our work on standardizing tcpcrypt in the IETF tcpinc working group for our attempts to improve one small corner of this space. https://datatracker.ietf.org/wg/tcpinc/charter/

Did anyone think about applications with time-sensitive arrival back then (e.g. VoIP), and have any implementation ideas that never made it out the door?

I've been working on VoIP and Internet multimedia since 1991 (I'm one of the authors of SIP, for my sins) so, yes, we've been concerned about time-sensitive material for a long time. From a standards point of view, this resulted in first, Interv and RSVP, then diffserv. The former largely failed, mostly for economic reasons, while the latter is widely used, but almost never for end-to-end service, again for economic reasons. Basically, if you're going to give priority to some traffic, there needs to be a disincentive for all traffic to demand priority, which usually means charging. No-one ever figured out a good economic model for end-to-end QoS, and most users aren't willing to pay extra anyway.

There has been a lot of effort more recently on sensible queue management schemes to avoid buffer-bloat, which show significant promise. For low-speed customer links, variants of fair queuing generally work well. My ISP, Andrews and Arnold, is one of the few that really gets this. They have a shaper, upstream of the DSL or FTTC link, that can be configured to 95% of the negotiated link speed, so there are no queues downstream. Then they run fairly small buffers in the shaper and WFQ. I pretty much never see any significant latency on my VoIP calls due to queuing.

In general, low-latency VoIP shouldn't be a problem - so long as the data rate is lower then the rate of the mean flow on a link, you can give it strict priority service without harming the other traffic. In practice, this requires some sort of policing to avoid abuse. Various forms of fair queuing approximate this - a flow that has a low data rate will be serviced frequently (though not as quickly as it it had priority), and see pretty low latency in the queue on a busy link.

Now, getting low latency for high quality video conferencing; that's a different question. Fair queuing doesn't really help, because the data rate can be relatively high. Instead, you've got to keep the total queue size small. This can impact competing TCP flows if you're not careful, and can cause non-negligible packet loss. Thus is due to TCP's congestion control dynamics - throughput of a TCP flow is inversely proportional to round trip time, and inversely proportional to square root of loss rate. If you reduce queuing at the bottleneck, you reduce RTT, so push up the loss rate. This is one of the reasons people gripe about TCP's congestion control. However, if ECN were widely deployed, this would become a non-issue, because we wouldn't need those packet drops to control TCP's sending rate. Generally, widely deploying ECN would be the single biggest enabler for low-latency networking.

Wow thank you - I was not expecting such a quality answer, this is wonderful information that will take me on further research tangents. I thank you very kindly for your time.

The fragility of BGP is one area that I have been concerned about for some time. We have already seen instances of misconfiguration that black hole entire countries, but if someone wanted to bring down the Internet intentionally they could do a lot of damage with just a few hacked ISPs.

Net neutrality is one of the problems that wasn't envisioned (at least in your paper) 10 years ago.

DDoS problem becomes pressing now with the emergence of IoT. Still no general solution though.

Thanks, for me this was mostly another illustration how to make a website that doesn't.

Please give me at least a chance to get a plain pdf (or html) that I can read (and click into) without content bumping forth and back and my computer grinding to a halt.

This seems a bit harsh. As far as I understand the purpose of this website is to make papers easier to understand. I think it accomplishes that. They are not even trying to show you ads. how are you helping?...

Also, they might have restrictions about distribution of papers. Youtube also doesn't have a download link next to every video.

It might sound harsh to you, but you'd feel differently if you sat in front of my computer. Each misclick costs me 1-2 seconds of layout recalculation (100% on 1 core). For reference, my computer is AMD X250 from ~2011, 4GB RAM (enough), and running Firefox on Debian 8.

Using chromium it's a tiny little quicker, but still annoying. They could easily stop the content bumping and the darkening "please subscribe" overlays.

sure. talking to people on the internet only just works...

This was probably a witty reference to the article. Can't appreciate it since I can't bring myself to suffer the website...

well I have a mbp late 2013 and it costs me 1-2 seconds (16 gb ram and core i7 3rd gen...)

Try disbling Javascript, I disabled it by default and the site is really fast for me and I can read the document just fine. I enabled JS and have to agree that now it is pretty sluggish.

I don't understand the need for expensive animations or the imagined use case of opening/closing the comments sidebar a hundred times while reading the paper. Why does opening one note hide all indicators of other notes? (It seems if you're reading at above ~1500px browser width, it shows them as small dots, but removes the preview text of the note). I should just be able to leave it open and have new notes/comments appear as I scroll past the relevant section.

Why does clicking anywhere on the document, or highlighting any text open up a "write a new comment" sidebar? Do they really think there are going to be more users writing comments on a paper than there will be copy-pasting a few sentences from it?

It feels like the primary purpose of the site is for users who want to comment on papers, and not users who just want to read papers. For the latter group, it's a really poor experience.

With all due respect, perhaps it might have been interpreted as harsh, but what was noted above is no less true.

I'll acknowledge there is not an overload of ads being displayed with the paper, which is cool. Also acknowledge that there certainly might be restrictions for distributing papers (a separate, possibly inflammatory topic)...but have you tried doing something as simple as printing the paper? On Chrome (windows machine) it prints out so disjointed as to diminish one's interest in reading the paper (offline of course). I just want to print this out and read it on the train ride home. I guess the intent of the site is ideal, but execution is less so.

It printed mostly fine for me (mac, chrome). It did not print the comments, which to be honest I'm not even sure about how you would go about showing the comments (which are often very large) in a printed page.

"Thanks, for me this was mostly another illustration how to make a website that doesn't." - sounds pretty harsh to me.

Well, but the site just doesn't. Not harsh, just truth.

I was unable to read the paper because an unclickable modal kept popping up asking me to subscribe.

The implementation is plain broken. I can't scroll at all with my trackpad. Every time I click anywhere, a "Comments" window stutters out from the left side, and takes a few seconds to retreat next time I click.

Ignoring any arguments about tone, I also agree that not providing at least a link to the actual paper is a puzzling omission. If the goal indeed is to aid paper comprehension, limiting the ability to read it is a weird choice.

And not the gp, but I'm not "helping". In fact, I have no idea what I'm supposed to take away from you having asked that question.

I loaded it up on my mobile page to see what I thought was a PDF reader opening up to find it was a browser with PDF covering the whole page grayed out with a little box at the bottom-right with a little X or something. I can't remember as I closed the page immediately. It was maybe the 2nd time I've seen something like that used. I knew someone would post an actual link to the PDF or a site less broken in presentation.

So, yeah, it was an unusually, negative experience on mobile.

It also have comments pane which takes half of the screen (with non working X button) and hijacks back button (firefox on android).

It is really that hard to just serve PDF instead of stupid javascript filled browsers.

> It is really that hard to just serve PDF instead of stupid javascript filled browsers.

Well, the entire point of the site is a collaboratively annotated journal article. You may not think that's interesting, or that it's feasibly implementable with current tools, but I think the folks do a pretty good job with their stated goal. So I think this is something to be left up to the HN voting.

For those looking for PDF, it is at the author's site (http://www0.cs.ucl.ac.uk/staff/M.Handley/): http://www0.cs.ucl.ac.uk/staff/M.Handley/papers/only-just-wo...

As an aside, our server may well be the oldest still running on the Internet:

  telnet www0.cs.ucl.ac.uk 80
  Trying 128.16.6.8...
  Connected to haig.cs.ucl.ac.uk.
  Escape character is '^]'.
  HEAD /staff/M.Handley/ HTTP/1,0

  HTTP/1.0 200 Document follows  
  MIME-Version: 1.0
  Server: CERN/3.0
  ...

Proudly running CERN 3.0 on a Sparc 20 continuously since ~1993.

Continuously as in No Downtime or as in you've just been using the same machine that long?

That's... gonna depend on how popular a certain HN post becomes...

Good answer. The Slashdot Effect delivered by its best alternative. ;)

Welp, here we go.

It has definitely been down occasionally - the odd power outage guarantees that in 23 years, and it doesn't really merit a UPS. Also I think it's on its second Sparc box, but our sysadmin has a pile of old spares. And it had to be patched to be Y2K-compliant, as the CERN 3.0 httpd was last updated in something like 1994. It is definitely slow compared to modern systems, so it's no longer our main webserver, but it still handles the occasional HN load spike reasonably well.

That's along lines I was thinking. Haha.

Agreed this is just awful

Oh man, I emailed the creators a year ago when they first released the site, encouraging them to make the frontend open source so the performance and layout issues could be fixed by the community (including myself, there are some easy bug fixes I wanted to submit). Back then, they were still deciding what the direction was going to be for the library. A year later, it seems they've opted for the closed-source, no improvements path unfortunately.

I still subscribe, since the papers are interesting, but the website needs some love.

It worked fine with NoScript -- which is a good way in general to hide from the madness of the modern Web.

The author (Mark Handley)'s other publications:

http://www0.cs.ucl.ac.uk/staff/M.Handley/papers/

Some very good reading.

Looking at it from a network protocol level is one view. From another perspective the internet (whether ipv4 or v6) is a complicated set of peering relationships between ASes and business entities. It takes clueful and experienced people with "enable" on the core and agg routers who also understand the economics of transit, peering, IXes, transport, dark and WDM systems to build a proper ISP.

The internet is only as fragile as you build it. I have seen too many ISPs running really important stuff through POPs where everything is 1+0.

Article is from 2006.

And? It's still a very good paper. Age doesn't change that.

First of all, the internet has changed in the past 10 years.

Second, it's best practice here to put the date in the title for old articles.

> First of all, the internet has changed in the past 10 years.

Not much. We're still using TCP/IP, BGP and NAT. Web-standards may have evolved, but the internet is still the same, except for the average link being 10x faster now.

> Second, it's best practice here to put the date in the title for old articles.

I agree.

If you think the internet is the world wide web as well, then sure, it's changed a lot.

But the actual internet infrastructure is still the same, this paper discusses the protocols and architectural problems. I challenge you to name something that has changed. Even IPv6 was formalized 15 years ago.

One of the WWW things that has changed, maybe not Internet technology specifically: if you are a business that moves very large volumes of packets, it doesn't matter that you have plenty of upstream bandwidth because the residential ISPs will refuse to upgrade their equipment on behalf of their customers. See: http://www.businessinsider.com/netflix-comcast-deal-explaine...

Does TCP Fast Open count?

In the early web days (mid-1990s) Bob Metcalfe(invertor of Ethernet) humorously the internet would collapse any day from increasing traffic. Aint happened yet.

Despite recent best efforts to the contrary by level3...

Wow! 42 comments on an article titled, "Why the internet ONLY JUST works" (emphasis added), and the word "security" occurs once, and the words "malware", "privacy", "malicious", "ransomware", "hack" and "cybercrime" don't show up at all.

Is there another internet out there that I don't know about? If not maybe the title should be "Why the internet only just stinks"!

Reply on news.ycombinator.com