| | 1 | TwoSew is a traffic model based on Application Data Units (ADU) extracted from real traffic flows. TwoSew describes each TCP flow as a series of ADU events. TwoSew is based loosely on Tmix and Swing traffic models, but is a ''two-way'' SEND/WAIT ADU-based flow model which extends these models to support a wider variety of flow dynamics. |
| | 2 | |
| | 3 | In TwoSew, each flow is equivalent to one TCP connection, initiated by a client with a server. Clients and servers send ADUs to each other. Each ADU is a chunk of data sent by the application in a single message to the transport layer, which may break the ADU into several packets. Either party may send an ADU based on internal application triggers (e.g., an FTP client has read a new chunk of data from disk and sends it to the server) or based on receipt and processing of an ADU sent by the other party (e.g., a Web server sends back a page after receiving and processing a user’s request). We support both these dynamics with two types of events: SEND events, which record generation of data from one party to another, and WAIT events, which record waiting for a given amount of data to arrive from a party, before proceeding with events. W |
| | 4 | |
| | 5 | In TwoSew, each event has the following fields: (1) actor: the IP address of the party performing the event, (2) eventtype: SEND or WAIT, (3) bytes: the number of bytes to send or to wait for, (4) twait: the time to wait. For SEND events, twait is the time measured from the previous SEND by the same party, and it mimics waiting for application triggers. For WAIT events, twait is the time measured from when the party receives total of bytes from another party, and it mimics the processing time of ADUs and user think time. |
| | 6 | |
| | 7 | TwoSew’s event structure is versatile enough to support a variety of scenarios: (1) request-response—where one party sends a request and waits for a response from another party be- fore proceeding, (2) parallel sends—where two machines are sending data to each other simultaneously and (3) a mixture thereof. TwoSew supports pauses between the connection start and the first ADU by using a non-zero wtime value in the first SEND event. TwoSew can also support pauses between the connection’s last ADU and its termination (via FIN or RST) by inserting a WAIT event for the client and the server at the end with non-zero wtime. All these scenarios are well-represented in real network traces. |
| | 8 | |
| | 9 | TwoSew is more expressive than previous models. For example Swing’s model cannot support communications with parallel sends, and Tmix’s model cannot support the mixture of request-response and parallel sends on the same connection. Further, neither model can support the ADU processing time at the server, and the delays at the start and the end of a connection. |
