Actually, TCP is a single sliding window protocol, which limits its
performance on seriously lossy and long delay transmission media.
We assume that a sender has sent packets [A] [B] [C] [D] [E] while
the receiver has received packets [A] [C] [E]. With TCP the receiver can
only tell the sender that [A] has reached. If the receiver can notify
the sender that both [B] and [D] should be re-sent, the performance will
be better.
------------------------------------------------------------------------
From Beijing, China
Mark Allman wrote:
1. Receiver should tell sender to re-send as soon as possible.
(But TCP makes receiver purely passive)
This isn't really going to help you at all. With SACK (especially, but
even without it) the receiver isn't really in a whole lot better
position than the sender to judge when a packet is actually lost. Some
people have worked on SNACKs (selective NEGATIVE acknowledgments), but
my opinion is that the results (that I have seen) show them to be fairly
equivalent to SACK in terms of performance.
2. Receiver should tell sender what is really necessary to re-send.
(Sometimes only a single ACK number of TCP cannot include enough
information)
RFC2018. (Which provides more than a single ACK number. But, this
doesn't make the receiver tell the sender what to resend. The logic
still resides at the sender.)
allman
_______________________________________________
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
