You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Testground is used to compare the performance between different transport protocols (e.g. raw TCP vs. libp2p TCP vs. libp2p QUIC).
When running on a local connection, raw TCP is able to use jumbo frames, sending segments up to 65 kB. quic-go limits the UDP packet size to 1452 bytes, since this is the absolute maximum packet size that can be transmitted over the public internet (with an Ethernet (?) MTU of 1500 bytes).
I'm still investigating how this impacts libp2p TCP, my suspicion is that we're limiting our buffer size somewhere in the stack (security? muxer?).
Using huge packets gives TCP an unfair and unrealistic advantage. It would be great if Testground could impose realistic limits on packet sizes.
The text was updated successfully, but these errors were encountered:
Testground is used to compare the performance between different transport protocols (e.g. raw TCP vs. libp2p TCP vs. libp2p QUIC).
When running on a local connection, raw TCP is able to use jumbo frames, sending segments up to 65 kB. quic-go limits the UDP packet size to 1452 bytes, since this is the absolute maximum packet size that can be transmitted over the public internet (with an Ethernet (?) MTU of 1500 bytes).
I'm still investigating how this impacts libp2p TCP, my suspicion is that we're limiting our buffer size somewhere in the stack (security? muxer?).
Using huge packets gives TCP an unfair and unrealistic advantage. It would be great if Testground could impose realistic limits on packet sizes.
The text was updated successfully, but these errors were encountered: