I have two comments I'd like to add to the discussion. First, in
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
causes are yet, but it seems clear that the implementation of timers
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
about computing the delay variance). I'll be happy to contribute more
along these lines as I learn more about what is going on in the
particular cases I am looking at.
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.
A more general approach might be to create a SNACK -- Selective NACK
-- which includes a "reason" field for each NACK. One reason field
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
apps (such as video) wanting "resiliance" -- retransmit if you can do
so quickly, otherwise move on...
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
let me know -- I'll be happy to flesh them out.
--Jamshid
This archive was generated by hypermail 2b29 : Mon Jan 28 2002 - 09:12:19 EST