I would argue that making your component geographic would not be good, and does not address the core issues with routing. You assume that just because two routers are geographically closer that there exists a 'regional' path between the two, but this is not always the case. It really depends on the TOPOLOGY of the network. Again, the question of how distance is defined becomes key; which is better--distance defined by physical distance, or distance defined by speed to reach the location? Another problem with physical distance (besides ignoring line speed) is that geographic distance is not a real reflection of the actual cable distance (it's never a straight line).
However, trying to keep the traffic within the same region does have merit (region being defined by the topology/network architecture, rather than pure geography), and I would agree with you that this need exists. However, there are mechanisms/theories that have been developed in attempt to address this issue. Rather than re-inventing the wheel, we should look at how these past attempts address the issue, and the problems they encounter.
Some past attempts mechanisms that I'm aware of include:
N.E.T.'s SuperWAN feature for the IDNX (TDM switch). Part of its purpose was to expand the node limitation, but it also kept circuits within a defined domain, and allowed circuits to cross domains only when necessary. A transit domain could be defined by the user to bridge two domains together that were not directly connected.
StrataCom (now Cisco) Domains (ATM switch). It also expanded the node limit. It is similar in concept to N.E.T.'s SuperWAN. I believe it is no longer supported--but I'm not current with their feature sets (I think they were moving towards PNNI).
Ascend (now Lucent) OSPF Area (ATM switch). Terminology has changed from Domains to Areas, but the basic concept for routing remains the same: connections remain within the area, unless the destination is outside the area.
PNNI Peer Groups (ATM). This is supposed to be a more scalable approach to the same concept: keep your traffic within your peer group unless the destination is somewhere outside your peer group.
One thing you will notice with all these methods is that the area must be defined by the user, and is always influenced by the topology of the network. Switches are assigned areas and are only connected to other switches of the same areas. Areas are connected to other areas by a gateway (in most cases, it is a 'special' switch designated as a gateway).
But notice that routing metrics are not applied to keep traffic within the area. Metrics are used to determine 'optimal' pathing.
Adding geographic coordinates are not necessary to address the issue because it should be addressed in architecting the network. The only real contribution geographic coordinates add is as a distance metric--but this already exists (it's in place, and in use--the problem is, is it 'correctly' being used?). Lastly, allowing geographic coordinates adds an additional complexity to router configuration, opening one more door to user error and compliance.
On the subject of network performance, there are 3 major places to look to see where network performance fails:
1. Capacity. There is not enough bandwidth to carry the traffic (ie. my pipes are not big enough). Just because you have big pipes and a lot of pipes does not mean you put the pipes in the right places (a major problem for most ISP's & carriers).
2. Queue. Because your pipes aren't big enough, the traffic must sit wait in a buffer before it has its turn to be sent out over the pipe. Adding more buffer to the queue reduces your packet drops by making your queue bigger--it does not make things get out faster.
3. CPU. Your switch can't handle all the lookups or route calculations or some sort of process. Because it's so bogged, it can't process or switch the packets fast enough. What can you do here? You are limited to the switch you bought.
Most IP-based networks focus on Queue and CPU. The table-lookups and DNS issues are more of a scalability problem, rather than a traffic issue (having too many nodes in the network vs. carrying too much traffic). Most traffic congestion for IP-based networks focuses on better queuing methods (ie. get the more important traffic out first). What is lacking for a vast majority of IP-based networks is the lack of optimization for CAPACITY. Remember, queue only kicks in when capacity runs out. If networks did a good job of placing enough bandwidth in the right places, then queuing would be minimized (example: TDM switches always guarantees capacity (100%), so there is no need for a queue. ATM & Frame Relay 'share' capacity, so a queue is needed when traffic begins to compete for space).
So why don't most networks optimize their capacity? In order to plan for capacity, you need a good idea what your traffic flows are (end-to-end traffic flows. link usage is not good enough). Most network administrators have no clue what their traffic flows actually are, because they are dynamic, very hard to guess, and there are very few good tools out there that can collect this type of information. Most tools on the market simulate queuing, but the traffic generated in the simulation are just guesses (read: no guarantee they mimic real life, much less your network), and this does not address the issue of capacity. Capacity planning tools exist, but they are few, and even fewer work as promised. Cisco is currently working with one company to provide capacity planning tools to IP-based networks, which has promise because it has the ability to extract traffic and network data from the live network. Still, for some reason, most router people are focused on queuing rather than capacity in order to improve performance.
Routing uses the process of receiving a packet and checking its destination. Using a table lookup based on the destination, it finds the the neighboring router it should forward the packet to. The table is updated so that routing can find 'the shortest path.' The real question here is how 'shortest' or distance is defined.
Your method of configuring geographic location on routers is basically trying to get the router to calculate its distance to its neighbors. However, you're thinking about geographic distance rather than logical topology which is the 'road map' that routers can travel on. There are two direct problems that stem from your method:
1. Pipe size (bandwidth) is not accounted for. If there exists two paths to the destination, should I take the 'geographically' shorter path that is connected by a 56K line, or a slightly longer path that consists of several OC3's?
2. Hop count is not weighed. With two paths, the geographically shorter path may travel through 20 routers, where a longer path may hop through 5 routers--how do you determine the tradeoffs?
Most importantly, routers currently have a mechanism to address this routing issue by allowing users to define the distance between routers. I believe this is usually set to reflect bandwidth size (ie. usually people define their OC3's to be shorter than their T1's). This is generally easier for network managers to adjust their link distances than to tweak their lat/lon coordinates.
Most of the problems with congestion I've seen is due to capacity problems--where there may be two different paths to a destination, but one path is over-utilized and another is under-utilized. Currently, routers are very limited in their load-balancing techniques. I believe Cisco routers can balance up to 6 equal paths--but configuring multiple 'equal' paths is not easy for a meshed network (equal as in defined distance). Without equal paths, routers generally send their packets down the 'shortest' path, regardless of congestion. Routers are not intelligent enough to recognize congestion and calculate the 'next shortest path' (though 'next-shortest' paths are done when there is a link failure). Without this type of mechanism, if you were to get the router to use the 'path of least resistence,' it would just shift the congestion from the previous route to your newly defined route. Currently, the MPLS initiative is trying to address this capacity issue.
Slashdot Mirror
I would argue that making your component geographic would not be good, and does not address the core issues with routing. You assume that just because two routers are geographically closer that there exists a 'regional' path between the two, but this is not always the case. It really depends on the TOPOLOGY of the network. Again, the question of how distance is defined becomes key; which is better--distance defined by physical distance, or distance defined by speed to reach the location? Another problem with physical distance (besides ignoring line speed) is that geographic distance is not a real reflection of the actual cable distance (it's never a straight line).
However, trying to keep the traffic within the same region does have merit (region being defined by the topology/network architecture, rather than pure geography), and I would agree with you that this need exists. However, there are mechanisms/theories that have been developed in attempt to address this issue. Rather than re-inventing the wheel, we should look at how these past attempts address the issue, and the problems they encounter.
Some past attempts mechanisms that I'm aware of include:
N.E.T.'s SuperWAN feature for the IDNX (TDM switch). Part of its purpose was to expand the node limitation, but it also kept circuits within a defined domain, and allowed circuits to cross domains only when necessary. A transit domain could be defined by the user to bridge two domains together that were not directly connected.
StrataCom (now Cisco) Domains (ATM switch). It also expanded the node limit. It is similar in concept to N.E.T.'s SuperWAN. I believe it is no longer supported--but I'm not current with their feature sets (I think they were moving towards PNNI).
Ascend (now Lucent) OSPF Area (ATM switch). Terminology has changed from Domains to Areas, but the basic concept for routing remains the same: connections remain within the area, unless the destination is outside the area.
PNNI Peer Groups (ATM). This is supposed to be a more scalable approach to the same concept: keep your traffic within your peer group unless the destination is somewhere outside your peer group.
One thing you will notice with all these methods is that the area must be defined by the user, and is always influenced by the topology of the network. Switches are assigned areas and are only connected to other switches of the same areas. Areas are connected to other areas by a gateway (in most cases, it is a 'special' switch designated as a gateway). But notice that routing metrics are not applied to keep traffic within the area. Metrics are used to determine 'optimal' pathing.
Adding geographic coordinates are not necessary to address the issue because it should be addressed in architecting the network. The only real contribution geographic coordinates add is as a distance metric--but this already exists (it's in place, and in use--the problem is, is it 'correctly' being used?). Lastly, allowing geographic coordinates adds an additional complexity to router configuration, opening one more door to user error and compliance.
On the subject of network performance, there are 3 major places to look to see where network performance fails:
1. Capacity. There is not enough bandwidth to carry the traffic (ie. my pipes are not big enough). Just because you have big pipes and a lot of pipes does not mean you put the pipes in the right places (a major problem for most ISP's & carriers).
2. Queue. Because your pipes aren't big enough, the traffic must sit wait in a buffer before it has its turn to be sent out over the pipe. Adding more buffer to the queue reduces your packet drops by making your queue bigger--it does not make things get out faster.
3. CPU. Your switch can't handle all the lookups or route calculations or some sort of process. Because it's so bogged, it can't process or switch the packets fast enough. What can you do here? You are limited to the switch you bought.
Most IP-based networks focus on Queue and CPU. The table-lookups and DNS issues are more of a scalability problem, rather than a traffic issue (having too many nodes in the network vs. carrying too much traffic). Most traffic congestion for IP-based networks focuses on better queuing methods (ie. get the more important traffic out first). What is lacking for a vast majority of IP-based networks is the lack of optimization for CAPACITY. Remember, queue only kicks in when capacity runs out. If networks did a good job of placing enough bandwidth in the right places, then queuing would be minimized (example: TDM switches always guarantees capacity (100%), so there is no need for a queue. ATM & Frame Relay 'share' capacity, so a queue is needed when traffic begins to compete for space).
So why don't most networks optimize their capacity? In order to plan for capacity, you need a good idea what your traffic flows are (end-to-end traffic flows. link usage is not good enough). Most network administrators have no clue what their traffic flows actually are, because they are dynamic, very hard to guess, and there are very few good tools out there that can collect this type of information. Most tools on the market simulate queuing, but the traffic generated in the simulation are just guesses (read: no guarantee they mimic real life, much less your network), and this does not address the issue of capacity. Capacity planning tools exist, but they are few, and even fewer work as promised. Cisco is currently working with one company to provide capacity planning tools to IP-based networks, which has promise because it has the ability to extract traffic and network data from the live network. Still, for some reason, most router people are focused on queuing rather than capacity in order to improve performance.
I'm not a router expert, but...
Routing uses the process of receiving a packet and checking its destination. Using a table lookup based on the destination, it finds the the neighboring router it should forward the packet to. The table is updated so that routing can find 'the shortest path.' The real question here is how 'shortest' or distance is defined.
Your method of configuring geographic location on routers is basically trying to get the router to calculate its distance to its neighbors. However, you're thinking about geographic distance rather than logical topology which is the 'road map' that routers can travel on. There are two direct problems that stem from your method:
1. Pipe size (bandwidth) is not accounted for. If there exists two paths to the destination, should I take the 'geographically' shorter path that is connected by a 56K line, or a slightly longer path that consists of several OC3's?
2. Hop count is not weighed. With two paths, the geographically shorter path may travel through 20 routers, where a longer path may hop through 5 routers--how do you determine the tradeoffs?
Most importantly, routers currently have a mechanism to address this routing issue by allowing users to define the distance between routers. I believe this is usually set to reflect bandwidth size (ie. usually people define their OC3's to be shorter than their T1's). This is generally easier for network managers to adjust their link distances than to tweak their lat/lon coordinates.
Most of the problems with congestion I've seen is due to capacity problems--where there may be two different paths to a destination, but one path is over-utilized and another is under-utilized. Currently, routers are very limited in their load-balancing techniques. I believe Cisco routers can balance up to 6 equal paths--but configuring multiple 'equal' paths is not easy for a meshed network (equal as in defined distance). Without equal paths, routers generally send their packets down the 'shortest' path, regardless of congestion. Routers are not intelligent enough to recognize congestion and calculate the 'next shortest path' (though 'next-shortest' paths are done when there is a link failure). Without this type of mechanism, if you were to get the router to use the 'path of least resistence,' it would just shift the congestion from the previous route to your newly defined route. Currently, the MPLS initiative is trying to address this capacity issue.