|
Connected: An Internet Encyclopedia
What to do when an ICMP Source Quench is received Up: Requests For Comments Up: RFC 896 Up: The two problems Up: Congestion control with ICMP Next: Self-defense for gateways
What to do when an ICMP Source Quench is received
Source Quench thus has the effect of limiting the connection to a limited number (perhaps one) of outstanding messages. Thus, communication can continue but at a reduced rate, that is exactly the effect desired. This scheme has the important property that Source Quench doesn't inhibit the sending of acknowledges or retransmissions. Implementations of Source Quench entirely within the IP layer are usually unsuccessful because IP lacks enough information to throttle a connection properly. Holding back acknowledges tends to produce retransmissions and thus unnecessary traffic. Holding back retransmissions may cause loss of a connection by a retransmission timeout. Our scheme will keep connections alive under severe overload but at reduced bandwidth per connection. Other protocols at the same layer as TCP should also be responsive to Source Quench. In each case we would suggest that new traffic should be throttled but acknowledges should be treated normally. The only serious problem comes from the User Datagram Protocol, not normally a major traffic generator. We have not implemented any throttling in these protocols as yet; all are passed Source Quench messages by ICMP but ignore them.
Connected: An Internet Encyclopedia What to do when an ICMP Source Quench is received |
|
Dies ist ein Mirror von Connected: An Internet Encyclopedia von Brent Baccala. Die offizielle Projekt-Homepage findet sich im Web unter www.freesoft.org/CIE. Dieser Mirror wurde zuletzt aktualisiert am Samstag, 28 Januar 2006 18:18 +0100. |