In message <[email protected]>, [email protected] writes:
> > btw- Look at rfc2068 at "3.6 Transfer Codings". If "A" is sent as a
> > "chunked" encoding, then "B" can (at least in principle) be sent
> > between chunks of "A" so HTTP 1.1 does not have the flaw you describe
> > above. I think this was one reason for Transfer Codings that was
>
> Even if the chunks are 'interleaved', HTTP 1.1 still stalls _all_
> interleaved streams until a missing packet is received (via retransmission)
> TCP doesn't guarantee that chunks fall on packet boundaries.
> When any packet is lost, all packets following it are delayed until
> the 'hole' is filled in.
>
> Any system that muxes over TCP must have this flaw.
> If the data were sent in different TCP connections, and the
> data from one connection is present, it is not held back by
> a hole in a different connection.
Gee the TCP I run doesn't stall all the data to support one
retransmission, it transmits a window of unacknowledged data and when
it detects that it does need to retransmit (through RTO expire or fast
retransmit), it does the retransmit and only reduces the size of the
window of unacknowledged data, continuing to transmit unacknowledged
data as this reduced window size permits (fast recovery, etc).
What kind of TCP are you running? :)
If you are referring the the receiving side, then rendering is stalled
for at most 1 RTO, but usually 1 RTT plus a few packet times for fast
retransmit. If rendering is faster than data transfer this would not
be a problem (a 1/2 second pause in rendering at 500 msec RTT in a
multisecond transfer - more likely >=10 seconds at 500 msec RTT).
The problem with long RTT and one TCP flow is the chance of a loss
early in the transfer forcing a low ssthresh and going into congestion
avoidance prematurely. The slow growth in window size after premature
loss is a problem for all large window applications.
Curtis
This archive was generated by hypermail 2b29 : Mon Feb 14 2000 - 16:14:29 EST