Hot-potato routing

In Internet routing between autonomous systems which are interconnected in multiple locations, hot-potato routing is the practice of passing traffic off to another autonomous system as quickly as possible, thus using their network for wide-area transit. Cold-potato routing is the opposite, where the originating autonomous system internally forwards the packet until it is as near to the destination as possible.[1][2][3]

Behaviors

[edit]

Hot-potato routing (or "closest exit routing")[2] is the normal behavior generally employed by most ISPs.[1] Like a hot potato in the hand,[2] the source of the packet tries to hand it off as quickly as possible in order to minimize the burden on its network.[1]

Cold-potato routing (or "best exit routing")[2] on the other hand, requires more work from the source network, but keeps traffic under its control for longer, allowing it to offer a higher end-to-end quality of service to its users.[1] It is prone to misconfiguration as well as poor coordination between two networks, which can result in unnecessarily circuitous paths.[1] NSFNET used cold-potato routing in the 90s.[2]

When a transit network with a hot-potato policy peers with a transit network employing cold-potato routing, traffic ratios between the two networks tend to be symmetric.[2]

Implementation

[edit]

Routing behavior can be influenced using two BGP "knobs": multi-exit discriminator (MED) and local preference.[1] In hot-potato routing, the MED attached to incoming EBGP-learned routes is discarded,[2] and the IGP cost is used instead.[3] In cold-potato routing, MED[2] or BGP communities are used to signal the cost of the route, which influences IBGP local preference.[3]

References

[edit]
  1. ^ a b c d e f Subramanian, Lakshminarayanan; Padmanabhan, Venkata N.; Katz, Randy H. (2002-06-10). Geographic Properties of Internet Routing (PDF). USENIX 2002 Annual Technical Conference.
  2. ^ a b c d e f g h McPherson, D.; Patel, K. (January 2006). "MEDs and Potatoes". Experience with the BGP-4 Protocol. IETF. p. 5. sec. 7.1.1. doi:10.17487/RFC4277. RFC 4277. Retrieved 2023-12-11.
  3. ^ a b c Decraene, B.; Francois, P.; Pelsser, C.; Ahmad, Z.; Armengol, A.J. Elizondo; Takeda, T. (April 2011). "Routing Decisions". Requirements for the Graceful Shutdown of BGP Sessions. IETF. p. 18. sec. A.3. doi:10.17487/RFC6198. RFC 6198. Retrieved 2023-12-12.