باغ گل های من

baghegolhayeman — Sat, 12 Dec 2009 18:39:18 GMT

چرا گرفته دلت؟
مثل آنكه تنهايي !!
چقدر هم تنها !!!
خيال مي كنم دچار آن رگ پنهان رنگها هستي
دچار يعني عاشق
و فكر كن كه چه تنهاست اگر كه ماهي كوچك دچار آبي درياي بيكران باشد
چه فكر نازك غمناكي !!!
و غم تبسم پوشيده ي نگاه گياه است
و غم اشاره ي محوي به رد وحدت اشياء ست
خوشا به حال گياهان كه عاشق نورند
و دست منبسط نور روي شانه ي آنهاست
نـــــــــه !!!
وصل ممكن نيست
هميشه فاصله اي است
اگر چه منحني آب بالش خوبيست براي خواب دلاويز و ترد نيلوفر
هميشه فاصله اي هست
دچار بايد بود
وگرنه زمزمه ي حيرت ميان دو حرف حرام خواهد شد
و عشق سفر به روشني احتزاز خلوت اشياءست
و عشق صداي فاصله هاست
صداي فاصله هايي كه غرق ابهامند
نــــه
صداي فاصله هايي كه مثل نقره تميزند
و باشنيدن يك هيچ مي شوند كدر
هميشه عاشق تنهاست
و دست عاشق در دست ترد ثانيه هاست
و او و ثانيه ها مي روند آن طرف روز
و او و ثانيه ها روي نور مي خوابند
و او وثانيه ها بهترين كتاب جهان را به آب مي بخشند
و خوب مي دانند كه هيچ ماهي هرگز هزار و يك گره رودخانه را نگشود

baghegolhayeman — Sun, 15 Nov 2009 17:39:18 GMT

Comparative Performance Analysis of Versions of

TCP in a Local Network with a Lossy Link

Anurag Kumar, Senior Member, IEEE

Abstract—We use a stochastic model to study the throughput

performance of various versions of transport control protocol

(TCP) (Tahoe (including its older version that we call OldTahoe),

Reno, and NewReno) in the presence of random losses on a

wireless link in a local network. We model the cyclic evolution

of TCP, each cycle starting at the epoch at which recovery starts

from the losses in the previous cycle. TCP throughput is computed

as the reward rate in a certain Markov renewal–reward process.

Our model allows us to study the performance implications of

various protocol features, such as fast retransmit and fast recovery.

We show the impact of coarse timeouts. In the local network

environment the key issue is to avoid a coarse timeout after a loss

occurs. We show the effect of reducing the number of duplicate

acknowledgements (ACK’s) for triggering a fast retransmit. A

large coarse timeout granularity seriously affects the performance

of TCP, and the various protocol versions differ in their ability

to avoid a coarse timeout when random loss occurs; we quantify

these differences. As observed in simulations by other researchers,

we show that, for large packet-loss probabilities, TCP-Reno

performs no better, or worse, than TCP-Tahoe. TCP-NewReno is

a considerable improvement over TCP-Tahoe, and reducing the

fast-retransmit threshold from three to one yields a large gain in

throughput; this is similar to one of the modifications in the recent

TCP-Vegas proposal. We explain some of these observations in

terms of the variation of fast-recovery probabilities with packetloss

probability. Finally, we show that the results of our analysis

compare well with a simulation that uses actual TCP code.

Index Terms—Congestion control, mobile Internet, models for

TCP, TCP performance.

I. INTRODUCTION

IT IS WELL KNOWN that transport control protocol (TCP)

(the transport-layer protocol in the Internet) reacts to all

packet losses as if they were caused by congestion, i.e.,

by stalling for a long timeout period and then dropping its

transmission window. Thus, over a cellular wireless channel,

in which there can be losses due to link errors and channel

handovers, TCP can exhibit very poor performance. Several

modifications have been proposed to the TCP loss-recovery

and congestion-control mechanism to improve data throughput

in the event of random loss; a simulation study of these

has been reported in [6]. To study the performance of TCP

over wireless channels, several researchers have recently used

experimental testbeds to understand TCP behavior and to

Manuscript received December 17, 1996; revised April 24, 1998; approved

by IEEE/ACM TRANSACTIONS ON NETWORKING Editor A. U. Shankar.

The author was with the Wireless Information Networks Laboratory (WINLAB),

Rutgers University, Piscataway, NJ 08854 USA, on leave from the

Department of Electrical and Communication Engineering, Indian Institute of

Science, Bangalore 560 094, India (e-mail: anurag@ece.iisc.ernet.in).

Publisher Item Identifier S 1063-6692(98)05642-8.

propose and evaluate possible solutions; see, for example, [1],

[2], [4], and [8].

Our work, reported here, belongs to a line of research that

attempts to develop detailed analytical models of the TCP

protocol in an effort to predict the performance of the various

versions that are being proposed. Such modeling and analysis

can also be used as a testbed for evaluating other variations,

so that experimentation can be done for the few that are

promising. The analysis effort also reveals the reasons for

which the various effects are observed in the experimental

work. The models we develop are analytical and parametric, so

that we can quickly answer “what-if” questions or evaluate the

effect of modifying a particular protocol or network parameter.

In this paper we develop models and analyses for studying

the bulk throughput of four versions of TCP, namely,

OldTahoe (the original protocol from [7]), Tahoe, Reno, and

NewReno [14], [6]. We assume a local network scenario, in

which a host on a local area network (LAN) is transmitting

bulk data to a mobile host connected to the LAN by a wireless

link. Our models incorporate important aspects, such as slow

start and congestion avoidance, coarse timers, fast retransmit,

and fast recovery. Assuming an uncorrelated random packetloss

model on the wireless link, we obtain the data throughput

as a function of the packet-error probability. Our results show

how the throughput degrades, for each version, with increasing

packet-loss probability. For a given loss probability, our results

quantify the performance improvement provided by each version.

We show that our analysis provides accurate quantitative

evaluation by comparing its results with a simulation based

on actual TCP code.

Prior research closest to our work is that of Mishra et al. [12]

and Lakshman and Madhow [11]; additional related references

are also given in these papers. Mishra et al. only analyze the

original protocol ([7]) and provide some supporting simulation

and experimental results. They observe a cyclical structure in

the TCP transmission process and they identify and analyze

the Markov chain of congestion window sizes at loss instants.

Both of these elements are key to our analysis as well, but we

analyze the newer protocols with the fast-retransmit feature.

Lakshman and Madhow consider OldTahoe and Reno, and

model and analyze one or more TCP connections whose flow

is constrained by a common bottleneck link. The link has a

finite buffer, and the bandwidth (i.e., the bottleneck bandwidth)

round-trip-delay product for each connection is large. There is,

thus, the issue of buffer overflow at the bottleneck link. These

authors study buffer sizing to obtain high TCP throughputs

and obtain an approximation to the random loss probability so

that random loss does not constrain throughput. They do not,

1063–6692/98$10.00 ã 1998 IEEE

486 IEEE/ACM TRANSACTIONS ON NETWORKING, VOL. 6, NO. 4, AUGUST 1998

Fig. 1. A LAN host with a TCP connection to a mobile host.

however, include coarse timeouts in their analysis; avoidance

of coarse timeouts is, however, the key issue in the local

network environment, and the issue of keeping the round-trip

“pipe” full is not as significant as in the wide-area situation.

Thus, they do not quantify the benefit of the fast-retransmit

feature in reducing the frequency of coarse timeouts.

Our work has been motivated by the experimental work

reported in [1] and [2]. These papers study various modifications

to the TCP protocol and report experimental results on

the improvements in performance observed when TCP is used

in situations such as that shown in Fig. 1. In [6] the authors

present fragments of simulation sample paths that demonstrate

how the various TCP versions differ in the ways they recover

from random packet losses. Our stochastic model captures the

probabilities of the various events occurring and, hence, allows

us to quantify how these different responses to loss events

affect the long-run throughput of the protocols.

As in [12] and [11], our analysis is also based on a study

of the cyclical evolution of the TCP transmission process.

Working with a Markov model, we are able to analyze the

congestion window process as well as the duration of the

cycle times. Thus, we can compute the long-run average

bulk throughput of the protocol. The newer versions of TCP,

namely, Tahoe, Reno, and NewReno, attempt to avoid coarse

timeouts by trying to do a fast retransmit and fast recovery.

Working with the complete distribution of the congestion

window process at loss instants allows us to obtain the

probability that fast recovery succeeds. Unlike [11], our first

attempt is to analyze the model as exactly as possible; since our

assumptions allow us to work with Markov models throughout,

we are able to capture many more details and the analysis is

relatively straightforward. Our model includes the duplicate

acknowledgment (ACK) threshold used by the fast-retransmit

feature, and we can study the effect of reducing this threshold.

A threshold of one is similar to one of the modifications to

Reno proposed in the TCP-Vegas proposals (see [3]).

This paper is organized as follows. In Section II we briefly

describe the data transfer part of the TCP protocol, highlighting

the various aspects that are important to model.

In Sections III and IV we describe the network scenario,

and the modeling assumptions/simplifications. In Section V

the detailed mathematical analysis is presented. Section VI

contains the numerical results and their discussion. Those

primarily interested in the results can skip Section V; the

notation and terminology used in Section VI are defined

before Section V. Finally, some conclusions are summarized

in Section VII.

II. THE TCP PROTOCOL

We model only the data transfer part of TCP. Details of the

TCP protocol can be found in the various Internet requests

for comments (RFC’s); see also [14]. The versions of the

TCP protocol that we model and analyze all assume the same

receiver process.

The TCP receiver: The TCP receiver accepts packets out

of sequence number order, buffers them in a TCP buffer, and

delivers them to its TCP user in sequence. Since the receiver

has a finite resequencing buffer, it advertises a maximum

window size at connection setup time, and the transmitter

ensures that there is never more than this amount of

unacknowledged data outstanding. We assume that the user

application at the TCP receiver can accept packets as soon as

the receiver can offer them in sequence and, hence, the receiver

buffer constraint is always just . The receiver returns an

ACK for every good packet that it receives. An ACK packet

that acknowledges the first receipt of an error-free in-sequence

packet will be called a first ACK. The ACK’s are cumulative,

i.e., an ACK carrying the sequence number acknowledges

all data up to, and including, the sequence number . If

there is data in the resequencing buffer, the ACK’s from the

receiver will carry the next expected packet number, which is

the first among the packets required to complete the sequence

of packets in the sequencing buffer. Thus, if a packet is lost

(after a long sequence of good packets), then the transmitter

keeps getting ACK’s with the sequence number of the first

packet lost, if some packets transmitted after the lost packet

do succeed in reaching the receiver. These are called duplicate

ACK’s.

The TCP transmitter: At all times , the transmitter

maintains the following variables for each connection:

the lower window edge. All data numbered up to

and including has been transmitted and

ACKed. is nondecreasing; the receipt of an

ACK with sequence number causes

to jump to .

the congestion window. The transmitter can send

packets with the sequence numbers

. ; increases or

decreases as described below.

the slow-start threshold. controls the increments

in as described below.

Retransmission timeout: The transmitter measures the

round-trip times (RTT’s) of some of the packets for which

it has transmitted and received ACK’s. These measurements

KUMAR: PERFORMANCE ANALYSIS OF VERSIONS OF TCP 487

are used to obtain a running estimate of the packet RTT on

the connection. Each time a new packet is transmitted, the

transmitter starts a timeout timer and resets the already running

timeout timer, if any; i.e., there is a timeout only for the

last transmitted packet. The timer is set for a retransmission

timeout (RTO) value that is derived from the RTT estimation

procedure. The TCP transmitter process measures time and

sets timeouts only in multiples of a timer granularity; for

example, BSD-based systems have a timer granularity of 500

ms. Further, there is a minimum timeout duration in most

implementations, e.g., two timer ticks in BSD, implying an

average minimum timeout of 750 ms. We will see in the

analysis that coarse timers have a significant impact on TCP

performance. For details on RTT estimation and the setting of

RTO values, see [5] or [14].

Window adaptation and timeout-based recovery: The

basic algorithm is common to all TCP versions and was

originally developed and proposed by Van Jacobson [7]; our

description follows that of [11]. The normal evolution of the

processes , , and is triggered by first ACK’s

(see definition above) and timeouts as follows.

1) Slow start: If , each first ACK causes

to be incremented by one.

2) Congestion Avoidance: If , each first

ACK causes to be incremented by .

3) Timeout at epoch causes to be set to one,

to be set to , and retransmissions

to begin from .

Packet loss recovery: If a packet is lost, and

will continue to be incremented until the first ACK for the

packet just before the lost packet is received. For a particular

loss instance, let their final values be denoted by and

, respectively; we will call a loss window. Then the

transmitter will continue to send packets up to the sequence

number . If some of the packets sent after the lost

packet get through, they will result in duplicate ACK’s, all

carrying the sequence number . The last packet transmitted

(i.e., ) will have a RTO associated with it.

The TCP versions differ in the way they recover from loss.

We provide some details here; in Section IV we will describe

how we have modeled these recovery procedures.

TCP-OldTahoe (timeout recovery [7]): The transmitter continues

sending until packet number and then waits

for a coarse timeout.

TCP-Tahoe (fast retransmit [6]): There is a transmitter

parameter , a small positive integer; typically . If

the transmitter receives the th duplicate ACK at time

(before the timer expires), then the transmitter behaves as if a

timeout has occurred and begins retransmission, with

and as given by the basic algorithm.

TCP-Reno (fast retransmit, fast (but conservative) recovery

[14]): Fast-retransmit is implemented, as in TCP-Tahoe, but

the subsequent recovery phase is different. Suppose the th

duplicate ACK is received at the epoch . Loss recovery

then starts. Recalling the definitions of and above, the

transmitter sets

The addition of takes care of the fact that more packets

have successfully left the network. The Reno transmitter then

retransmits only the packet with sequence number , the Reno

philosophy being conservative—if only one packet is lost then

this retransmission will produce an ACK for all of the other

packets, whereas if more packets are lost we had better be

sure that we are not really experiencing congestion loss. For

the th duplicate ACK received, at say , until recovery

completes

We explain the rest of the Reno recovery via an example,

where we take . Suppose and

packet 15 is lost. The transmitter continues sending packets

16, 17, 18, , 30; suppose packet 20 is also lost. The

receiver returns ACK’s (all asking for packet 15) for packets

16, 17, 18, 19, 21, , 29, 30. Note that the ACK for packet

14 would have been the first ACK asking for packet 15.

When the ACK for packet 18 is received (i.e., the third

duplicate ACK), the transmitter sets ,

and . is still 15; thus, packet 15 is

retransmitted. Meanwhile, ACK’s for packets 19, 21, ,

30 are also received and grows to . Since

, with , the transmitter is allowed to send

packets 15–36; hence, retransmission of packet 15 is followed

by transmission of packets 31–36. Receipt of packet 15 results

in a first ACK asking for packet 201 (thus first-ACKing packets

15, 16, 17, 18, 19) and jumps to 20. If packets 31–36

succeed in getting through, then three duplicate ACK’s asking

for packet 20 also are obtained, and 20 is retransmitted. This

results in a first ACK that covers all of the packets up to packet

number 36. At this time , the congestion window is reset as

follows and a new transmission cycle starts:

Thus, Reno slowly recovers the lost packets and there is

a chance that, owing to insufficient duplicate ACK’s, the

recovery stalls and a timeout has to be waited for. After a

timeout, the basic timeout recovery algorithm is applied.

TCP-NewReno (fast retransmit, fast recovery [6]): When

duplicate ACK’s are received, the first lost packet is resent,

but, unlike Reno, upon receipt of a partial ACK after the

first retransmission, the next lost packet (as indicated by the

partial ACK number) is retransmitted. Thus, after waiting

for the first duplicate ACK’s, the remaining lost packets

are recovered in as many RTT’s. If less than duplicate

ACK’s are received, then a timeout is inevitable. Consider the

following example to see the difference with Reno. Suppose

that after a loss, and , packets 7, 8, , 14 are

sent, and packets 7, 8, and 11 are lost. The transmitter receives

three duplicate ACK’s for packets 9, 10, and 12 (asking for

1 This is called a partial ACK since all of the packets transmitted in the

original loss window were not ACKed.

488 IEEE/ACM TRANSACTIONS ON NETWORKING, VOL. 6, NO. 4, AUGUST 1998

Fig. 2. Model for the TCP connection. X(t) is the number of TCP packets queued at the IS at time t.

packet 7). Fast retransmit is done (the same as in Reno), i.e.,

, and packet 7 is sent. The two ACK’s

for packets 13 and 14 cause to become 9. Assuming that

packet 7 now succeeds, its ACK (the first ACK asking for

8) would cause to become 8; the transmitter can now send

packets 15 and 16 also. NewReno would now resend packet

8, whereas Reno would wait for three duplicate ACK’s; these

cannot come since only two more packets have been sent after

the retransmission of packet 7. Thus, in case of multiple losses,

Reno has a higher probability of resorting to a coarse timeout.

Spurious retransmissions: Consider TCP-OldTahoe. The

retransmission of the first lost packet may result in an ACK

that acknowledges all of the packets until the next packet lost

in the loss window. This would cause the lower window edge

to advance; the congestion window would be increased

to two and the next lost packet and its successor would be

transmitted, even if this successor packet had gotten through

in its first transmission. Thus, some of the good packets in the

loss window may be retransmitted when retransmission starts;

this phenomenon can be seen in the sample path fragments

shown in [6].

baghegolhayeman — Sun, 15 Nov 2009 17:28:18 GMT

Modeling TCP Throughput: A Simple Model and its Empirical Validation _

Jitendra Padhye Victor Firoiu Don Towsley Jim Kurose

f jitu, v_roiu, towsley, kuroseg@cs.umass.edu

Department of Computer Science

University of Massachusetts

Amherst, MA 01003 USA

Abstract

In this paper we develop a simple analytic characterization

of the steady state throughput, as a function of loss rate

and round trip time for a bulk transfer TCP ow, i.e., a

ow with an unlimited amount of data to send. Unlike the

models in [6, 7, 10], our model captures not only the be-

havior of TCP's fast retransmit mechanism (which is also

considered in [6, 7, 10]) but also the e_ect of TCP's timeout

mechanism on throughput. Our measurements suggest that

this latter behavior is important from a modeling perspec-

tive, as almost all of our TCP traces contained more time-

out events than fast retransmit events. Our measurements

demonstrate that our model is able to more accurately pre-

dict TCP throughput and is accurate over a wider range of

loss rates.

1 Introduction

A signi_cant amount of today's Internet tra_c, including

WWW (HTTP), _le transfer (FTP), email (SMTP), and re-

mote access (Telnet) tra_c, is carried by the TCP transport

protocol [18]. TCP together with UDP form the very core

of today's Internet transport layer. Traditionally, simula-

tion and implementation/measurement have been the tools

of choice for examining the performance of various aspects of

TCP. Recently, however, several e_orts have been directed

at analytically characterizing the throughput of TCP's con-

gestion control mechanism, as a function of packet loss and

round trip delay [6, 10, 7]. One reason for this recent in-

terest is that a simple quantitative characterization of TCP

throughput under given operating conditions o_ers the pos-

sibility of de_ning a \fair share" or \TCP-friendly" [6] through-

put for a non-TCP ow that interacts with a TCP connec-

tion. Indeed, this notion has already been adopted in the

design and development of several multicast congestion con-

trol protocols [19, 20].

_This material is based upon work supported by the National

Science Foundation under grants NCR-95-08274, NCR-95-23807 and

CDA-95-02639. Any opinions, _ndings, and conclusions or recommen-

dations expressed in this material are those of the authors and do not

necessarily reect the views of the National Science Foundation.

In this paper we develop a simple analytic characteriza-

tion of the steady state throughput of a bulk transfer TCP

ow (i.e., a ow with a large amount of data to send, such

as FTP transfers) as a function of loss rate and round trip

time. Unlike the recent work of [6, 7, 10], our model captures

not only the behavior of TCP's fast retransmit mechanism

(which is also considered in [6, 7, 10]) but also the e_ect

of TCP's timeout mechanism on throughput. The measure-

ments we present in Section 3 indicate that this latter behav-

ior is important from a modeling perspective, as we observe

more timeout events than fast retransmit events in almost

all of our TCP traces. Another important di_erence between

ours and previous work is the ability of our model to accu-

rately predict throughput over a signi_cantly wider range

of loss rates than before; measurements presented in [7] as

well the measurements presented in this paper, indicate that

this too is important. We also explicitly model the e_ects

of small receiver-side windows. By comparing our model's

predictions with a number of TCP measurements made be-

tween various Internet hosts, we demonstrate that our model

is able to more accurately predict TCP throughput and is

able to do so over a wider range of loss rates.

The remainder of the paper is organized as follows. In

Section 2 we describe our model of TCP congestion control

in detail and derive a new analytic characterization of TCP

throughput as a function of loss rate and average round trip

time. In Section 3 we compare the predictions of our model

with a set of measured TCP ows over the Internet, having

as their endpoints sites in both United States and Europe.

Section 4 discusses the assumptions underlying the model

and a number of related issues in more detail. Section 5

concludes the paper.

2 A Model for TCP Congestion Control

In this section we develop a stochastic model of TCP conges-

tion control that yields a relatively simple analytic expres-

sion for the throughput of a saturated TCP sender, i.e., a

ow with an unlimited amount of data to send, as a function

of loss rate and average round trip time (RTT).

TCP is a protocol that can exhibit complex behavior,

especially when considered in the context of the current In-

ternet, where the tra_c conditions themselves can be quite

complicated and subtle [14]. In this paper, we focus our at-

tention on the congestion avoidance behavior of TCP and

its impact on throughput, taking into account the depen-

dence of congestion avoidance on ACK behavior, the manner

in which packet loss is inferred (e.g., whether by duplicate

ACK detection and fast retransmit, or by timeout), limited

receiver window size, and average round trip time (RTT).

Our model is based on the Reno avor of TCP, as it is by

far the most popular implementation in the Internet today

[13, 12]. We assume that the reader is familiar with TCP

Reno congestion control (see for example [4, 17, 16]) and we

adopt most of our terminology from [4, 17, 16].

Our model focuses on TCP's congestion avoidance mech-

anism, where TCP's congestion control window size, W; is

increased by 1=W each time an ACK is received. Con-

versely, the window is decreased whenever a lost packet is

detected, with the amount of the decrease depending on

whether packet loss is detected by duplicate ACKs or by

timeout, as discussed shortly.

We model TCP's congestion avoidance behavior in terms

of \rounds." A round starts with the back-to-back transmis-

sion of W packets, where W is the current size of the TCP

congestion window. Once all packets falling within the con-

gestion window have been sent in this back-to-back manner,

no other packets are sent until the _rst ACK is received for

one of these W packets. This ACK reception marks the end

of the current round and the beginning of the next round.

In this model, the duration of a round is equal to the round

trip time and is assumed to be independent of the window

size, an assumption also adopted (either implicitly or ex-

plicitly) in [6, 7, 10]. Note that we have also assumed here

that the time needed to send all the packets in a window is

smaller than the round trip time; this behavior can be seen

in observations reported in [2, 12].

At the beginning of the next round, a group of W0 new

packets will be sent, where W0 is the new size of the con-

gestion control window. Let b be the number of packets

that are acknowledged by a received ACK. Many TCP re-

ceiver implementations send one cumulative ACK for two

consecutive packets received (i.e., delayed ACK, [16]), so b

is typically 2. If W packets are sent in the _rst round and

are all received and acknowledged correctly, then W=b ac-

knowledgments will be received. Since each acknowledgment

increases the window size by 1=W; the window size at the

beginning of the second round is then W0 = W +1=b. That

is, during congestion avoidance and in the absence of loss,

the window size increases linearly in time, with a slope of

1=b packets per round trip time.

In the following subsections, we model TCP's behavior

in the presence of packet loss. Packet loss can be detected in

one of two ways, either by the reception at the TCP sender

of \triple-duplicate" acknowledgments, i.e., four ACKs with

the same sequence number, or via time-outs. We denote the

former event as a \TD" (triple-duplicate) loss indication,

and the latter as a \TO" loss indication.

We assume that a packet is lost in a round independently

of any packets lost in other rounds, a modeling assumption

justi_ed to some extent by past studies [1] that have shown

that periodic UDP packets that are separated by as little

as 40 msec tend to get lost only in singleton bursts. On

the other hand, we assume that packet losses are correlated

among the back-to-back transmissions within a round: if a

packet is lost, all remaining packets transmitted until the

end of that round are also lost. This bursty loss behavior,

which has been shown to arise from the drop-tail queuing

discipline (adopted in many Internet routers), is discussed

in [2, 3]. We discuss it further in Section 4.

We develop a stochastic model of TCP congestion con-

trol in several steps, corresponding to its operating regimes:

when loss indications are exclusively TD (Section 2.1), when

loss indications are both TD and TO (Section 2.2), and

when the congestion window size is limited by the receiver's

advertised window (Section 2.3). We note that we do not

model certain aspects of TCP's behavior (e.g., fast recov-

ery) but believe we have captured the essential elements of

TCP behavior, as indicated by the generally very good _ts

between model predictions and measurements made on nu-

merous commercial TCP implementations, as discussed in

Section 3. A more detailed discussion of model assumptions

and related issues is presented in Section 4. Also note that

in the following, we measure throughput in terms of packets

per unit of time, instead of bytes per unit of time.

baghegolhayeman — Tue, 07 Jul 2009 18:27:56 GMT

امروز هم گذشت و هیشکی ما رو نکشت .

امروز .... صبح ..... ظهر ..... شب

صبح ها یا با عجله بیدار میشیم و دنبال کارامون می ریم کارای روزمره و همیشگی کارای بی هیجان و میخ کوب شده به دیوار

یا با سستی و کرختی . چون یه روز تکراری دیگه خواهیم داشت پر از بیکاری پر از مشغله ی چه کنم ؟

و پر از تضادها و تناقض های چرا باید ؟ چون نباید .

یه روز دیگه پر برنامه برای فردا فردایی که برای وجود واقعیش ارزش قائل نیستیم ولی به تصورش ایمان داریم ایمان به این که میشه . ولی وجودش رو نادیده می گیریم . یه رویا می سازیم از چیزی که دوست داریم این وسط خیلی چیزا رو فراموش می کنیم اولین چیزی که فراموش میشه اینه که برای چی ؟ ما برای چی اینجاییم ؟ به قول مژگان "ما که اون سیب و نچیدیم" خداوندا تو مسئولی .

فراموش می کنیم دیروز چه نقشه هایی کشیدیم واسه امروز ، امروز واسه فردا ، فردا برای کی ؟

فراموش می کنیم به قاصدک قول داده بودیم آزادش کنیم . فراموش می کنیم دلتنگی هامونو تو کلبه دلتنگی جا بگذاریم ، ولی گمش نکنیم . اما چرا نباید اونا رو گم کنیم تا کی با دیروزمون زندگی کنیم تا کی واسه فردا ؟ پس امروز چی ؟ الان که وقت گفتن از بی وفایی ها نیست .

پس دلتنگی های قشنگمونو می گذاریم تو کلبه دلتنگی تا تلخی ناکامی هاش کلبه رو ویرون نکنه .

مهمتر از همه یادمون میره خودمون باشیم گاهی فقط یه اسم و یدک می کشیم،تا کجا ؟

یادمون میره اولین انشایی که نوشتیم چی بود ؟ نوشتن رو یادمون میره .

کاش یادمون نره هستیم .....اینجا .......الان ....... امروز .

پی نوشت : دلم تنگ شده بود واسه اینجا . چرا فراموش کردم ؟

بعد از پی نوشت : نه الکی نوشتم و نه از روی سیاه کردن صفحه .

baghegolhayeman — Wed, 01 Jul 2009 23:03:46 GMT

امروز از همیشه تنهاترم ...

تیک تاک ثانیه ها را تازه باور کردم ...

اشک ابرها را دیشب لمس کردم

وقتی بی بهانه گریه میکردند !

تازه فهمیده ام مردم چقدر غریبه اند ...

میدانم همه بی وفایند ...

گل خشک یادگاریت

هر روز خشک و خشک تر میشود ...

آرزوهای من هم به همراهش ...!

baghegolhayeman — Sat, 20 Jun 2009 20:49:18 GMT

اول سلام و بعد ....

سنگ از کمان پسرک رها شد.
به سینه ی شیشه خورد.آن را شکست.
کنار خورده های آن نشست.
شیشه که صد پاره شده بود نالید:خدایا شکرت.
سنگ با تعجب گفت:خدایا شکرت!؟
شیشه،شکسته بسته گفت:وقتی که تنها باشی همنشینی
با سنگ ام موهبتی ست.

همین!

baghegolhayeman — Wed, 06 May 2009 07:06:49 GMT

سلام شما رای می دید؟

جان چی می دیم؟

رای؟

نه آقا ما فقط دست می دیم .

سلام شما رای می دید؟

به جون مامانم من تازه رای دادم بابام گفته فقط هر 4 سال یه بار رای بدم منم به مامانم رای دادم و تا 4 سال مامان رییس خونست .

سلام شما رای می دید؟

بله حتما چرا که نه این وظیفه شرعی و قانونی و حق منه مال منه سهم منه عشق منه .

هییییییی آقا در مورد انتخابات داشتیم صحبت می کردیم

آهان بله خب من رای می دم

به چه کسی ؟

خب به اکبر علی .....

هیییییییییییی آقا تبلیغات نکن و اسم نبر بگو فقط به چه جور آدمی ؟

آهان شما از اون نظر حساب می کنی خب اممممم چه سوالیه بلاخره اکبرعلی .... هم یه آدمه دیگه

سلام شما رای می دید ؟

بله

به چه کسی؟

بستگی داره

به چی ؟

انتخابات چند شنبه است ؟

جمعه چه ربطی داره حالا

نه دیگه جمعه تعطیله کاغذ سفید می ندازم

سلام شما رای می دید ؟

البته

به چه کسی؟

اونی که خط امامیه

آفرین دمتون قیژژژ حالا یه کم بیشتر توضیح بدین تا الان که کسی دو کلوم حرف حساب نزده شما بگو

بله والا منم نمی دونم تو تلویزیون شنیدم فکر کنم یعنی خونشون خیابون امام باشه

سلام شما رای می دید؟

اهم عمری چرا که نه

به چه کسی ؟

آقا فقط تکلیف شناس باشه

ایول خب بیشتر توضیح بدید یعنی چی تکلیف شناس باشه ؟

اینو اون دانشجوهه تو مصاحبه و تریبون آزادی که بود گفت منم بچه دانشجو و مدرسه ای دارم پس منم به یه تکلیف شناس رای می دم تا بچه ها تو درس و تکلیف و مشق دیگه مشکلی نداشته باشن .

سوال از خود خبرنگار

شما رای می دید ؟

خواهی نشوی رسوا همرنگ جماعت شو امروز به این نتیجه رسیدم .

بی ربط 1:

هیچ اعتراضی پذیرفته نیست .

بی ربط 2:

بی ربط بالایی رو همینجوری نوشتم ولی اگه کسی خواست دقت کنه می تونه هر برداشتی در مورد پست و بی ربطش داشته باشه .

baghegolhayeman — Mon, 27 Apr 2009 18:30:37 GMT

کلاس کارگاه عمومی

د د :استاد میشه به من کمک کنید

ا:بله جانم بگو

د د : استاد اینو برام باز می کنید

ا : (آخه ابله من زورم کمتر از تو نباشه بیشتر نیست) آقای ... لطف می کنید به این خانم کمک کنید .

د پ : بفرمایید خانم کار دیگه ای هم هست بفرمایید تا من انجام بدم (چی میشه خودش صدام کنه به استاد نگه اون وقت منم بهش می گم بله عزیزم)

د د : استاد میشه بیاید اینجا .

ا : بله جانم بگو

د د : استاد میشه اینو سوهان بکشید من ببینم چه طوریه

ا : (ای لعنت بر .....اگه بهت نمره دادم ) آقای ... لطف می کنید ...

د د : استاد میشه این دستگاه برش و تنظیم کنید

ا : (شیطونه میگه از کلاس بندازمش بیرون انگار اینا نمی دونن استاد کارگاه عمومی یه فوق دیپلم جانورشناسیه که از قضا فامیلیش با فامیلی یه استاد دیگه و چند تا مسئول کارگاه و حراست دم در آبدارچی رئیس یکیه.) آقای ...

د پ : بله استاد می دونم .

ا : خب بچه ها دیگه می تونید برید

د د : خسته نباشید آقای .........

پی نوشت یا همون باربط و بی ربط خودمون:

لغات دشوار متن:

د د : دانشجوی دختر

د پ : دانشجوی پسر

ا : استاد

baghegolhayeman — Thu, 23 Apr 2009 16:38:18 GMT

باغ ایینه
چراغی به دستم، چراغی در برابرم:
من به جنگ سیاهی می روم.

گهواره های خستگی
از کشکش رفت و آمدها
باز ایستاده اند،
و خورشیدی از اعماق
کهکشان های خاکستر شده را
روشن می کند.
***
فریادهای عاصی آذرخش -
هنگامی که تگرگ
در بطن بی قرار ابر
نطفه می بندد.
و درد خاموش وار تک -
هنگامی که غوره خرد
در انتهای شاخسار طولانی پیچ پیچ جوانه می زند.
فریاد من همه گریز از درد بود
چرا که من، در وحشت انگیز ترین شبها، آفتاب را به دعائی
نومیدوار طلب می کرده ام.
***
تو از خورشید ها آمده ای، از سپیده دم ها آمده ای
تو از اینه ها و ابریشم ها آمده ای.
***
در خلئی که نه خدا بود و نه آتش
نگاه و اعتماد ترا به دعائی نومیدوار طلب کرده بودم.
جریانی جدی
در فاصله دو مرگ
در تهی میان دو تنهائی -
[ نگاه و اعتماد تو، بدینگونه است!]
***
شادی تو بی رحم است و بزرگوار،
نفست در دست های خالی من ترانه و سبزی است

من برمی خیزم!

چراغی در دست
چراغی در دلم.
زنگار روحم را صیقل می زنم
اینه ئی برابر اینه ات می گذارم
تا از تو
ابدیتی بسازم.

احمد شاملو

سلام دوستای گلم امیدوارم همه همیشه خوب باشید فعلا یه شعر از استاد شعر احمد شاملو گذاشتم تا اینکه خودم شروع کنم دوباره به نوشتن.

فعلا !

راستی مین و آتیش عزیز چرا قالب وبتون اینجوری شده من نمی تونم تا آخر نوشته هاتونو ببینم و قسمت نظرات هم دیده نمی شه که نظر بزارم دلم براتون تنگ شده یه فکری به حالش کنید لطفا می خوام نوشته هاتونو تا آخر بخونم .

baghegolhayeman — Thu, 29 Jan 2009 12:54:47 GMT

دخترها:
۱- توی ماهيتابه روغن ميريزن
۲- زير ماهيتابه رو روشن ميكنن
۳- تخم مرغها رو ميشكنن و همراه نمك توی ماهيتابه ميريزن
۴- چند دقيقه بعد نيمروی آماده رو نوش جان ميكنن

پسرها:
۱- توی كابينتهای بالايی آشپزخونه دنبال ماهيتابه ميگردن
۲- توی كابينتهای پايينی دنبال ماهيتابه ميگردن و بلاخره پيداش ميكنن
۳- ماهيتابه رو روی اجاق گاز ميذارن
۴- توی ماهيتابه روغن ميريزن
۵- توی يخچال دنبال تخم مرغ ميگردن
۶- يه دونه تخم مرغ پيدا ميكنن
۷- چند تا فحش ميدن
۸- دنبال كبريت ميگردن
۹- با فندك اجاق گاز رو روشن ميكنن و بوی سركه همراه دود آشپزخونه رو بر ميداره
۱۰- ماهيتابه رو ميشورن (بگو چرا روغنش بوی ترشی ميداد!)
۱۱- ماهيتابه رو روی اجاق گاز ميذارن و توش روغن واقعی ميريزن
۱۲- تخم مرغی كه از روی كابينت سر خورده و كف آشپزخونه پهن شده رو با دستمال پاك ميكنن
۱۳- چند تا فحش ميدن و لباس ميپوشن
۱۴- ميرن سراغ بقالی سر كوچه و ۲۰ تا تخم مرغ ميخرن و برميگردن
۱۵- تلويزيون رو روشن ميكنن و صداش رو بلند ميكنن
۱۶- روغن سوخته رو ميريزن توی سطل و دوباره روغن توی ماهيتابه ميريزن
۱۷- تخم مرغها رو ميشكنن و توی ماهيتابه ميريزن
۱۸- دنبال نمكدون ميگردن
۱۹- نمكدون خالی رو پيدا ميكنن و چند تا فحش ميدن
۲۰- دنبال كيسهء نمك ميگردن و بلاخره پيداش ميكنن
۲۱- نمكدون رو پر از نمك ميكنن
۲۲- صدای گزارشگر فوتبال رو ميشنون و ميدون جلوی تلويزيون
۲۳- نمكدون رو روی ميز ميذارن و محو تماشای فوتبال ميشن
۲۴- بوی سوختگی رو استشمام ميكنن و ميدون توی آشپزخونه
۲۵- چند تا فحش ميدن و تخم مرغهای سوخته رو توی سطل ميريزن
۲۶- توی ماهيتابه روغن و تخم مرغ ميريزن
۲۷- با چنگال فلزی تخم مرغها رو هم ميزنن
۲۸- صدای گــــــــــل رو از گزارشگر فوتبال ميشنون و ميدون جلوی تلويزيون
۲۹- سريع برميگردن توی آشپزخونه
۳۰- تخم مرغهايی كه با ذرات تفلون كنده شده توسط چنگال مخلوط شده رو توی سطل ميريزن
۳۱- ماهيتابه رو ميندازن توی سينك
۳۲- دنبال ظرفهای مسی ميگردن
۳۳- قابلمهء مسی رو روی اجاق گاز ميذارن و توش روغن و تخم مرغ ميريزن
۳۴- چند دقيقه به تخم مرغها زل ميزنن
۳۵- ياد نمك ميفتن و ميرن نمكدون رو از كنار تلويزيون برميدارن
۳۶- چند ثانيه فوتبال تماشا ميكنن
۳۷- ياد غذا ميفتن و ميدون توی آشپزخونه
۳۸- روی باقيماندهء تخم مرغی كه كف آشپزخونه پهن شده بود ليز ميخورن
۳۹- چند تا فحش ميدن و بلند ميشن
۴۰- نمكدون شكسته رو توی سطل ميندازن
۴۱- قابلمه رو برميدارن و بلافاصله ولش ميكنن
۴۲- چند تا فحش ميدن و انگشتهاشون كه سوخته رو زير آب ميگيرن
۴۳- با يه پارچهء تنظيف قابلمه رو برميدارن
۴۴- پارچه رو كه توسط شعله آتيش گرفته زير پاشون خاموش ميكنن
۴۵- نيمروی آماده رو جلوی تلويزيون ميخورن و چند تا فحش ميدن

امیدوارم خیلی تکراری نبوده باشه بیشتر می یام شاید با یه تغییر و تحول خیلی بزرگ