This would be a big step. If you'd like to see a recent example of how
failure to make this distinction added 40% to a 2MB transfer over a 0.24%
errored link, for a major service provider, I'll be happy to send it.
In addition, we have some help built into IP that we don't use -- the ID.
This could be passed up to the sending and receiving transports and used to
distinguish which Acks (after a retransmission) really just indicate a longer
RTT and which are truly repeated Acks due to loss -- you can have the patent,
but you have to put my youngest through college.
Alex
Nitin H Vaidya wrote:
>
> >> From mahdavi@novell.com Thu Jan 21 09:40:34 1999
> >>
> ...
> >>
> >> 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.
>
> I guess something like that might be useful.
> Several variants on this type of ACK have been suggested in recent
> years and are often called "explicit notifications" (in the context of
> wireless networks). The explicit notifications could be implemented
> as ICMPs or special form of TCP acks. Such notifications could be
> sent by the receiver node when it detects that the
> packet fails checksum, could be sent by the base station if
> it detects that the next (wireless) link is broken, etc.
> Then there are "partial acks" which could be sent
> by the base station to indicate that a packet is queued up
> waiting for the wireless link to get back to a good state.
>
> - nitin
This archive was generated by hypermail 2b29 : Mon Jan 28 2002 - 09:12:19 EST