How movie/TV watching has changed

▼ Back in the 1990s, for a good number of years, I would go to see the "sneak preview" every week. One show a week would be dedicated to showing a movie that hadn't been released yet. And which movie would be a surprise. This meant I ended up seeing all big ticket movies, as well as a good number of additional smaller movies. And with rare exceptions, I would be happy to sit through them.

These days, I very often find myself getting bored with a movie that I'm watching. Now obviously a lot has changed in the intermediate almost 30 years. Have movies gotten worse? I'd say they have. But not so much that this explains me happily watching pretty much any movie in the 1990s vs getting bored by about half of them in the 2020s. Do we have a shorter attention span and more distractions today than we had 30 years ago? Again, yes. But I don't think that's the full explanation.

I think the reason it's so hard to focus on any movie or TV show/episode is that we have so much more choice today. Back in the 1990s I would have a choice between maybe a handful of movies that seemed decent prospects. Or when watching TV, there were about a dozen channels with limited VCR-based time shifting. So unless something was completely terminally boring, we'd sit through it.

These days, I subscribe to three streaming services and I have around 100 movies and TV show seasons on DVD. So how much time should I give a movie or TV show before giving up and giving something else a try? Definitely not the full 90 (or 140...) minutes for movies. For TV shows, why would I give something with a poor pilot a second chance? "Slow burn", sure, have me waste hours and then decide it sucks. I don't think so.

The grass is always greener on the other side.

Or is it? Should we give our content more time to grab our interest?

Back in the 1990s and before we definitely gave boring and/or slow content too much of our time. It seems obvious we went too far in the other direction these days. But where do we draw the line?

The past few days I watched "No Time to Die" and "The Age of Adeline". The former is a bond flick which was way too long. There was definitely some good stuff there, but 2 hours and 43 minutes worth. With "The Age of Adeline", everything was slow to begin with and didn't pick up speed later. The science fiction element where we ask ourselves what happens if you grow older but physically stay young forever are interesting, but handled in a boring way.

In these days where hundreds of other movies and TV shows are competing for our attention (not to mention video games), being boring is a deadly sin. I finished both these movies by ignoring the sunken cost fallacy, but in retrospect, I should have bailed out at some point.

Two things that don't help here are the increasing length of blockbusters. I recently saw Schindler's List at 3:15. It was painful. I needed a bunch of 25-minute sessions to get through it. Yes, because of the subject matter. But also the length.

Permalink - posted 2024-02-19

BGP handling of obscure errors

▼ I read Ben Cartwright Cox' (extensive) blog post Grave flaws in BGP Error handling and then saw his talk about the same topic at NLNOG on Youtube.

The necessary background

In addition to the "well-known" BGP path attributes that we all know (because the RFC says we must) and love (because they make the internet work), it's also possible define new attributes to provide new functionality. These can be "transitive" attributes, which means that a BGP router that doesn't recognize them propagates them to its BGP neighbors unchanged.

The ability to create new optional transitive attributes has allowed us to run BGP version 4 for three decades without having to bump the version number because we had to make backward-incompatible changes that would make adoption all but impossible.

For instance, 32-bit autonomous system numbers were added as the 16-bit BGP AS numbers started to run out. In addition to the well-known (mandatory) 16-bit AS path, an optional 32-bit AS path was added. If a router in the middle didn't understand the 32-bit AS path, it would update the 16-bit AS path and propagate the 32-bit AS path unchanged.

The next 32-bit capable BGP router can then add back the AS numbers from the 16-bit path that are missing from the 32-bit path, and 32-bit AS numbers work even if routers in the middle don't understand them. (They just see "23456".)

Of course you can read all about BGP attributes in my book Internet Routing with BGP. It's even in the sample chapters! (Page 15.)

The error handling issue

In Ben's blog post, he talks about a Brazilian network included a malformed version of a still experimental attribute. All the big routers in the core of the internet don't run experiments, so they just saw an attribute they didn't recognize, and propagated it as per the transitive setting. Eventually BGP updates with the broken attribute arrived at routers that did understand the attribute, but saw that it was broken.

So as per the original BGP spec, they tore down the BGP session towards the router that sent them the broken attribute. And then, after a short delay, tried to set up a new BGP session towards that neighboring router. Only to encounter the same error again and tearing down the BGP session again. And so on.

Which is probably not wat you want. Which is nicely explained in RFC 7606, published in 2015, which suggests to treat such errors as if the neighboring router had asked to withdraw the route containing the offending path attribute. So if a neighbor tells me prefixes 10.0.0.0/8, 172.16.0.0/12 and 192.168.0.0/16 are reachable through them, and 172.16.0.0/12 has a broken attribute, I just act as if my neighbor had told me that 172.16.0.0/12 is not reachable through them. But I don't bring down the BGP session so 10.0.0.0/8 and 192.168.0.0/16 remain reachable through the neighbor in question.

Ben seems to be rather annoyed that many router vendors don't implement the RFC 7606 behavior, implement it but don't enable it by default, and/or don't have a bug bounty program to reward security researchers for pointing out these deficiencies. He spent a good amount of time evaluating different implementations and then "fuzzing" attributes to see what would happen, So that's somewhat understandable. Here is his score card from his presentation slides:

My take

I agree that the RFC 7606 handling by default is what you want. I also agree that changing a default here, something router vendors loathe to do, shouldn't be problematic.

However, these are pretty obscure errors. This is not an internet extinction level issue.

For my own network, I would strongly prefer a mechanism to turn off handling of these often rather frivolous new attributes. Both to avoid being bitten by buggy implementations elsewhere, but also to avoid inflating BGP messages. As BGP updates propagate, the AS paths (the 16- and 32-bit versions) increase in length, so an update that was just under the limit at some point will exceed the maximum size of 4096 bytes at some point, and then definitely bad things will happen.

However, it's important that new transitive attributes aren't filtered out wholesale, as that would make it impossible to add new features to BGP. I'm not sure if there is a workable way to put a stop to frivolous BGP path attributes being injected into the global routing system while at the same time not robbing BGP of its forward compatibility with future new innovations.

Permalink - posted 2023-10-02