Potato routing: Difference between revisions
imported>Howard C. Berkowitz (Origin of the term. See discussion page whether some of my own work is appropriate.) |
imported>Howard C. Berkowitz (More references and examples) |
||
| Line 7: | Line 7: | ||
| id = Rand RM-3103-PR | | id = Rand RM-3103-PR | ||
| url = http://www.rand.org/pubs/research_memoranda/RM3103/}}</ref> | | url = http://www.rand.org/pubs/research_memoranda/RM3103/}}</ref> | ||
Both hot and cold potato routes are used in the Internet. <ref name=>{{citation | |||
| contribution = Hot-potato versus Cold-potato routing | |||
| title = Geographic Properties of Internet Routing | |||
| author = L. Subramanian, V.N. Padmanabhan, R.H. Katz | |||
| conference = USENIX 2002 Annual Technical Conference | |||
| pages 243-259 | |||
| url = http://www.usenix.org/events/usenix02/full_papers/subramanian/subramanian_html/node28.html}}</ref> 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. | |||
<blockquote>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.<ref name=Berkowitz2002>{{citation | |||
| author = Berkowitz H | |||
| title = Building Service Provider Networks | |||
| chapter = Translating Service Definitions to Technical Requirements: Policies | |||
| publisher = Wiley | year = 2002}} p. 355 </ref></blockquote> | |||
==Network reliability and potatoes== | ==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.<ref name=Berkowitz1999>{{Citation | |||
| first = H | |||
| last = Berkowitz | |||
| contribution = OSPF Goodies for ISPs | |||
| url = http://www.nanog.org/mtg-9910/ospf.html | |||
| title = North American Network Operators Group NANOG 17 | |||
| year = 1999 | |||
| place = Montreal }} p. 57</ref>. In most implementations, exterior routes, which, to OSPF, includes [[default route]]s, 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.<ref> Berkowitz 2002, pp. 357-358</ref> | |||
==Potatoes and controlling quality of service== | ==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. | 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 system]]s between which the MEDs are transferred.<ref name=RFC4451>{{citation | |||
| id = RFC4451 | |||
| title = BGP MULTI_EXIT_DISC (MED) Considerations | |||
| author = D. McPherson, V. Gill | |||
| date = March 2006 | |||
| url = http://www.ietf.org/rfc/rfc4451.txt}}</ref> | |||
==Regulatory and economic considerations== | ==Regulatory and economic considerations== | ||
The alternatives have different regulatory and economic aspects.<ref>{{citation | The alternatives have different regulatory and economic aspects.<ref>{{citation | ||
| title = Peering and Fearing: ISP Interconnection and Regulatory Issues | | title = Peering and Fearing: ISP Interconnection and Regulatory Issues | ||
| first = Kenneth Neil | last = Cukier | | first = Kenneth Neil | last = Cukier | ||
| url = http://www.cukier.com/writings/peering-cukier-dec97.html}}</ref> | | url = http://www.cukier.com/writings/peering-cukier-dec97.html}}</ref> 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.<ref name=Woods2000>{{citation | ||
| title = Fishy Business | |||
| date = 24 July 2000 | |||
| first = Darrin | last = Woods | |||
| journal = Network Computing | |||
| url = http://www.networkcomputing.com/1114/1114f1.html}}</ref> | |||
==References== | ==References== | ||
{{reflist}} | {{reflist}} | ||
Revision as of 14:19, 23 July 2008
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