C50-Eval-20010323-xxx-traffic-comments

TITLE:Comments on HTTP Traffic Model

SOURCE: Nandu Gopalakrishnan, Srinivas Kadaba and Farooq Khan

ngopal, skadaba, fkhan1@lucent.comLucent Technologies

DATE: March 23, 2001

Notice

©2000 Lucent Technologies. All rights reserved.

The information contained in this contribution is provided for the sole purpose of promoting discussion within the 3GPP2

and its Organization Partners and is not binding on the contributor. The contributor reserves the right to add to, amend,

or withdraw the statements contained herein.

The contributor grants a free, irrevocable license to 3GPP2 and its Organization Partners to incorporate text or other

copyrightable material contained in the contribution and any modifications thereof in the creation of TIA or 3GPP2

publications; to copyright and sell in Organizational Partner’s name any Organizational Partner’s standards publication

even though it may include portions of the contribution; and at the Organization Partner’s sole discretion to permit others

to reproduce in whole or in part such contributions or the resulting Organizational Partner’s standards publication

ABSTRACT: This contribution provides comments on the proposed HTTP traffic model.

RECOMMENDATION: Discuss

C50-Eval-20010323-xxx-traffic-comments

MTU Size

– The MTU size per TCP packet assumed by Motorola is 1500 bytes.

– MTU size of 576 bytes is proposed.

– In a mix of sub-networks with different MTUs the lowest one is picked. Thus there is a bias towards the lower MTU of 576 bytes and hence we should adopt this packet size in the model.

C50-Eval-20010323-xxx-traffic-comments

Packing Efficiency (1)

– The issue of packing inefficiency does not involve the data rate only.

– Packing inefficiency arises as a result of the non-integral division of the quantum of data that is available in the transmitter buffers by the quantum of data that can be carried on a frame.

– For example, consider a lower than 64-QAM rate of 2.144 Mbps. Over a 5 ms frame this is capable of transmitting 1340 bytes which is 2.32 TCP packets (576 byte). Suppose three 576 byte TCP packets are sitting in the buffer then the first frame gets 100% packed whereas the next frame will be packed only 29% assuming no new data arrived for that user.

C50-Eval-20010323-xxx-traffic-comments

Packing Efficiency (2)

• The key is therefore the buffer occupancy which is driven by the inter-arrival times between the TCP bursts.

• However, option 1 of Motorola’s model clearly under-represents and avoids the packing efficiency issue in that an entire object arrives at the buffer in one shot.

• In option 3 of Motorola’s model, the entire remaining set of packets in a round is released by the source in one large chunk after the ACK from the first packet of the last round is ‘done’. It can be demonstrated that this will quickly ensure that the BS buffers are full of large quantities of data.

• Hence we propose (rather second) the following (see next VG) realistic and reasonable model (alluded to by Motorola during the last call):

C50-Eval-20010323-xxx-traffic-comments

Source Model

• For every TCP packet acknowledgement received after the due delay modeled as two components (c and L) as suggested, two new TCP packets will be released by the source.

– This will be representative of the initial slow start process of TCP as illustrated by Motorola.

– This together with the i.i.d exponentially distributed r.v. c and the realized L will allow for some probability of packets arriving staggered at the base station buffer and hence not flooding it.

– This does requires the program to delineate each TCP packet and have a feedback from receiver to sender, as in option 3 of Motorola.

C50-Eval-20010323-xxx-traffic-comments

Reasonable Complexity

• Note that the above model is simplified in the sense that it does not have all the nuances and details of a full fledged TCP stack.

– For example, when the link saturates, the resulting overflow and congestion triggers timer expiry and TCP falls back to slow start with a congestion window of just one TCP packet. Only then does the Slow Start Threshold (ssthresh) reset from its default value of 64 K to the value at saturation point, and the next time around congestion avoidance algorithm with linear growth kicks in. Clearly this situation will exacerbate and worsen the packing efficiency issue.

– Detailed issues (such as above and fast retransmit recovery from channel loss of TCP packets) can be studied in phase 2 by implementing a full blown TCP stack replete with such intricate mechanisms.

C50-Eval-20010323-xxx-traffic-comments

TCP Connection Establishment/Release

TX

RX

SYN(K)

SYN(J)ACK(K+1)

ACK(J+1) FIN(M)

ACK(M+1) FIN(N)

ACK(N+1)

Data flow

JK+1

ACK PSH RST SYN FINURG

20 bytes

[SYN(J), ACK(K+1)]

C50-Eval-20010323-xxx-traffic-comments

TCP Control Segments Model (1)

• For downlink data transfer, the TCP connection establishment will be initiated (by sending SYN (K)) by the Host in the fixed network.

• For each TCP connection established and torn down, 4 control segments [SYN(K), ACK(J+1), FIN(M), ACK(N+1)] will be sent on the downlink.

• The size of the control segments can be fixed at 40 bytes (20 bytes TCP header + 20 bytes IP header).

C50-Eval-20010323-xxx-traffic-comments

TCP Control Segments Model (2)

• For HTTP/1.0, 4 control segments will be generated for the main object and each of the embedded objects i.e., a total of 4*(Nd+1) segments.

• For HTTP/1.1, 4 control segments will be generated for the main object and another 4 segments for all the embedded objects i.e., a total of 8 segments.

• ACK (J+1) is released Trtt after the successful transmission (over the air) of SYN (K).

• ACK (N+1) is released Trtt after the successful transmission (over the air) of FIN (M).

C50-Eval-20010323-xxx-traffic-comments

Summary

• This model, which is neither over-simplified thus missing key issues nor over-complicated as in full blown TCP and further is consistent with Motorola’s own suggestions, should be chosen for simulation.

• It should be considered carefully and Lucent hopes that final agreement on this HTTP model will be reached soon, ahead of the Seattle meeting as we endeavored.