I believe two points:
1. Receiver should tell sender to re-send as soon as possible.
(But TCP makes receiver purely passive)
2. Receiver should tell sender what is really necessary to re-send.
(Sometimes only a single ACK number of TCP cannot include enough
information)
------------------------------------------------------------------------
From Beijing, China
Mark Allman wrote:
You can take a look at SCPS - http://www.scps.org/ Their protocol is
used on lossy links with big latency and packet loss (such as
satellites) and overcomes shortcomings of TCP. It works with divert
mechanism of FreeBSD and I ported the tap device part as well to both
NetBSD / FreeBSD (experimental).
It's not clear to me that this is going to help. Fundamentally, TCP and
SCTP share the same congestion control response. At 30% packet loss
SCTP ought to be as unusable as TCP. Both consider losses to be
indications of network congestion.
SCTP does have some things built-in that need to be added onto TCP
(e.g., SACK). So, we could expect more consistent behavior from SCTP
across implementations and platforms. But, in the end the performance
of both is proportional to 1/sqrt(p) where p is the loss rate. So, as
the loss rate increases performance decreases. At 30% you're
essentially cooked no matter which you use.
allman
_______________________________________________
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
