anchor.diff:  [bash]>./astf-sim -f astf/http_simple.py --full -o b.pcap 
   ----
   
  -those are the pcap file that generated 
  -
  -* b.pcap_c.pcap  client side pcap 
  -* b.pcap_s.pcap  server side pcap 
  +
  +* Use `--full' initiated the full simulation mode
  +* b.pcap output pcap file will be generated, it is the client side multiplex pcap
  +* There is no server side pcap file in this simulation because we are not simulating latency/jitter/drop in this case so the server should be the same as client side.
  +
  +another example that will run sfr profile in release mode and will show the counters 
  +
  +[source,bash]
  +----
  +[bash]>./astf-sim -f astf/sfr.py --full -o o.pcap -d 1 -r -v 
  +----
  +
   
   
   === Traffic profile reference 
  
positive.code: 
  * Ability to work when the DUT terminates the TCP stack (e.g. compress/uncompress, see figure 1). In this case there is a different TCP session on each side, but L7 data are *almost* the same.
  
  image::images/t_c2.png[title="DUT is TCP proxy",align="left",width={p_width}, link="images/t_c2.png"]
  
  * Ability to work in either client mode or server mode. This way TRex client side could be installed in one physical location on the network and TRex server in another. figure 2 shows such an example
  
  image::images/t_c3.png[title="C/S mode",align="left",width={p_width}, link="images/t_c2.png"]
  
  * Performance and scale
  ** High bandwidth - ~200gb/sec with many realistic flows (not one elephant flow)
  
negative.code:             
  ==== Simulation of latency/jitter/drop in high scale
  
  image::images/t_c7.png[title="TCP Rx side",align="center",width={p_width}, link="images/t_c7.png"]
  
  There is a requirement to simulate latency/jitter/drop in the network layer. Simulating drop in high rate it is not a problem, but simulating latency/jitter in high rate is a challenge because there is a need to queue a high number of packets. See figure 6 on the left.
  A better solution is to queue a pointer to both the TCP flow and the TCP descriptor (with TSO information) and only when needed (i.e. when it has already left the tx queue) build the packet again (lazy). The memory footprint in this case can be reduced dramatically.
  