Re: HTTP 1.1 pipelining & persistent connections query

From: matthew halsey ([email protected])
Date: Fri Aug 01 1997 - 12:20:00 EDT


Form: Reply
Text: (15 lines follow)
John,

Thanks for info, it backs up what everyone has told me that my file sizes
were too large.
However, I have one question for you. I thought slow start (that is the
start of transmission) is exponential but that congestion avoidance is only
invoked in congestion recovery?

In TCP/IP Illustrated Vol1 p. 286, W.R. Stevens states that slow start
yields an exponential increase until congestion is reached, as noticed by
dropped packets. Then congestion recovery is invoked and the congestion
avoidance algorithm is used as seen in fig 21.8 of same book and as
described by you?

Matt
Original text: (76 lines follow)
>From JVM@SMTPGATE (John V. Martinez) {jvm%[email protected]},
on 1/8/97 11:21 AM:
To: TCP-OVER@SMTPGATE {[email protected]}

-----BEGIN PGP SIGNED MESSAGE-----

At 09:34 AM 7/30/97 -0400, Matthew wrote:

>Can someone explain pipelining and persistent connection benefits of HTTP
>1.1 to me?
>I have set up a simple spreadsheet to analyse this and get contradictory
>results.
>I have one column which is a single persistent TCP connection to transfer
>1MByte, it takes 20 RTTs as can be seen in second column.

Hi Matthew,

Try re-building your spreadsheet for some smaller numbers - the performance
(and reduced net-traffic) benefits of HTTP 1.1 pipelining make the most
sense
for a 'typical' web page, where the main page is about 1-2k, and then there
are a few small buttons/graphics each a few dozen kbytes. In this (extremely

common) case, where the total data to be tranferred is small, individual TCP

connections make for horrible performance, because the TCP slow-start
algorithm takes so long to crank up that by the time the window size has
reached something reasonable, you are done transferring data, and are
closing
down the connection. (Also, the ratio of data packets to connection control
packets is awful when you open many small connections -- this is an
expensive
way to use limited transponder bandwidth.) Opening just one, persistent
connection means that your TCP connection will last longer, and have more
opportunity to operate with a large window.

Another point: in your spreadsheet, you seem to be assuming that the TCP
window will *double* on every round-trip until it reaches 64k. This doubling

only happens during the slow-start phase, until the window size reaches a
certain threshold (anyone have references for what a common threshold is?
8k?) -- after reaching that threshold, TCP switches into
congestion-avoidance
mode, where one packet is added to the window for every N packets received,
where N is the current window size. So it actually takes much longer to get
all the way to a full 64K window size. :^(

A recent paper in IEEE/ACM Transactions on Networking might be of interest:

Lakshman and Madhow, "The Performance of TCP/IP for Networks with High
Bandwidth-Delay Products and Random Loss" IEEE/ACM Trans. Networking, vol 5,

Number 3, pp.336-350, June 1997

- -(-- John

-----BEGIN PGP SIGNATURE-----
Version: PGP for Personal Privacy 5.0
Charset: noconv

iQEVAwUBM+H/BUtiS8INJvWxAQEoYwf9F9bEJBfhAemoX1/Ezv5kh4sdQXF0quOP
Rxb9VtqIxC2DY1/yD+PUSg+ZbnIar0G4kchQ5E00jg0XNZb7PaUvGdP/JSD3r2/z
j4aVS8Xy4vJMALbi4vZUdzoRuAcpzdVT3TU3Kts3oTFDGlRYJTzfpK/r/k5UPx0w
gPsBcLOdWclMHLp6l512LWZI+WU8+g2RjcR1TyWLH0w88FHRpk8MEqnFOLw6QCdn
sQpz3lV0vvCuihYaye1uswC37jQuq1Qo5SvqVr+8w4mraVSkoulR2iEvgfNEl35M
JZ5Qs3ReGRRBw8UssjmFZYx/QHg4ZlzrkxkLZCCxMTiY2Tjv4Q+wgQ==
=Tqh1
-----END PGP SIGNATURE-----

-(--- John V. Martinez - [email protected] -
HM:(404) 892-0060 WK: 870-0001x29 FX: 870-0075 CL: 630-0913
PGP Key Fingerprint: 3B F1 5D 94 3C 3C 05 30 - 57 38 60 86 1E F8 CA 20
>> Making the world safe for satellite communications and ice cream. <<

Use Proportional Font: true
Previous From: JVM@SMTPGATE (John V. Martinez) {jvm%[email protected]}
Previous To: TCP-OVER@SMTPGATE {[email protected]}
Attachment Count: 0





This archive was generated by hypermail 2b29 : Mon Feb 14 2000 - 16:14:28 EST