Still on speeding up RX:
What's a decent way to detect congestion, and what's the best way to
handle it?
The current RX way of three nacks in a row is hardly adequate - UDP
packets can and do get reordered!
Also, running at wire speed does not prevent the odd TCP packet sneak
in and cause a drop at the uplink (as seen from the receiver) - here
an optimistic retransmit (for example in the second half of the xmit
window) without reducing window sizes or waiting for acks helps a lot.
But in a chronic congestion scenario (e.g. two streams ending up on
the same receiver) this does not help: even the re-transmitted packet
has a reasonable chance of getting dropped and the protocol is running
at retransmit-timeout speed again. (it's actually worse:
retransmitting wildly, even if insured only once per packet, almost
doubles the traffic -worst case- and increases the chances for drops).
Here slowing down at the sender helps keeping the timeouts out of the
game.
In the above scenario the sender actually knows a lot upon ack - how
fast the receiver is digesting packets and what holes he's got. What
would you conclude if you received an ACK looking like
----++++++++++++++++----++++--------+++++----++++++++++++ ?
Common practice suggests keeping sender & receive at the same pace is
best, hence reducing the window would be the answer. But the price is
high as the pace can change and the sender would know only late
because of latency! And since memory is cheap, perhaps always filling
big windows with lots (200? 500?) of packets assuming efficient
queueing and dealing with drops is better, even under congestion?
(I loosely followed discussions on TCP window sizes for trans-atlantic
fibres in the late 90s... is this summarized somewhere)?
--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
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
