Subject: Burstiness WIth increased max cwnd.

From: mukul goyal <[email-masked]>
Date: Thu, 24 Feb 2000 12:04:04 -0500 (EST)

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: Zachary Amsden <[email-masked]>
Date: Thu, 24 Feb 2000 14:36:04 -0800

Yes, there are many:

M. Allman, C. Hayes, H. Krusem, and S. Ostermann
TCP Performance over Satellite Links
Proceedings of 5th International Conference on Telecommunication Systems

M. Aron and P. Druschel
Soft timers: efficient microsecond timer support for network processing
Operating Systems Review 34(5), Dec. 1999

H. Balakirshnan, V.N Padmanabhan, R. H. Katz
The Effects of Asymmetry on TCP Performance
Proceedings of 3rd ACM Conference on Mobile Computing nand Networking

W. C. Feng, D. D. Kandlur, D. Saha, and K. G. Shin.
Understanding and improving TCP performance over networks with minimum rate 
guarantees
IEEE/ACM Transactions on Networking, 7(2), Apr. 1999

V.N. Padmanabhan and R. H. Katz.
TCP Fast Start: A Technique For Speeding Up Web Transfers
Proceedings of the IEEE GLOBECOM '98 Conference, Nov 1998

V. Visweswaraiah and J. Heidermann.
Improving restart of idle TCP connections.
Technical Report 97-661, University of Southern California, Nov 1997

---

From: Kacheong Poon <[email-masked]>
Date: Thu, 24 Feb 2000 15:12:41 -0800 (PST)

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

Do you mean the bursty traffic after there is a dropped segment?  If there is
no dropped segment (including ACKs), TCP is as bursty as it is without window
scaling, sending 3 segments for every ACK (assuming delayed ACK for every 2
segments).  I believe many implementations now have some simple form of
bursty control.  And with SACK and various forms of NewReno, I think TCP is
not as busrty as it used to be when there is no window scaling. 

							K. Poon.
							[email-masked]

---

From: Zachary Amsden <[email-masked]>
Date: Thu, 24 Feb 2000 18:24:42 -0800

> not as busrty as it used to be when there is no window scaling. 

TCP is still bursty over high bandwidth-delay product links while inflating 
the congestion window.  Basically everything in the window is trasmitted at 
once, and when ACKs arrive, the process repeats with a larger window.  Thus 
larger windows cause the burstiness to proceed for longer amounts of time.

-- 
Zachary Amsden  [email-masked]  (650) 933-6919  09U-510  Core Protocols

---

From: Kacheong Poon <[email-masked]>
Date: Thu, 24 Feb 2000 18:35:15 -0800 (PST)

> larger windows cause the burstiness to proceed for longer amounts of time.

What do you mean by "trasmitted at once?"  TCP does not send the whole window
all at once.  Do you mean the case when after the link is idle for some time,
TCP can send the whole window at once?  I think this has been discussed before
and the problem is an implementation bug.  Joe Touch has a note on this.

Or do you mean something else?  Note that congestion window (cwnd) is inflated
based on incoming ACKs.  The rate of increase is determined by the rate of
incoming ACKs.  And for every ACKs, it can send up to 3 segments.  This is
the burstiness.  And cwnd is reduced back to 1 (or 2 or 3 segments depending
on whether the implementation uses larger slow start cwnd) after the link is
idle.

One exception is when there is segment dropped.  But as I mentioned
previously, I think it is not as bad as it used to be.  There are other
issues, say ACK compression, ...  But I think a larger window does not make
this worse than before.  Please elaborate.

							K. Poon.
							[email-masked]

---

From: mukul goyal <[email-masked]>
Date: Thu, 24 Feb 2000 21:44:27 -0500 (EST)

No, I was not referring to burstiness after dropped segment. 

TCP may potentially send a large number of packets in rapid succession 
followed by a relatively large period of silence. This will happen if
ACKs arrive in rapid succession. I am interested in studying this
phenomenon and how frequent is this with both default and scaled window
sizes.

I was wondering if previous work exists on this topic. 

Also, I will be interested in knowing what are the burst control
techniques currently being employed by various implementations.

Thanks,
Mukul

---

From: Zachary Amsden <[email-masked]>
Date: Thu, 24 Feb 2000 21:39:43 -0800

> this worse than before.  Please elaborate.

I am talking about burstiness in slow start, while the congestion window is 
growing.  When doing slow start, the small initial congestion window is 
transmitted fairly rapidly, then waits for ACKs.  When the ACKs arrive, they 
arrive fairly rapidly as well, and the congestion window grows and again the 
same process occurs.  If and when the window grows large enough that an ACK is 
received for the start of the window right after we send the last window 
chunk, the burstiness stops.  But if the window never grows this large, then 
this equilibrium won't set in, and the connection remains bursty.

I believe that is the type of burstiness Mukul was referring to.  This is 
exacerbated when using high b*d links because many segments can be in the 
pipe, necessitating a larger window.

In any case, no, TCP over high b*d links is not bursty at equilibrium, but 
with too small a window the connection appears very bursty unless rate-based 
clocking is used.  Neither do large windows cause burstiness - too small 
windows cause burstiness.  But it takes longer for the ideal window size to be 
reached when windows are large.