Re: Life after source quench


Charley Kline (kline@uxc.cso.uiuc.edu)
Mon, 9 Nov 87 12:11:02 CST


Gosh Professor Mills, you guys all yelled at me so much when I
mentioned that d.ncsa.uiuc.edu didn't respond to quenches that I
thought I'd better do it right. Do I get an A on my project?

As Ed pointed out, the method that our "Craykitten" uses in response to
a source quench is simply to shackle all packets in the IP output queue
destined for the originator of the quench (I mean the ip_dst of the
packet returned in the quench) such that there is a delay of X
milliseconds before each is transmitted. X is initially zero, and the
current parameter is to increase it by 500 milliseconds for each quench
received. If no quenches are received for 30 seconds, X is halved. An X
lower than 500 causes the quench reaction to stop. This all happens in
the IP module, and TCP is unaware of the quenches.

I'm sure that the reason that the fuzzball is issuing quenches every
thirty seconds is because if only one quench is sent, IP throttles back
to one packet every 500 milliseconds (which should keep the fuzzball
happy), but when the 30 second quench reaction stops, IP starts
vomiting the packets full blast again, which causes another quench. I'm
pleased that the quench mechanism creates such effective data rate
communication between an IP module and IP gateways.

I can't take credit for the method, it's an implementation of Postel's
proposal. I only messed with the parameters.

-----
Charley Kline
University of Illinois Computing Services
kline@uxc.cso.uiuc.edu
kline@uiucvmd.bitnet
{ihnp4,uunet,pur-ee,convex}!uiucuxc!kline



This archive was generated by hypermail 2.0b3 on Thu Mar 09 2000 - 14:39:55 GMT