4 ms·

This argument is broken. An ISP engineer debugging need only look at IP packet drops in their part of the network. If their end clients are asking them to debug

This argument is broken. An ISP engineer debugging need only look at IP packet drops in their part of the network. If their end clients are asking them to debug an issue then they should debug it at the end points, not in the middle. This attitude is what lead them to stick more e and more buffers in the middle and do other shaping devices in the name of problem solving or adding value and ended up ossifying protocols. I think endpoints will evolve to better protocols to solve their own problems if the ISPs stopped putting hacks (like deep buffers) in their networks.

jsnell 8y ago
> This argument is broken. An ISP engineer debugging need only look at IP packet drops in their part of the network. That's just not true in practice, pretty much on any level. First, you need to look at a lot more things than just packet drops (e.g. reordering, queue buildup, corruption). Second, even getting full visibility into your own network is highly non-trivial since nobody has active probes on every link. My experience is that arranging for packet captures from an arbitrary point in the network could take a week. And if you guessed wrong about which node was at fault, you'd need to do it again in a binary search pattern. Third, you absolutely do need to know about things other than your own network. Otherwise you don't even know whether there is a problem you can solve. If the bottleneck is in the server, or the client, or the transit links, there is no point in debugging the core or the access network. > If their end clients are asking them to debug an issue then they should debug it at the end points, not in the middle. The endpoints are not going to be available. Do you think that Youtube is going to give an operator some kind of server access or even insight to the traffic? Do you really want to see a world where a customer having a complaint needs to first root their phone and install packet capturing software? What you're really saying here is that no problem should ever be debugged, and we should just hope that the network doesn't break. And hope is not much of a strategy.

jsnell 8y ago

> This argument is broken. An ISP engineer debugging need only look at IP packet drops in their part of the network. That's just not true in practice, pretty much on any level. First, you need to look at a lot more things than just packet drops (e.g. reordering, queue buildup, corruption). Second, even getting full visibility into your own network is highly non-trivial since nobody has active probes on every link. My experience is that arranging for packet captures from an arbitrary point in the network could take a week. And if you guessed wrong about which node was at fault, you'd need to do it again in a binary search pattern. Third, you absolutely do need to know about things other than your own network. Otherwise you don't even know whether there is a problem you can solve. If the bottleneck is in the server, or the client, or the transit links, there is no point in debugging the core or the access network. > If their end clients are asking them to debug an issue then they should debug it at the end points, not in the middle. The endpoints are not going to be available. Do you think that Youtube is going to give an operator some kind of server access or even insight to the traffic? Do you really want to see a world where a customer having a complaint needs to first root their phone and install packet capturing software? What you're really saying here is that no problem should ever be debugged, and we should just hope that the network doesn't break. And hope is not much of a strategy.