Potato routing
In Internet routing, two paradigms, informally called hot potato and cold potato, exemplify the operational principles used in developing routing policy. When a routing domain or autonomous system receives a packet, under hot potato, it gets rid of it as quickly as possible. Hot potato is also called closest exit routing, and does minimize the workload required to route the information.
The term comes from a 1964 Rand Corporation paper by Sharla Boehm and Paul Baran.[1]
Both hot and cold potato routes are used in the Internet. [2] Both are tools in the routing architect's toolbox, to be used for the right purpose, just as a screwdriver really should not be used as a chisel — unless you don't have a chisel.
Hot potato is safer for the router, but gives the operator of the router less control. For any service provider network, the first requirement is that it survive, just as the important thing about a dog walking on his hind legs is not that he does it well, but that he does it at all.
Optimal routing is not the first priority in making a robust routing system. Indeed, route optimality may mean different things at different times. For a given application, minimizing latency is optimal. For a different application, maximizing throughput may be optimal. Survival often means maximizing closest-exit routing and minimizing churn [i.e., updating and recomputation] of the routing table. The latter depends significant on maximizing route aggregation, which causes a loss of [optimal routing] information.[3]
Network reliability and potatoes
If there are multiple exits from a routing domain, the highest-availability design tends to be hot potato. When there is both a guaranteed availability and a quality of service specification, the designer needs to set up backup paths that meet the guarantees.
There is an obscure but elegant way, in the Open Shortest Path First interior routing protocol, to create closest exits from its routing domain.[4]. In most implementations, exterior routes, which, to OSPF, includes default routes, are set as External Type 2, which only considers the cost of the external interface. Setting them to External Type 1, with the same external interface cost, causes the default route to the default route as the external interface cost plus the sum of internal link cost to get to the external interfce. From different points in the routing domain, as long as multiple defaults exist, traffic will go to the closest exit. If an exit fails, the next best exit will automatically be selected.[5]
Potatoes and controlling quality of service
Cold potato, also called best exit routing, involves having the routing domain or autonomous system keep control of the packet as long as it can route it over links of known performance and traffic, so it can control the per-hop behavior encountered by the packet. The exit point from the current routing domain will also be selected to have the best available external path to the destination.
In BGP, the effects of certain ways to designate a route as more or less preferential, such as multi-exit discriminator (MED), will depend on the potato-related meta-policies of the connected autonomous systems between which the MEDs are transferred.[6]
Regulatory and economic considerations
The alternatives have different regulatory and economic aspects.[7] An ISP that principally uses cold potato, with the caveat that they must have designers that can ensure the resources are present to support the increased resource demand, is likely to be more predictable.[8]
References
- ↑ Boehm, Sharla P. & Paul Baran, On Distributed Communications: II. Digital Simulation of Hot-Potato Routing in a Broadband Distributed Communications Network, Rand RM-3103-PR
- ↑ L. Subramanian, V.N. Padmanabhan, R.H. Katz, Hot-potato versus Cold-potato routing, Geographic Properties of Internet Routing
- ↑ Berkowitz H (2002), Translating Service Definitions to Technical Requirements: Policies, Building Service Provider Networks, Wiley p. 355
- ↑ Berkowitz, H (1999), OSPF Goodies for ISPs, North American Network Operators Group NANOG 17, Montreal p. 57
- ↑ Berkowitz 2002, pp. 357-358
- ↑ D. McPherson, V. Gill (March 2006), BGP MULTI_EXIT_DISC (MED) Considerations, RFC4451
- ↑ Cukier, Kenneth Neil, Peering and Fearing: ISP Interconnection and Regulatory Issues
- ↑ Woods, Darrin (24 July 2000), "Fishy Business", Network Computing