Looking at some of the RX performance problems that we see in
particular with respect to single stream throughput I stumbled across
the following:
upon receipt of an ACK the sender retains all ACKed packets above
[t]first in the transmission queue (i.e. until they're hard acked).
The question is: why? The packet has been received by the RX stack at
the receiver, albeit not delivered to the "consumer". There is
certainly a point throttling transfer at the sender for congestion,
hence transmission and congestion windows, but why would the sender
ever need to resend a packet to a receiver who's already got it?
And if it could... what would be the mechanism? I only see the
possibility of explicitly nacking the packet later again, but unless
the receiver would drop a packet already received this can't be as far
as I can see, and I don't see the latter happening. Am I struck with
blindness or is this ancient history?
Given that long queues in conjunction with big window sizes are a drag
I plan to short-circuit this. Any comments?
--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Rainer Toebbicke
European Laboratory for Particle Physics(CERN) - Geneva, Switzerland
Phone: +41 22 767 8985 Fax: +41 22 767 7155
_______________________________________________
OpenAFS-devel mailing list
[email protected]
https://lists.openafs.org/mailman/listinfo/openafs-devel
