FWIW, GRO/GSO give no end of headaches to the idea of new TCP options, esp. the current ones to extend option space after the SYN (draft-ietf-tcpm-tcp-edo).
Although I appreciate their zeal for optimization, implementers of GRO/GSO still need to play by the rules of TCP and UDP. It’s not clear they are (e.g., coalescing packets with different unknown options), and when they don’t, I want to be clear that it is they that are the problem. I agree that the common Unix socket interface has performance flaws, but perhaps it’s that interface that needs to evolve. Joe — Joe Touch, temporal epistemologist www.strayalpha.com > On Jan 27, 2022, at 1:29 PM, Behcet Sarikaya <sarikaya2...@gmail.com> wrote: > > Hi Folks, > > Thanks Christian for explaining how GSO/GRO are used by Quic implementations. > So the use is not mandated in Quic RFCs but rather used in implementations.
_______________________________________________ Int-area mailing list Int-area@ietf.org https://www.ietf.org/mailman/listinfo/int-area
