Something a Host Could Do with Source Quench: The Source Quench Introduced Delay (SQuID)
RFC 1016

Document Type RFC - Unknown (July 1987; No errata)
Last updated 2013-03-02
Stream Legacy
Formats plain text pdf htmlized bibtex
Stream Legacy state (None)
Consensus Boilerplate Unknown
RFC Editor Note (None)
IESG IESG state RFC 1016 (Unknown)
Telechat date
Responsible AD (None)
Send notices to (None)
Network Working Group                                            W. Prue
Request for Comments:  1016                                    J. Postel
                                                                     ISI
                                                               July 1987

             Something a Host Could Do with Source Quench:

               The Source Quench Introduced Delay (SQuID)

Status of this Memo

   This memo is intended to explore the issue of what a host could do
   with a source quench.  The proposal is for each source host IP module
   to introduce some delay between datagrams sent to the same
   destination host.  This is an "crazy idea paper" and discussion is
   essential.  Distribution of this memo is unlimited.

Introduction

   A gateway may discard Internet datagrams if it does not have the
   buffer space needed to queue the datagrams for output to the next
   network on the route to the destination network.  If a gateway
   discards a datagram, it may send a source quench message to the
   Internet source host of the datagram.  A destination host may also
   send a source quench message if datagrams arrive too fast to be
   processed.  The source quench message is a request to the host to cut
   back the rate at which it is sending traffic to the Internet
   destination.  The gateway may send a source quench message for every
   message that it discards.  On receipt of a source quench message, the
   source host should cut back the rate at which it is sending traffic
   to the specified destination until it no longer receives source
   quench messages from the gateway.  The source host can then gradually
   increase the rate at which it sends traffic to the destination until
   it again receives source quench messages [1,2].

   The gateway or host may send the source quench message when it
   approaches its capacity limit rather than waiting until the capacity
   is exceeded.  This means that the data datagram which triggered the
   source quench message may be delivered.

The SQuID Concept

   Suppose the IP module at the datagram source has a queue of datagrams
   to send, and the IP module has a parameter "D".  D is the introduced
   delay between sending datagrams from the queue to the network.  That
   is, when the IP module discovers a datagram waiting to be sent to the
   network, it sends it to the network then waits time D before even
   looking at the datagram queue again.  Normally, the value of D is

Prue & Postel                                                   [Page 1]
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                                                   [Page 2]
RFC 1016        Source Quench Introduced Delay -- SQuID        July 1987

   "D" could be adjusted datagram by datagram based upon the length of
   the datagrams.  Wait longer after a long datagram.

   The delay algorithm could be implemented such that if a source
   doesn't send a datagram when it is next allowed (the introduced delay
   interval) or for N such intervals that the source gets a credit for
   one and only one free (no delay) datagram.

Implementation Ideas

   Since IP does not normally keep much state information about things,
   we want the default or idle IP to have no state about these D values.
   Since the default D value is zero, let us propose that the IP will
Show full document text