The ns Manual (formerly ns Notes and Documentation)1 - NM Lab at ...
The ns Manual (formerly ns Notes and Documentation)1 - NM Lab at ... The ns Manual (formerly ns Notes and Documentation)1 - NM Lab at ...
Chapter 41PackMime-HTTP: Web Traffic GenerationThe PackMime Internet traffic model was developed by researchers in the Internet Traffic Research group at Bell Labs, basedon recent Internet traffic traces. PackMime includes a model of HTTP traffic, called PackMime-HTTP. The traffic intensitygenerated by PackMime-HTTP is controlled by the rate parameter, which is the average number of new HTTP connectionsstarted each second. The PackMime-HTTP implementation in ns-2, developed at UNC-Chapel Hill, is capable of generatingHTTP/1.0 and HTTP/1.1 (persistent, non-pipelined) connections.The goal of PackMime-HTTP is not to simulate the interaction between a single web client and web server, but to simulatethe TCP-level traffic generated on a link shared by many web clients and servers.A typical PackMime-HTTP instance consists of two ns nodes: a server node and a client node. It is important to note thatthese nodes do not correspond to a single web server or web client. A single PackMime-HTTP client node generates HTTPconnections coming from a “cloud” of web clients. Likewise, a single PackMime-HTTP server node accepts and serves HTTPconnections destined for a “cloud” of web servers. A single web client is represented by a single PackMime-HTTP clientapplication, and a single web server is represented by a single PackMime-HTTP server application. There are many clientapplications assigned to a single client ns node, and many server applications assigned to a single server ns node.In order to simulate different RTTs, bottleneck links, and/or loss rates for each connection, PackMime-HTTP is often usedin conjunction with DelayBox (see Chapter 22). DelayBox is a module developed at UNC-Chapel Hill for delaying and/ordropping packets in a flow according to a given distribution. See Section 41.3 for more information on using PackMime-HTTPand DelayBox together.The PackMime HTTP traffic model is described in detail in the following paper: J. Cao, W.S. Cleveland, Y. Gao, K. Jeffay,F.D. Smith, and M.C. Weigle , “Stochastic Models for Generating Synthetic HTTP Source Traffic”, Proceedings of IEEEINFOCOM, Hong Kong, March 2004.41.1 Implementation DetailsPackMimeHTTP is an ns object that drives the generation of HTTP traffic. Each PackMimeHTTP object controls the operationof two types of Applications, a PackMimeHTTP server Application and a PackMimeHTTP client Application. Each ofthese Applications is connected to a TCP Agent (Full-TCP). Note: PackMime-HTTP only supports Full-TCP agents.Each web server or web client cloud is represented by a single ns node that can produce and consume multiple HTTPconnections at a time (Figure 41.1). For each HTTP connection, PackMimeHTTP creates (or allocates from the inactivepool, as described below) server and client Applications and their associated TCP Agents. After setting up and starting each363
(nsnode) clientcloudPackM ime(nsnode) servercloudandAgentsFigure 41.1: PackMimeHTTP Architecture. Each PackMimeHTTP object controls a server and a client cloud. Each cloudcan represent multiple client or server Applications. Each Application represents either a single web server or a single webclient.serverApplicationsandAgents clientApplicationsconnection, PackMimeHTTP sets a timer to expire when the next new connection should begin. The time between newconnections is governed by the connection rate parameter supplied by the user. New connections are started according to theconnection arrival times without regard to the completion of previous requests, but a new request between the same client andserver pair (as with HTTP 1.1) begins only after the previous request-response pair has been completed.PackMimeHTTP handles the re-use of Applications and Agents that have completed their data transfer. There are 5 pools usedto maintain Applications and Agents – one pool for inactive TCP Agents and one pool each for active and inactive client andserver Applications. The pools for active Applications ensure that all active Applications are destroyed when the simulationis finished. Active TCP Agents do not need to be placed in a pool because each active Application contains a pointer to itsassociated TCP Agent. New objects are only created when there are no Agents or Applications available in the inactive pools.41.1.1 PackMimeHTTP Client ApplicationEach PackMimeHTTP client controls the HTTP request sizes that are transferred. Each PackMimeHTTP client takes thefollowing steps:• if the connection is persistent and consists of more than one request, then the client samples all request sizes, responsesizes, and inter-request times for the connection• if the connection only consists of one request, then the client samples the request size and the response size• send the first HTTP request to the server• listen for the HTTP response• when the entire HTTP response has been received, the client sets a timer to expire when the next request should bemade, if applicable• when the timer expires, the next HTTP request is sent, and the above process is repeated until all requests have beencompleted364
- Page 313 and 314: 3.6274 n 0 m r 1 type repair servi
- Page 315 and 316: 3.6029 n 3 m r 2 Q NTIMER at 3.730
- Page 317 and 318: 36.4 Loss Detection—The Class SRM
- Page 319 and 320: same packet. The repair objet does
- Page 321 and 322: }hdr_asrm* seh = (hdr_asrm*) p->acc
- Page 323 and 324: set grp [Node allocaddr]$srm set ds
- Page 325 and 326: #set up the multicast routingDM set
- Page 327 and 328: 37.3 Architecture of the PLM Protoc
- Page 329 and 330: We add in void PLMLossMonitor::recv
- Page 331 and 332: Part VIApplication330
- Page 333 and 334: Traffic generatorsApplication/Traff
- Page 335 and 336: • recv(int nbytes)—Announces th
- Page 337 and 338: 1. EXPOO_Traffic—generates traffi
- Page 339 and 340: set src [new Agent/UDP]set sink [ne
- Page 341 and 342: Application FTP FTP objects produce
- Page 343 and 344: send_data(ADU)Application(HttpApp,
- Page 345 and 346: 39.1.4 Transmitting user data over
- Page 347 and 348: and teardown of connections. Only O
- Page 349 and 350: TclObjectPagePoolPagePool/CompMathP
- Page 351 and 352: PagePool/ProxyTrace takes these two
- Page 353 and 354: }int id_; // object IDWebTrafSessio
- Page 355 and 356: An Http/Server object waits for inc
- Page 357 and 358: set tmp [new RandomVariable/Exponen
- Page 359 and 360: Object Type Event Type Explaination
- Page 361 and 362: Chapter 40Worm ModelIn this chapter
- Page 363: $w local-p 0.5Following are some co
- Page 367 and 368: HTTP responsesclients servers Delay
- Page 369 and 370: 41.5 Commands at a GlanceThe follow
- Page 371 and 372: • HTTP response size (bytes)• s
- Page 373 and 374: Chapter 42Session-level Packet Dist
- Page 375 and 376: 42.1.2 Inserting a Loss ModuleWhen
- Page 377 and 378: Delay and Loss Modules Each receive
- Page 379 and 380: Chapter 43Asim: approximate analyti
- Page 381 and 382: set n(1) [$ns node]set link(0:1) [$
- Page 383 and 384: Part VIIIEmulation382
- Page 385 and 386: When using the emulation mode, a sp
- Page 387 and 388: set intf [$pf1 open readonly]puts "
- Page 389 and 390: puts "install nets into taps..."$a0
- Page 391 and 392: Chapter 45Nam45.1 IntroductionNam i
- Page 393 and 394: • Button 6 (Chevron logo) - Close
- Page 395 and 396: Second, when dealing with randomly
- Page 397 and 398: dst_portaddr,seqno,flags,sname);A n
- Page 399 and 400: • up• down• right• left•
- Page 401 and 402: 46.1.7 Agent TracingAgent trace eve
- Page 403 and 404: v -t 1.0 -e node_tclscript 2 "Echo
- Page 405 and 406: If nam ever gets to the end of an e
- Page 407 and 408: l :link-t time-s source id-d des
- Page 409 and 410: E :D :P :a :session enqueue-t time
- Page 411 and 412: v :V :N :W :g :A :c :q :execute tcl
- Page 413 and 414: $ns duplex-link-op orient right$ns
(<strong>ns</strong>node) clientcloudPackM ime(<strong>ns</strong>node) servercloud<strong>and</strong>AgentsFigure 41.1: PackMimeHTTP Architecture. Each PackMimeHTTP object controls a server <strong>and</strong> a client cloud. Each cloudcan represent multiple client or server Applic<strong>at</strong>io<strong>ns</strong>. Each Applic<strong>at</strong>ion represents either a single web server or a single webclient.serverApplic<strong>at</strong>io<strong>ns</strong><strong>and</strong>Agents clientApplic<strong>at</strong>io<strong>ns</strong>connection, PackMimeHTTP sets a timer to expire when the next new connection should begin. <strong>The</strong> time between newconnectio<strong>ns</strong> is governed by the connection r<strong>at</strong>e parameter supplied by the user. New connectio<strong>ns</strong> are started according to theconnection arrival times without regard to the completion of previous requests, but a new request between the same client <strong>and</strong>server pair (as with HTTP 1.1) begi<strong>ns</strong> only after the previous request-respo<strong>ns</strong>e pair has been completed.PackMimeHTTP h<strong>and</strong>les the re-use of Applic<strong>at</strong>io<strong>ns</strong> <strong>and</strong> Agents th<strong>at</strong> have completed their d<strong>at</strong>a tra<strong>ns</strong>fer. <strong>The</strong>re are 5 pools usedto maintain Applic<strong>at</strong>io<strong>ns</strong> <strong>and</strong> Agents – one pool for inactive TCP Agents <strong>and</strong> one pool each for active <strong>and</strong> inactive client <strong>and</strong>server Applic<strong>at</strong>io<strong>ns</strong>. <strong>The</strong> pools for active Applic<strong>at</strong>io<strong>ns</strong> e<strong>ns</strong>ure th<strong>at</strong> all active Applic<strong>at</strong>io<strong>ns</strong> are destroyed when the simul<strong>at</strong>ionis finished. Active TCP Agents do not need to be placed in a pool because each active Applic<strong>at</strong>ion contai<strong>ns</strong> a pointer to itsassoci<strong>at</strong>ed TCP Agent. New objects are only cre<strong>at</strong>ed when there are no Agents or Applic<strong>at</strong>io<strong>ns</strong> available in the inactive pools.41.1.1 PackMimeHTTP Client Applic<strong>at</strong>ionEach PackMimeHTTP client controls the HTTP request sizes th<strong>at</strong> are tra<strong>ns</strong>ferred. Each PackMimeHTTP client takes thefollowing steps:• if the connection is persistent <strong>and</strong> co<strong>ns</strong>ists of more than one request, then the client samples all request sizes, respo<strong>ns</strong>esizes, <strong>and</strong> inter-request times for the connection• if the connection only co<strong>ns</strong>ists of one request, then the client samples the request size <strong>and</strong> the respo<strong>ns</strong>e size• send the first HTTP request to the server• listen for the HTTP respo<strong>ns</strong>e• when the entire HTTP respo<strong>ns</strong>e has been received, the client sets a timer to expire when the next request should bemade, if applicable• when the timer expires, the next HTTP request is sent, <strong>and</strong> the above process is repe<strong>at</strong>ed until all requests have beencompleted364
Change language