[OpenAFS-devel] Question about RX & congestion

[chas williams - CONTRACTOR]

In message <47D8EA32.1040600@pclella.cern.ch>,Rainer Toebbicke writes:
>What's a decent way to detect congestion, and what's the best way to 
>handle it?

you might want to read a bit about udt.  they have some good ideas
about udp performance: http://udt.sourceforge.net  i think this is
perhaps the most relevant: http://www.cs.uic.edu/~ygu/paper/pfldnet2005-v8.pdf
but there are others: http://udt.sourceforge.net/doc.html

>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
>
>----++++++++++++++++----++++--------+++++----++++++++++++ ?

i guess i would say slow down/rate limit.

>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?

if you model congestion as some sort of delay, then increasing the
window size would be the right answer (bandwidth delay product).  if the
congestion is merely reordering, then sure its just delay.  if the
congestion is actually loosing data, then i would suggest smaller windows.
unforunately iterating long queues isnt a good idea.  this can tie
up a cpu long to allow retransmit timers to expire.