Subject: RE: Burstiness WIth increased max cwnd.

From: "Samaraweera, Nihal" <[email-masked]>
Date: Fri, 25 Feb 2000 09:16:03 -0000

This is my favorite reference which explains the problem (please check the 
latest version from the IETF web).

C. Partridge, 'ACK Spacing for High Delay-Bandwidth Paths with Insufficient
Buffering', IETF, draft-partridge-e2e-ackspacing-00.txt, July 1997.

I also got some more explanation and simulation results:

N.K.G. Samaraweera, 'Return Link Optimisation for Internet Service Provision

Using DVB-S Networks', CCR, ACM SIGCOMM, volume 29, number 3, July 1999. 
http://www.acm.org/sigcomm/ccr/archive/1999/jul99/ccr-9907-samaraweera4.html
.

good luck!!
nihal.

-----Original Message-----
From: mukul goyal [mailto:[email-masked]]
Sent: 24 February 2000 17:04 PM
To: [email-masked]
Subject: Burstiness WIth increased max cwnd.

With Window scaling in TCP, the back-to-back packets a TCP flow sends
can be very high. I was wondering if there is some study evaluating the
increase in burstiness of TCP traffic with larger cwnd. Or, in general, 
are there some papers talking about how bursty the traffic is as seen by a
router?

Thanks,
Mukul

---

From: Lloyd Wood <[email-masked]>
Date: Fri, 25 Feb 2000 11:03:48 +0000 (GMT)

> latest version from the IETF web).

That's from July 1997, and internet drafts expire after six months.

good luck finding a copy...

L.
> are there some papers talking about how bursty the traffic is as seen by a

<[email-masked]>PGP<http://www.ee.surrey.ac.uk/Personal/L.Wood/>

---

From: Kacheong Poon <[email-masked]>
Date: Fri, 25 Feb 2000 12:49:26 -0800 (PST)

> Buffering', IETF, draft-partridge-e2e-ackspacing-00.txt, July 1997.

The latest version should be draft-rfced-exp-partridge-01.txt.

> There really are two different "burstiness" definitions, I think.
> One is outlined above.  That is, how many segments are sent in
> response to each ACK (a sort of "micro burstiness").  The other
> version would be a "macro burstiness", which is caused by ACKs
> arriving one right after another causing causing a large amount of
> data transmission (but, not at line rate).  This is especially true
> on long-delay links.  What you see during slow start is all the ACKs
> arriving at the beginning of the RTT, causing a macro burst of data
> packets, followed by a long idle period that we spend waiting for
> the ACKs.  There is a nice paper that talks about these macro
> bursts....

I see what the "burst" is referred to here now.  It is my English ):  The
problem is about the total number of TCP segments for a connection in the
network at any time.  And when TCP is in slow start, this number doubles for
every RTT.  So Mukul's question is how the network responds to this large
number of segments.  I have never considered this as a burst before...
Thanks for clearing the "burst" definition.

							K. Poon.
							[email-masked]

---

From: mukul goyal <[email-masked]>
Date: Sat, 26 Feb 2000 12:49:52 -0500 (EST)

Hello All,

Kindly give me your opinions about lack of self-clocking in TCP.

I feel that TCP's self-clocking as illustrated in Van Jacobson's 1988
paper exists only if bottleneck link is a link of lower capacity (i.e.
bandwidth) than other links. However, if bottleneck link has higher
capacity than other links (i.e. the link is bottlenecked because a large
number of flows are using it simulateneously), there is no self-clocking
any more. I guess this is also a main reason why one needs some thing like
paced TCP. (The other reason being significantly less buffer
requirements with paced TCP.)

Thanks,
Mukul

---

From: Craig Partridge <[email-masked]>
Date: Sat, 26 Feb 2000 16:01:55 -0500

any more. 

I don't think it is that simple

Self clocking always occurs -- you inject a packet  in response to an ack and
the ack is telling you when the network has capacity for your new packet.

The issue raised in your note is whether the spacing of the acks reflects the
available bandwidth at the bottleneck.  In most cases the answer is that
it reflects bandwidth only imperfectly.  Ack compression, queueing disciplines,
etc., all conspire to muddy the spacing.

Craig

---

From: mukul goyal <[email-masked]>
Date: Sat, 26 Feb 2000 16:12:43 -0500 (EST)

Thanks for phrasing the problem in better terms. By "lack of
self-clocking" I had meant ACK spacing not reflecting the fair
share of the bandwidth at the bottleneck. But I guess this is not the
correct usage of the term "self-clocking".

Mukul