Open egwakim opened 1 year ago
hhaim
commented
1 year ago @egwakim, we don't have plans to support it as our use-cases do not have a special handling for QUIC. I think that the trex server side would be more scalable and aligned with the app layer, but much more complex to support it (maybe share object is an option ..) EMU can support it in an easier way in case there is an implementation, but the rate would be limited (5MPPS top) not sure if this is enough..
egwakim
commented
1 year ago Thanks for comment. TRex-EMU approach would be easier approach. 5MPPS would not be critical limitation. But, TRex-EMU seems have several critical limitations. 1) It can support only limited port range(0xff00 ~ 0xffff) : it's critical limitation which cannot used in our STP. 2) It can support only single traffic profile : it also critical issue because we need to create traffic profiles dynamic way.
hhaim
commented
1 year ago @egwakim you are correct. EMU was designed for CP topology, protocols and all the ASTF features are not there ..
Hi, Usage of QUIC protocol is increasing. Many of modern apps(Chrome, Edge, Safari, Youtube, Facebook, Instagram, Gmail) supports QUIC protocol. QUIC protocol is needed to simulate real world traffic. Do you have plan to support QUIC in TRex? If so, which way would be better? Would it possible to support in TRex like TCP layer?(Tunnable ip.proto = tcp or quic?) Unlike TCP, QUIC transport layer runs on top of UDP, there would be possibility to support as TRex-EMU plugin. But, I assume that it's not proper approach because TRex-EMU designed to support control plane protocols and it would have some limitations(single profile, port range(0xff00~0xffff), zmq channel capacity (3 ~ 5MPPS) etc). There is no suitable QUIC implementations written in GO(e.g QUIC-GO does not support BBR).