3 ms·
I think we’re operating on different definitions of in-order and as received. TCP delivers packets in order, but perhaps not as received, if it had to request r
by ramzyo 9y ago
I think we’re operating on different definitions of in-order and as received. TCP delivers packets in order, but perhaps not as received, if it had to request retransmission of a dropped packet. UDP delivers packets in order that they were received. Doing what the article suggests would make TCP also deliver packets in the order that they were received. No?
- JoeAltmaier 9y agoTCP won't nack a packet when one is perceived as 'missed' (but really out-of-order); that's clear from the premise (ack everything). But reordering also happens simply by examining received packets in a burst, and putting them right. So its six of one and a half-dozen of the other I guess. Sorry for coming off so abrupt.
- ramzyo 9y agoNo problem, thanks for clarifying! So basically the benefit to the TCP NACK approach is that the TCP layer will also do a sort on the packets received?
- JoeAltmaier 9y agoYeah, which is imperfect but there you are. It means sometimes out-of-order packets will be reordered, and sometimes dropped (since TCP acked it, the (existing) TCP code will discard the out-of-order packet as 'duplicate'. Which turns out works pretty well in practice, since out-of-order are almost always in a burst (no delay inter-packet)