Sadly, out-of-order delivery tolerance was a "requirement" when we designed TCP originally. There was a big motivation: spreading traffic across a variety of roughly equivalent paths, when you look at the center of the network activity (not the stupid image called "backbone" the forces you to think it is just one pipe in the middle). Instead a bunch of bell-head, circuit-oriented thought was engineered into TCP's later assumptions (though not UDP, thank the lord). And I mean to be insulting there.
It continues to appall me how much the post-1990 TCP tinkerers have assumed "almost perfectly in-order" delivery of packets that are in transit in the network between endpoints, and how much they screw up when that isn't true. Almost every paper in the literature (and RFC's) makes the assumption. But here's the point. With a little careful thought, it is unnecessary to make this assumption in almost all cases. For example: you can get the effect of SACK without having to assume that delivery is almost in-order. And the resut will be a protocol that works better for out-of-order delivery, and also have much better performance wnen in-order delivery happens to occur. (and that's not even taking advantage of erasure coding like the invention called "Digital Fountains", which is also an approach for out-of-order delivery in TCP). This is another example of the failure to adhere to the end-to-end argument. You don't need to put "near-in-order-delivery" as a function into the network to get the result you want (congestion control, efficient error-tolerance). So don't put that requirement on the network. Let it choose a different route for every packet from A to B. On Saturday, April 11, 2020 7:08pm, "Dave Taht" <[email protected]> said: > The way I've basically looked at things since 25Gbit ethernet was that > improvements in single stream throughput were dead. I see a lot of > work on out of order delivery tolerance as an outgrowth of that, > but... am I wrong? > > https://ethernettechnologyconsortium.org/wp-content/uploads/2020/03/800G-Specification_r1.0.pdf > > -- > Make Music, Not War > > Dave Täht > CTO, TekLibre, LLC > http://www.teklibre.com > Tel: 1-831-435-0729 > _______________________________________________ > Cerowrt-devel mailing list > [email protected] > https://lists.bufferbloat.net/listinfo/cerowrt-devel > _______________________________________________ Cerowrt-devel mailing list [email protected] https://lists.bufferbloat.net/listinfo/cerowrt-devel
