Thanks! It's especially nice to hear from someone who's worked running the infrastructure involved. Can you speak to the general question of whether it might b

Thanks! It's especially nice to hear from someone who's worked running the infrastructure involved. Can you speak to the general question of whether it might be possible/practical to have a useful diagnostic suite that runs from the customer end of a connection? I'm sure that my ability to use traceroute is limited (I know what a TTL is, but I expect I don't have much beyond a pretty vague idea for how that interacts with typical device configurations along a typical route), but the fact that scripted conversations with support often seem to end with a request for some traceroute output makes me think someone at the ISP does find that information useful in troubleshooting (unless that's also an unconnected crosswalk button), and it makes me wonder if automating that among other things and frontloading its use could save time on both ends of the support call, which would seem to provide the right incentives. Also... do you have any insights about the incentives regarding informing customers about already discovered problems? I suppose this touches on my assumption that the ISP doesn't already know about my problem vs the plausible reality that internal monitoring is already going on. I've noticed on a few occasions (primarily back when I was with Comcast, I think?) that when I've called in for interrupted service that they've said "your issue is related to one we're aware of, you can look at this URL to follow our efforts to address it, or sign up for automated updates." That's not the reward that an instant fix is, but it seems to feel pretty good. But it's also apparently rare, which nudges my default perception towards "most of the time the ISP does not already know." Is there a dynamic which means an ISP might reasonably believe it's better off not telegraphing known issues?