ASTF - Compression and throttling use case support

[Richard McLaughlin]

Hi Trex Team

I am currently evaluating commercial traffic generators for testing a transparent proxy solution and was recently directed to your tool by a colleague. The ASTF capabilities within TRex to support a terminating proxy appear to align with what we need, however our L7 traffic simulation requirements are quite complex so I was wondering about the flexibility of the Python API.

The ASTF guide starts off with a diagram showing a DUT with a compress/uncompress function. Taking this as a basic use that we need to support, is there an example to show how the scenario should be configured in TRex given that the content returned from the server will be compressed by the DUT before being returned to the client? My understanding from the documentation is that the scenarios use packet captures to drive the interactions between the client and server. Since the proxy will then manipulate/compress the content, can TRex support this? For example does the server side need to be set up with the original content and the client side programmed to assert against the compressed content ?

A slightly more complex use case would be mimicking the behaviour of an adaptive streaming client that makes its requests (ABR quality levels) based upon the download rate at which previous requests were received. We currently have logic to run this behaviour in Python scripts so being able to bring these into Trex would be an end goal.

I would be interested to hear your views in the feasibility of using TRex to simulate these behaviours and test a proxy functions which manipulates/throttles content on the return path.

Thanks

Richard

[hanoh haim]

Hi Richard, 

TRex has a client side flow and server side flow. With compress/uncompress diagram I've tried to convey the fact that the flows could be different and L7 (in some cases) is the same (e.g. client MSS could be 512 (IPsec) while server side is MSS 9k) .However  the server side and client side L7 could be different too 

Regarding the proxy, TRex objective is to test scale of L7 features like Firewall/NAT/DPI etc that inspect the traffic and even change the traffic. This is done using advanced methods to achieve this unprecedented scale. In case of Proxy it is a bit more complex as there are a few L7 *control* protocols that the server side need to adhere (e.g. Is the webserver is up?). TRex does not support those server side protocols so your proxy might not work only due to  of this (the proxy will think that the server side is down)

In regards to the emulation layer. Under the hood there is L7 API to customize the TCP layer and App (L7) layer. It is a mini instruction parser.  Python builds a program that run really fast on the server side. 

If you have a specific app need, you can add a specific instruction (it is not that complex) and you can build the program yourself. 

See example for a low level L7 emulation layer. 

Have a look here for an example

https://github.com/cisco-system-traffic-generator/trex-core/blob/master/scripts/astf/http_manual_commands_pipeline4.py

The pcap file capability is just a very simple python layer that reads the pcap, analyze the L7 traffic and convert it to L7 instructions (more of write/read). 

For your questions:

1. " For example, does the server side need to be set up with the original content and the client side programmed to assert against the compressed content ?  "

[hh] No, you can build different "instructions"/program for server side and client side.  

2. "A slightly more complex use case would be mimicking the behaviour of an adaptive streaming client that makes its requests (ABR quality levels) based upon the download rate at which previous requests were received. We currently have logic to run this behaviour in Python scripts so being able to bring these into Trex would be an end goal.  "

[hh] This is indeed more complex, you could maybe make a client instruction that does the math of download and request different value. It will run on the server side. 

thanks

Hanoh

 

--
You received this message because you are subscribed to the Google Groups "TRex Traffic Generator" group.
To unsubscribe from this group and stop receiving emails from it, send an email to trex-tgn+u...@googlegroups.com.
To post to this group, send email to trex...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/trex-tgn/dfc13de5-750d-4b3a-a9b3-7c95ee89f092%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--

Hanoh

Sent from my iPhone