> From: Curtis Villamizar <[email protected]>
>
> I seem to recall a past discussion on end2end-interest on that
> particular code fragment and further relaxing from the recommendation
> to slam shut. The consensus was that after idle, the window stayed
> open for 1 RTO and then abruptly shut. One suggestion was to reduce
> the value of cwnd in half for each RTO (in thinking about this perhaps
> each 1/2 RTO might work well) rather than all the way to one segment.
> This would close down the window quite a bit for the purpose of
> avoiding a burst into an already loaded path (if more than one RTT has
> passed since idle, other connections may have taken up much of the
> bandwidth that had been allowed to go idle) but would not immediately
> go all the way back to slow start cwnd of one.
Sure - there are many options on what to do when the
connection has been idle. And apparently, many definitions
of what 'idle' means :-)
> Another interesting point wrt HTTP 1.1 is that the first inline image
> is ussually in the first TCP segment of HTML. If so, there is usually
> a few more segments (average HTML file is 2-3KB, right?) so you don't
> go idle. The idle occurs just after the ACK tells the sender that
> there is no data in flight, not after the sender runs out of packets
> to send. If the ACK is delayed (by the delayed ACK algorithm), it
This is the current behavior, but not the intended (as proscribed
in Jacobson's Sigcomm paper). The intended is 'when the sender
goes idle', and it makes much more sense - the purpose is to avoid
a line-rate burst at the sender. It doesn't matter when the acks
arrive; it matters only whether the sender has accumulated more
'send privilege' than it has data to occupy.
For restart, it appears the idle of interest is mainly between requests,
given the relationship to RTO. There remains a possibility that slow systems,
or systems that take a long time to parse requests or traverse their web
filesystem may pause long enough for gaps, but this isn't likely on links
over 10ms.
> I'd be surprised if your testing reveals some other behaviour.
And I am suprised at testing hasn't been conducted earlier. Our earlier
measurements proved that slow-start restart occurred on TCP when the
sender was idle, but didn't consider 1.1 persistent connections with
the return path data. When we tested the latter, we saw a completely
unexpected behavior.
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