Pardon me if I am using the wrong term, I am using the term Asymmetrical routing to describe a scenario in which a request packet enters a network via one path and the response packet exits the network via a different path.
For example an ICMP ping request enters a network via ISP A and the reply leaves via ISP B (due to multi-homing on both networks, and or some kind of manual or automatic 'tweaking' of route preferences on one end or the other).
I haven't noticed too many instances of this causing huge performance problems, but I have noticed some, has anyone noticed any instances in the real world where this has actually caused performance gains over symmetrical routing? Also in a multi-homed environment is there any way to automatically limit or control the amount of Asymmetrical routing which takes place? (should you?) I have read a few papers [what few I could find] and they are conflicted about whether or not it is a real problem for performance of applications although I cannot see how it wouldn't be. Has there been any real community consensus on this issue published that I may have overlooked?
I'm not sure I understand. If a routing protocol such as BGP is being used, this is considered normal behavior, and the routing determination is made usually wrt either best route or best bandwidth. In the first case, a return packet would usually follow on the same interface. In the second case it would be determined by however you have set things up (round robin, 2/3rds on one int and 1/3rd on the other, whatever.)
If you are multi-homed with two backbone providers with static routes, then it is also normal behavior for some packets to enter thru either of your two interfaces, and then to exit on the preferred interface (if no preference is made clear via routing, then the default outbound interface is the one with the lower IP address--e.g. 201.x.y.z would be preferred over 202.x.y.z).
There are at least two common scenarios where intentional asymmetric
routing (aka traffic engineering) benefits the sender:
Scenario 1: InterNAP-like product where the outbound packet takes a
path optimized for conditions other than shortest AS path. Conditions
might include minimize packet loss or maximize throughput as
determined by ongoing communication with testpoints in that direction.
Scenario 2: Cost minimization for bulk transfer. If you operate a
large mailing list or a usenet server, you might arrange for traffic
from the server to prefer peers first and then your lowest-cost
transit provider.
Routing in general is based of the premise of "my decision, my control" and
therefore you have some (albeit limited) controls about how YOU can
influence someone else's routing decision.
So any time you have more than one connection to the collective ('Net) then
you simply run the risk of you make one decision to send a packet out a
particular link, but a bunch of other people make decisions about routing as
well and it may very well come back another path.
Presumably you have your IP addressing as a constant. If you are NATting,
you may have some interesting problems with this, but that would be a design
problem on your end. Same with stateful firewalls.
From an appplication viewpoint though, it really shouldn't make any
difference. Packet goes out. Packet comes back. Life is good.
In short though, you have some choices with this, but they are all design
choices on your end. If you want to be multihomed, this is the way life is.
There's the somewhat trivial efficiency that if you're willing to
accept asymmetric routing, you spend a lot less time tweaking your
networks than if you insist on symmetry, and the more significant
issue that the network will usually be more resilient and reliable
(though slightly less predictable) if you're not tweaking it.
Essentially, if you don't control all the parts of the network that
your packet uses, you're not able to directly set optimization
parameters, so what you're doing to get symmetry is throwing lots of
hints at the network and hoping some will stick, and the parts of the
network that happen to cooperate with you may not be the best ones
that are otherwise available.