Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!uunet!husc6!rutgers!ames!sdcsvax!ucsdhub!hp-sdd!hplabs!ucbvax!A.ISI.EDU!CERF
From: CERF@A.ISI.EDU
Newsgroups: comp.protocols.tcp-ip
Subject: Re: ISO8473 vs. IP
Message-ID: <[A.ISI.EDU].9-Sep-87.06:13:59.CERF>
Date: Wed, 9-Sep-87 06:13:00 EDT
Article-I.D.: <[A.ISI.EDU].9-Sep-87.06:13:59.CERF>
Posted: Wed Sep  9 06:13:00 1987
Date-Received: Fri, 11-Sep-87 01:43:14 EDT
References: <8709081824.AA09821@nic.nyser.net>
Sender: daemon@ucbvax.BERKELEY.EDU
Organization: The ARPA Internet
Lines: 15

RE: DEC Bit (Congestion Experienced)

When I talked with Tony Lauck about this notion, the idea was
that you could tell the receiving party "sooner" than the sending party
about this congestion problem and that the receiving party might use
the window mechanism to reduce the sender's ambition level until the
congestion had died away. The sender probably needs to know about
the congestion explicitly, too, if there is any option for re-routing
the traffic from the origin via an alternate path which is less
congested.

It would be helpful to hear from Digital about their experiences with
the dynamics of their DECNET with and without the use of this signal.

Vint