>looking at traces with longer delays, I've seen a number of cases
>where timeouts happen in less than 2 RTT. I don't know what the
Right. If the variance in the round trip is low, the RTO will be not much
greater than the SRTT. This provided a considerable improvement in
throughput over paths with stable delay but a high loss rate. Before Van
Jacobsen made this change, the RTO started at some multiple of the SRTT
and performance on a lossy path was even worse than it is now.
>and timeouts needs at minimum some clarification. Perhaps it would be
>appropriate to also add some help for link layers with ARQ, (for
>example, making the RTO base on 2 RTT, or being more conservative
I think my approach of a expiration timestamp is the cleaner approach.
But I doubt that it would be worth the effort in most cases. Anybody
want to run some simulations?
>Second, I've been considering writing up a new type of SACK option.
>The specific idea I had was to make one which I jokingly call a CRACK
>(CoRruption ACK) for specific use with wireless. Receivers should, in
>principle, be able to detect packets with failed checksum and send
>back a CRACK indicating to the sender that a packet has been dropped,
>but it is not a sign of congestion -- retransmit the packet but don't
>reduce cwnd.
If you are referring to packets with a failed TCP checksum, I don't
think that would help much. TCP checksum failures are very
rare. That's because link errors are usually caught by link-level
checksums or CRCs, so the packet never makes it to the destination
TCP.
The one exception is SLIP over old dialup modems without error
correction. But both SLIP and modems without error correction are
practically extinct these days.
>would be corruption or failed checksum. Another one which might be
>useful in a RUTS context is something along the lines of "I don't have
>this data yet, but I don't need it anymore" which could be used by
We saw a presentation at the end-to-end group meeting of a protocol
with this feature that's designed for multilayered video delivery.
Not clear it's something that can be easily retrofitted into TCP with
its guaranteed, in-order semantics; it may require a new protocol
designed specifically for these real-time applications.
>In both of these cases, I'm unsure of the actual practical
>usefulness. For example, if most wireless corruption causes packets
>never to make it to the stage of being checksummed, there wouldn't be
>much use. If people think these ideas would be useful, though, please
Right.
--Phil
This archive was generated by hypermail 2b29 : Mon Jan 28 2002 - 09:12:19 EST