At a high level, this mechanism inserts a jitter-reordering buffer in the flows of length OUTOFORDER_TIMER microseconds, where OUTOFORDER_TIMER is a configured parameter. I have experience with three different types of flow, each of which interacts with such a mechanism in a different way:
UDP-based request/response protocols: These are insensitive to packet reordering, and are only slowed down by dejittering. TCP: I'm not an expert on TCP, but reports are that most TCP congestion-control algorithms respond badly to misordered packet reception. This seems to be a situation where jitter-reordering is useful. UDP-based media streaming (RTP): RTP receivers generally contain dynamically-adjusted dejitter buffers. So I'd expect them to automatically compensate for jitter introduced by packet spraying. Adding dejittering upstream provides no additional value. So it seems to me that doing jitter-reordering in a separate layer may not be a good idea; rather it seems that OUTOFORDER_TIMER should be provided to the transport layer so that it can compensate for packet disordering. Also, given that the similar mechanism for GRE is 18 years old, I'd like to see the draft summarize experience with that mechanism. Then again, there's no rule that the option has to be specified for all packets between two endpoints. One possiblity is applying it only to packets carrying TCP payloads. That allows the Geneve implementation to support TCP implementations that don't respond well to packet reordering, while leaving other implementations alone. Dale _______________________________________________ nvo3 mailing list [email protected] https://www.ietf.org/mailman/listinfo/nvo3
