1.. include:: replace.txt 2 33GPP HTTP applications 4---------------------- 5 6Model Description 7***************** 8 9The model is a part of the applications library. The HTTP model is based on a commonly 10used 3GPP model in standardization `[4]`_. 11 12Design 13====== 14 15This traffic generator simulates web browsing traffic using the Hypertext 16Transfer Protocol (HTTP). It consists of one or more ``ThreeGppHttpClient`` 17applications which connect to a ``ThreeGppHttpServer`` application. The client 18models a web browser which requests web pages to the server. The server 19is then responsible to serve the web pages as requested. Please refer to 20``ThreeGppHttpClientHelper`` and ``ThreeGppHttpServerHelper`` for usage instructions. 21 22Technically speaking, the client transmits *request objects* to demand a 23service from the server. Depending on the type of request received, the 24server transmits either: 25 26 - a *main object*, i.e., the HTML file of the web page; or 27 - an *embedded object*, e.g., an image referenced by the HTML file. 28 29The main and embedded object sizes are illustrated in figures :ref:`fig-http-main-object-size` 30and :ref:`fig-http-embedded-object-size`. 31 32 33.. _fig-http-main-object-size: 34 35.. figure:: figures/http-main-object-size.* 36 :figwidth: 15cm 37 38 3GPP HTTP main object size histogram 39 40.. _fig-http-embedded-object-size: 41 42.. figure:: figures/http-embedded-object-size.* 43 :figwidth: 15cm 44 45 3GPP HTTP embedded object size histogram 46 47\ 48 49A major portion of the traffic pattern is *reading time*, which does not 50generate any traffic. Because of this, one may need to simulate a good 51number of clients and/or sufficiently long simulation duration in order to 52generate any significant traffic in the system. Reading time is illustrated in 53:ref:`fig-http-reading-time`. 54 55.. _fig-http-reading-time: 56 57.. figure:: figures/http-reading-time.* 58 :figwidth: 15cm 59 60 3GPP HTTP reading time histogram 61 62 633GPP HTTP server description 64############################ 65 663GPP HTTP server is a model application which simulates the traffic of a web server. This 67application works in conjunction with ``ThreeGppHttpClient`` applications. 68 69The application works by responding to requests. Each request is a small 70packet of data which contains ``ThreeGppHttpHeader``. The value of the *content type* 71field of the header determines the type of object that the client is 72requesting. The possible type is either a *main object* or an *embedded object*. 73 74The application is responsible to generate the right type of object and send 75it back to the client. The size of each object to be sent is randomly 76determined (see ``ThreeGppHttpVariables``). Each object may be sent as multiple packets 77due to limited socket buffer space. 78 79To assist with the transmission, the application maintains several instances 80of ``ThreeGppHttpServerTxBuffer``. Each instance keeps track of the object type to be 81served and the number of bytes left to be sent. 82 83The application accepts connection request from clients. Every connection is 84kept open until the client disconnects. 85 86Maximum transmission unit (MTU) size is configurable in ``ThreeGppHttpServer`` or in 87``ThreeGppHttpVariables``. By default, the low variant is 536 bytes and high variant is 1460 bytes. 88The default values are set with the intention of having a TCP header (size of which is 40 bytes) added 89in the packet in such way that lower layers can avoid splitting packets. The change of MTU sizes 90affects all TCP sockets after the server application has started. It is mainly visible in sizes of 91packets received by ``ThreeGppHttpClient`` applications. 92 933GPP HTTP client description 94############################ 95 963GPP HTTP client is a model application which simulates the traffic of a web browser. This 97application works in conjunction with an ThreeGppHttpServer application. 98 99In summary, the application works as follows. 100 1011. Upon start, it opens a connection to the destination web server 102 (ThreeGppHttpServer). 1032. After the connection is established, the application immediately requests 104 a *main object* from the server by sending a request packet. 1053. After receiving a main object (which can take some time if it consists of 106 several packets), the application "parses" the main object. Parsing time 107 is illustrated in figure :ref:`fig-http-parsing-time`. 1084. The parsing takes a short time (randomly determined) to determine the 109 number of *embedded objects* (also randomly determined) in the web page. 110 Number of embedded object is illustrated in :ref:`fig-http-num-of-embedded-objects`. 111 112 * If at least one embedded object is determined, the application requests 113 the first embedded object from the server. The request for the next 114 embedded object follows after the previous embedded object has been 115 completely received. 116 * If there is no more embedded object to request, the application enters 117 the *reading time*. 118 1195. Reading time is a long delay (again, randomly determined) where the 120 application does not induce any network traffic, thus simulating the user 121 reading the downloaded web page. 1226. After the reading time is finished, the process repeats to step #2. 123 124.. _fig-http-parsing-time: 125 126.. figure:: figures/http-parsing-time.* 127 :figwidth: 15cm 128 129 3GPP HTTP parsing time histogram 130 131.. _fig-http-num-of-embedded-objects: 132 133.. figure:: figures/http-num-of-embedded-objects.* 134 :figwidth: 15cm 135 136 3GPP HTTP number of embedded objects histogram 137 138The client models HTTP *persistent connection*, i.e., HTTP 1.1, where the 139connection to the server is maintained and used for transmitting and receiving 140all objects. 141 142Each request by default has a constant size of 350 bytes. A ``ThreeGppHttpHeader`` 143is attached to each request packet. The header contains information 144such as the content type requested (either main object or embedded object) 145and the timestamp when the packet is transmitted (which will be used to 146compute the delay and RTT of the packet). 147 148 149References 150========== 151 152Many aspects of the traffic are randomly determined by ``ThreeGppHttpVariables``. 153A separate instance of this object is used by the HTTP server and client applications. 154These characteristics are based on a legacy 3GPP specification. The description 155can be found in the following references: 156 157\ 158 159.. _`[1]`: 160 161[1] 3GPP TR 25.892, "Feasibility Study for Orthogonal Frequency Division Multiplexing (OFDM) for UTRAN enhancement" 162 163\ 164 165.. _`[2]`: 166 167[2] IEEE 802.16m, "Evaluation Methodology Document (EMD)", IEEE 802.16m-08/004r5, July 2008. 168 169\ 170 171.. _`[3]`: 172 173[3] NGMN Alliance, "NGMN Radio Access Performance Evaluation Methodology", v1.0, January 2008. 174 175\ 176 177.. _`[4]`: 178 179[4] 3GPP2-TSGC5, "HTTP, FTP and TCP models for 1xEV-DV simulations", 2001. 180 181\ 182 183Usage 184***** 185 186The three-gpp-http-example can be referenced to see basic usage of the HTTP applications. 187In summary, using the ``ThreeGppHttpServerHelper`` and ``ThreeGppHttpClientHelper`` allow the 188user to easily install ``ThreeGppHttpServer`` and ``ThreeGppHttpClient`` applications to nodes. 189The helper objects can be used to configure attribute values for the client 190and server objects, but not for the ``ThreeGppHttpVariables`` object. Configuration of variables 191is done by modifying attributes of ``ThreeGppHttpVariables``, which should be done prior to helpers 192installing applications to nodes. 193 194The client and server provide a number of ns-3 trace sources such as 195"Tx", "Rx", "RxDelay", and "StateTransition" on the server side, and a large 196number on the client side ("ConnectionEstablished", 197"ConnectionClosed","TxMainObjectRequest", "TxEmbeddedObjectRequest", 198"RxMainObjectPacket", "RxMainObject", "RxEmbeddedObjectPacket", 199"RxEmbeddedObject", "Rx", "RxDelay", "RxRtt", "StateTransition"). 200 201 202Building the 3GPP HTTP applications 203=================================== 204 205Building the applications does not require any special steps to be taken. It suffices to enable 206the applications module. 207 208Examples 209======== 210 211For an example demonstrating HTTP applications 212run:: 213 214 $ ./waf --run 'three-gpp-http-example' 215 216By default, the example will print out the web page requests of the client and responses of the 217server and client receiving content packets by using LOG_INFO of ``ThreeGppHttpServer`` and ``ThreeGppHttpClient``. 218 219Tests 220===== 221 222For testing HTTP applications, three-gpp-http-client-server-test is provided. Run:: 223 224 $ ./test.py -s three-gpp-http-client-server-test 225 226The test consists of simple Internet nodes having HTTP server and client applications installed. 227Multiple variant scenarios are tested: delay is 3ms, 30ms or 300ms, bit error rate 0 or 5.0*10^(-6), 228MTU size 536 or 1460 bytes and either IPV4 or IPV6 is used. A simulation with each combination of 229these parameters is run multiple times to verify functionality with different random variables. 230 231Test cases themselves are rather simple: test verifies that HTTP object packet bytes sent match 232total bytes received by the client, and that ``ThreeGppHttpHeader`` matches the expected packet. 233 234 235 236