> If you allow tcp to drop/re-order packets, the entire abstraction of a stream protocol is gone. The application now has to understand packet boundaries, which

> If you allow tcp to drop/re-order packets, the entire abstraction of a stream protocol is gone. The application now has to understand packet boundaries, which packets are missing, etc. I don't think so. On the receiver's side, the application doesn't need to know packets at all -- it just deals with a stream of bytes where some portions may be dropped or come out of order. The packet nature would be abstracted away. On the sender's side, packets only become relevant if the application wants to get optimal behavior with respect to the packet size (in which case it would be already doing its own manual UDP). If it just wants "good enough" generic behavior (which is what TCP has always been providing for everyone) then it can again ignore the packet nature and just treat the connection as a stream where some portions may be dropped and/or reordered. Think about how useful this could be in so many common situations: when you're trying to download some file, for example, you don't need TCP -- because it doesn't matter if the data comes out of order. You just need to make sure you get everything eventually and that the data isn't corrupted. You don't want UDP either, which would require you to implement your own feedback/congestion control/etc. mechanisms from scratch. There's a nice sweet spot in the middle waiting to be hit. And it baffles me that it still doesn't seem to have been done.