Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sun-barr!apple!salt.acc.com!opal!art
From: art@opal.acc.com (Art Berggreen)
Newsgroups: comp.protocols.tcp-ip
Subject: Re: Congestion AVoidance Help Needed
Message-ID: <1991Jun3.171444.19287@salt.acc.com>
Date: 3 Jun 91 17:14:44 GMT
References: <9106012137.AA20860@ucbvax.Berkeley.EDU>
Sender: news@salt.acc.com
Reply-To: art@opal.acc.com (Art Berggreen)
Organization: Advanced Computer Communications, Santa Barbara, California
Lines: 29

In article <9106012137.AA20860@ucbvax.Berkeley.EDU> WELDEN@JAGUAR.ESS.HARRIS.COM writes:
>
>                CONGESTION AVOIDANCE WHEN ICMP CAN'T BE USED
>                ********************************************
>
>I need feedback views and experience for a network situation we are facing in
>using the TCP/IP protocols in a secure application.
>
>Hosts on IEEE 802.3 LANs connect to a Packet Encryption Device and then by an
>IEEE 802.3 LAN to an IP Router and then out into a WAN to the reverse set of
>eomponents. The Packet Encryption Device will be a NSA approved item and will
>create a barrior between the Hosts and the IP Router. 
>
>When congestion starts in the WAN the IP Router would normally generate an ICMP
>Source Quench packet to be sent back to the source Host but the Packet Encryp-
>tion Device blocks it.
>
>I need to know if anyone else has experienced this situation and/or what solid
>recommendations ca be made. We feel we must be able to slow down selected
>sourceHosts in order to manage congestion avoidance in the network.

Well, there are a lot of people who believe that Source Quenches are of
very limitied utility, and that modern transport implementations (e.g.
Slow-Start TCP) can do a good job of adapting to congestion by monitoring
the loss of packets.  Source Quenches themselves can easily be lost
during congestion, and many routers rate limit the number of Source
Quenches generated anyway.

Art