Open mcallaghan-sandvine opened 6 years ago
This article (written by Cisco!) gives further context and terminology definitions that perhaps we can lean on and reference
https://www.cisco.com/c/en/us/about/security-center/network-performance-metrics.html
related to #137 ... (continuation from that story)
as per https://trex-tgn.cisco.com/trex/doc/trex_manual.html#_per_template_section
, we define these as:
ipg = inter-packet-gap -- this is actually about IDLE FRAME duration between Ethernet packets. (aka interframe spacing, interframe gap) -- https://en.wikipedia.org/wiki/Interpacket_gap
I think by "ipg", we actually mean "inter-packet delay" -- (how long to delay pkt-to-pkt transmission when RTT is not at play for TCP control flow packets?), this is likely a non-industry accepted term since it's specific to TRex's implementation?
rtt = round-trip-time -- this is different from ipg (and inter-packet delay) -- "the length of time it takes for a signal to be sent plus the length of time it takes for an acknowledgment of that signal to be received" -- https://en.wikipedia.org/wiki/Round-trip_delay_time
I have tested and confirmed this theory:
==== CASE A) (status quo)
if we send a TCP flow when RTT == IPG == 100ms
-> here it goes:
, we can see that the timestamp correctly increments by ~100ms for each packet (without much understanding, this is an implicit assumption without knowing enough...)
==== CASE B) rtt > ipd (a MORE realistic situation)
results in ->
we can see here for all TCP control packets, the RTT is honoured, with 100ms delay and for all DATA packets, 10ms increments happen!
==== CASE C) rtt < ipd (awkward, but possible) (*this is a scenario where the RTT of the network is LESS (faster) than the server or client delay in sending sequential data packets ... fairly unlikely in the real world, but possible if the application artificially delays packets, or perhaps if the OS or network stack is throttling ... etc.)
and:
, as we can see, it's the reverse from CASE (B). RTT TCP control packets adhere to a 100ms delay, and TCP data stream pkts go for 10ms delay
TODO: NEEDS UDP TESTING
SO; I'd like to propose A> remove all notions that "rtt == ipg" B> properly explain RTT and what TRex does with it C> change "ipg" to inter-packet-delay and properly define it (ipg must remain for backwards compatibility I guess...)