> From [email protected] Thu Aug 7 16:29:20 1997
> Date: Thu, 7 Aug 1997 16:28:34 -0700 (PDT)
> From: Kacheong Poon <[email protected]>
> Subject: RE: Problematic Approaches
> To: [email protected]
> Cc: [email protected], [email protected]
>
> > The problem is that the client asks for a page, then has to receive
> > it before it can be parsed and subsequent requests pipelined. On
> > high bw*delay nets, the window has to slam shut after the first request,
>
> I want to point out a minor point. For most implementations, like BSD, the
> idle interval for TCP to restart slow start is usually 1 RTO, which is greater
> than 1 RTT. So as long as the client can parse the page and generate next
> requests in less than half of RTT, the server TCP will not restart slow start.
> Actually, if we also count the time the ACK for the last segment from server
> to get to the server, the client has even "more" time. So it is not that a
> client machine has to rush, but maybe a user has to rush in reading a page to
> avoid slow start (-:
The client can't parse the page until it arrives; it doesn't arrive
until it gets there. At high bw*delay, that's one RTT during which
nothing occurs.
The BSD implementations in question do not allow their 'possible front'
to exceed their 'current front' by more than 1/2 the window size at
any time, regardless of timers. This is to avoid the line-rate burst.
So, when 1/2 the window is ACKd and there's nothing left to send, the
window slams shut.
It's not clear that rushing to parse the incoming HTML, but rather
waiting in between requests (as you mention) and for the HTML
to arrive (propagation, not parsing delay) that causes the problem.
Joe
----------------------------------------------------------------------
Joe Touch - [email protected] http://www.isi.edu/~touch/
ISI / Project Leader, ATOMIC-2, LSAM http://www.isi.edu/atomic2/
USC / Research Assistant Prof. http://www.isi.edu/lsam/
This archive was generated by hypermail 2b29 : Mon Feb 14 2000 - 16:14:29 EST