Re: Metcalf and Other Net.Fogies
perry@piermont.com writes:
Alan Olsen writes:
Metcalfe may have a valid prediction here.
Metcalfe is talking out his ass. He's reached the "old geezer who's impeding his own field" stage. Many of his articles seem to be written as though no one was trying to fix problems.
Well, having talked with people involved with the problems I can assure you that they are real. The net brownouts when MAE-East dumps its BGP core or the fact that when one of the NAPs upgraded to FDDI it soon found that by the time people had installed the upgrades to the routers the bandwidth was already saturated should indicate that there are problems. Most of the problems are in the routers, even the top of the line Cisco boxes can only handle so much. The sky is not falling, but these sorts of problems are cracking the whip behind IPv6 and pushing the companies that make the routers pretty hard (Have you ever tried to buy even a lowly Cisco 2401? Do you know what the wait is on delivery? I really wish I had bought Cisco stock earlier...)
When I run traceroutes, the blockage is in MCI or Sprintnet land.
How do you manage to determine where you are losing bandwidth using traceroute? That must be a mighty powerful traceroute to do that -- most traceroutes I've seen are hard pressed just to find out what the connectivity path is.
Then you should probably upgrade your traceroute, preferably to one which allows source routing of the packets and then couple the output to a nice udp source routing script which will bounce a few packets between links with slow response times. Most of the problems are at the exchange points where packets go from one company's network to another. It seems that users have the annoying habit of wanting to talk to other people's customers...imagine the nerve :)
The bandwidth to the net has been oversold.
Always the case. Big deal. Bandwidth is still increasing pretty fast. There are, naturally, growing pains, but the outages and bandwidth situation are pretty good, all things considered. Compared to the way things were eight or nine years ago they are amazing; compared to four years ago they are still astoundingly better.
Bandwidth may be increasing quickly, but demand for it is increasing even faster with every moron wanting tose the web while the routers to hook it all together and make it work are still very expensive and not being produced fast enough to satisfy the demand. Compared to the way things were even a few years ago the aggregate bandwidth that one person can expect is decreasing, it seems that no one writing internet protocols passed an Intro to Sociology/Poly Sci course and assumed that the tragedy of the commons did not apply to them. The upside of all of this is that it is creating a demand for value-added services which offer users dedicated bandwidth and faster response time in return for a little coin. This will probably push micro-currency on to the net faster than any other consumer demand... jim
Jim McCoy writes:
perry@piermont.com writes:
Alan Olsen writes:
Metcalfe may have a valid prediction here.
Metcalfe is talking out his ass. He's reached the "old geezer who's impeding his own field" stage. Many of his articles seem to be written as though no one was trying to fix problems.
Well, having talked with people involved with the problems I can assure you that they are real.
I'm "involved with the problems" too, you know. Don't teach granpaw to suck eggs. OF COURSE there are problems. None of them, however, are signs of "collapse". As a certified Network Old Fogie, I can tell you about the time the Arpanet decided to die because of a bug in the IMPs... and then there was the day that the backhoe took out *the* line between the east and west coasts... and then there was the time in the 80s before Van J's algorithm where congestion was nuking everything in sight... and then there was... Look, there will *always* be trouble. The question is whether or not "collapse" is something imminent. The answer is "no". Stuff will get better, it will get worse, but the overall trend is better, and collapse just isn't in the cards. Metcalfe talks about stupidity like how there aren't enough "suits" running the net -- as though people in suits do better engineering than the folks we've got. Metcalfe talks as though no one is trying to fix the trouble. There already *are* people working hard trying to fix the trouble, and they know a lot more than he does.
When I run traceroutes, the blockage is in MCI or Sprintnet land.
How do you manage to determine where you are losing bandwidth using traceroute? That must be a mighty powerful traceroute to do that -- most traceroutes I've seen are hard pressed just to find out what the connectivity path is.
Then you should probably upgrade your traceroute, preferably to one which allows source routing of the packets and then couple the output to a nice udp source routing script which will bounce a few packets between links with slow response times.
That doesn't tell you squat about bandwidth. At best, you can find a really bad link that way, but there is no way to quantify the problem, and no way to detect things like how much traffic is hitting that link. The only way -- the ONLY way -- to determine link utilization from the outside is with a management protocol like SNMP. Perry
participants (2)
-
mccoy＠communities.com -
Perry E. Metzger