RFC 1016 (rfc1016) - Page 2 of 18

Something a host could do with source quench: The Source Quench Introduced Delay (SQuID)

RFC 1016        Source Quench Introduced Delay -- SQuID        July 1987


   zero.

   Imagine that when a source quench is received (or any other signal is
   received that the host should slow down its transmissions to the
   network), the value of D is increased.  As time goes by, the value of
   D is decreased.

The SQuID Algorithm

          on increase event:

               D <-- maximum (D + K, I)
                                        (where K = .020 second,
                                               I = .075 second)

          on decrease event:

               D <-- maximum (D - J, 0)
                                        (where J = .001 second)

   An increase event is receipt of one or more source quenches in a
   event period E, (where E is 2.000 seconds).

   A decrease event is when S time has passed since D was decreased and
   there is a datagram to send (where S is 1.000 seconds).

   A cache of D's is kept for the last M hosts communicated with.

   Note that when no datagrams are sent to a destination for some time
   the D for that destination is not decreased, but, if a destination is
   not used for a long time that D for that destination may fall out of
   the cache.

Possible Refinements

   Keep a separate outgoing queue of datagrams for each destination
   host, local subnet, or network.

   Keep the cache of D's per network or local subnet, instead of per
   host.

   "I" could be based upon the basic speed of the slowest intervening
   network (see Appendix A).

   "D" could be limited to never go below "I" if the above refinement
   were implemented.

   "S" could be based upon the round trip time.



Prue & Postel