Saku Ytti wrote:
Fun fact about the real world, devices do not internally guarantee order. That is, even if you have identical latency links, 0 congestion, order is not guaranteed between packet1 coming from interfaceI1 and packet2 coming from interfaceI2, which packet first goes to interfaceE1 is unspecified.
So, you lack fundamental knowledge on the E2E argument fully applicable to situations in the real world Internet. In the very basic paper on the E2E argument published in 1984: End-To-End Arguments in System Design https://groups.csail.mit.edu/ana/Publications/PubPDFs/End-to-End%20Arguments... reordering is recognized both as the real and the theoretical world as: 3.4 Guaranteeing FIFO Message Delivery Ensuring that messages arrive at the receiver in the same order in which they are sent is another function usually assigned to the communication subsystem. which means, according to the paper, the "function" of reordering by network can not be complete or correct, and, unlike you, I'm fully aware of it.
This is because packets inside lookup engine can be sprayed to multiple lookup engines, and order is lost even for packets coming from interface1 exclusively, however after the lookup the order is restored for _flow_, it is not restored between flows, so packets coming from interface1 with random ports won't be same order going out from interface2.
That is a broken argument for how identification of flows by intelligent intermediate entities could work against the E2E argument and the reality initiated this thread. In the real world, according to the E2E argument, attempts to identify flows by intelligent intermediate entities is just harmful from the beginning, which is why flow driven architecture including that of MPLS is broken and hopeless. I really hope you understand the meaning of "intelligent intermediate entities" in the context of the E2E argument. Masataka Ohta