On Thu, 29 Aug 1996 15:04:05 -0700 Paul A Vixie wrote:

Since I use programmable routers, I plan to reprogram them such that when an interface output queue is full or getting full, and it's time to do Van's trick of "pick a number from 1 to N+1 and destroy that packet", the chance of a UDP getting blasted will be higher than for a TCP.

This is predicated on (1) TCP is mostly well behaved, except when it comes form a Netscape browser opening too many (more than one) simultaneous TCP connection to the same destination; (2) UDP apps I care about, like DNS, will do reasonable things like fallback and timeout and retry; and (3) it is OK to violate the layering if it makes your network stop melting.

If you think this would be a useful feature, ask Cisco to make it part of SPD.

We have a user who has been doing this for around 3 months now. They have a setup as follows: T1-cisco-Unix-cisco-LAN. The Unix box works as a programmable router for the T1 traffic. When someone started running 5 concurrent ping -f sessions, saturating the T1 line with ping packets, the Unix box was instructed to take the ping traffic and move it to a buffer and freeze it there for 4 seconds and then let it move onward. This caused the pings to slow down. He has it now set with different buffer sizes and different freeze periods for different protocols i.e. telnet gets 0 time in the freezer whereas http can go up to 540kb/sec and anything over that the pkts start getting put in the buffer-freezer. Since they pay per GB to IBM for their Internet capacity they have used this box as a method to limit traffic during peak hours. Hank