rfc1016.txt

来自「RFC 的详细文档！」· 文本 代码 · 共 1,011 行 · 第 1/4 页

   decrease "D" by one "J" unit if "S" time, or more, has elapsed.  The
   other timer is not so easily eliminated.  If the IP implementation is
   periodically awakened to check for work to do, it could check the
   time stamps of the head of the queues to see if any datagrams have
   waited long enough.  This would mean we would necessarily wait too
   long before sending, but it may not be too large of a variance from
   our desired rates.  The additional delay would help congestion and
   reduce our chances of SQ.  Another option is setting a real timer
   which is say 25-50% too large and hope that our periodic work in IP
   will allow us to notice a datagram is delayed enough, and send it.
   Upon sending the datagram we would cancel the timer, avoiding the
   timer interrupt and environment swap.  In other implementations the
   communications interface or the link level protocol may be able to
   provide the timing needed without interrupts to the main processor.

   Background tasks like some file transfers could query IP for the
   latest delay characteristics for a given destination to determine if
   it is appropriate to consume network resources now or if it would be
   better to wait until later.

   We should consider what would happen if IP, using the SQuID
   algorithm, and TCP both introduced delay between the datagrams.  If
   TCPs delay was greater than IP's, then when IP got the datagrams it



Prue & Postel                                                  [Page 14]

RFC 1016        Source Quench Introduced Delay -- SQuID        July 1987


   would forward them immediately as described in the algorithm above.
   This is because when the IP send queue is empty and it has been at
   least as long as IP wants the higher level protocol, TCP, gets one
   free (no delay) send.  Note also that IP will be decreasing the
   amount of delay it wants introduced because of the successful
   transmissions without SQs.  This would affect other protocols who
   might also send to the same destination.  If TCP sends too quickly
   then IP will protect the network from its indiscretion as described
   in the basic algorithm however TCPs round trip time estimates will be
   much closer to reality.  A lost datagram will thus be detected more
   quickly.  If TCP also uses windowing to limit its sending rate, it
   might, because of its success with a smaller window, increase the
   window size increasing TCPs efficiency.

   As this algorithm is implemented everywhere, the SQ Keep (SQK) and SQ
   Low Water (SQLW) queue level percentages should be dropped to reduce
   queue sizes and thus the through net delay.  The percentage we lower
   SQK and SQLW to should be adjusted based upon the percentage of time
   the queue is empty.  The more the queue is empty the more likely it
   is that the node is discouraging data flow too much.  The more time
   the queue is not empty but not too full, the more likely it is the
   node is not excessively discouraging data flow.  How uniform the
   queue size is, is a measure of how well the network citizens are
   behaved.

   As the congestion is pushed to the sources, gateways which are
   bottlenecks can more easily detect someone not playing by the rules
   (sending datagrams in bursts) and deal with the offender.























Prue & Postel                                                  [Page 15]

RFC 1016        Source Quench Introduced Delay -- SQuID        July 1987


Appendix A -- Determination of the Value for the Parameter "I"

   To get to the correct value for the delay needed quickly, when an
   event occurred and the currently used delay was minimal, the
   transmission time for an average sized datagram across the slowest
   communications link was used for a first value.  How a real IP node
   is to guess this value is discussed below.  In our example the
   transition between node 2 and node 3 is the bottleneck. Using the 56
   kb/s line, a 512 byte datagram would take 73 msec with no queuing or
   processing time is considered.  This value is defined to be the
   minimum inter-datagram arrival time (MIAT).  Assuming a perfect
   network, ignoring factors other than transmission speed, this is the
   minimum time one could expect between receipt of datagrams at the
   destination, because of the slowed data rate through the bottleneck.
   This won't hold true if the datagrams do not follow the same path.

   The MIAT, minimum inter-datagram arrival time, may be guessed at by
   comparing the arrival timestamps of consecutive datagrams from a
   source of data.  Each value to be considered needs to be adjusted up
   or down based upon the size between the second datagram received and
   the typical datagram size.  More simply stated, a datagram which is
   half the size of the average datagram can be transmitted across a
   line in half the time.  Therefore, double its IAT before considering
   it for an MIAT.  If the timestamp of a datagrams is taken based upon
   an event caused by the start of the datagram arriving, not the
   completion of the datagram arriving, then the first datagram's size
   is the limiting length and should be used to adjust its IAT.  In
   order to keep the algorithm simple, arrival times for short datagram
   could be ignored as could IATs which were orders of magnitude too
   large (see below).

   Once a minimal value is found based upon looking for small values
   over a minute or more, the value might be time averaged with a value
   kept like TCP's SRTT in order to reduce the effects of a false MIAT.
   We could assume the limiting facility would be a 9.6 kb/s line, a
   56-64 kb/s line, or a 1.5 Mb/s line.  These facilities would provide
   a MIAT of 427 msec, 73-64 msec, or 3 msec respectively, for a
   datagram 512 bytes long.  These are almost orders of magnitude in
   differences.  If the MIAT a node measures is not in this range but
   close, the value it is closest to may be used for its MIAT from that
   source.

   One of the good things about this measurement is that it is an
   entirely passive measurement.  No additional traffic is needed to
   measure it.  If a source is not sending data continuously then the
   longer measured values won't be validated as minimal values.  The
   assumption is that at least sometimes the source will send multiple
   datagrams at a time.



Prue & Postel                                                  [Page 16]

RFC 1016        Source Quench Introduced Delay -- SQuID        July 1987


   The MIAT measurement is totally unaffected by satellite delay
   characteristics of any intervening facilities.  The chance of getting
   a valid minimal reading is affected by the number of nodes traversed,
   but the value measured if it is valid will not be affected by the
   number of nodes traversed.  Stated another way, when a pair of
   datagrams traverse from one node to the next the datagrams are
   susceptible to being separated by a datagram from another source.
   Both of these factors affect SRTT. The value obtained requires no
   topological knowledge of the route.

   A potential problem with the measurement is, it will not be the
   proper value for some forms of alternate routes.  If a T1 link is the
   bottleneck route some times and other times it is a 56 kb/s link our
   first guess for inter-datagram delay would be too small for the 56
   kb/s line route.  Another problem is that if one datagram goes via
   one route and the next goes via another, their inter-datagram arrival
   difference could lead to a small false measurement.  If intervening
   networks fragment datagrams then the measured IAT between segments
   could be misleading.  A solution to this problem is to ignore
   fragmented datagram IATs.

   This number represents the minimum inter-datagram delay the sending
   IP should use to send to us, the measuring site, for the given
   datagram size.  If we assume that the return path will be through the
   same facilities or the same type, then as described above this value
   can be the first guess for inter-datagram introduced delay, "D" (in
   the algorithm).  It represents the "I" parameter.

   These MIATs may be cached on a host, subnet, or network basis.  The
   last "n" hosts MIATs could be kept.  For infrequent destinations an
   entry per destination network would be applicable to many
   destinations.  If the local net is in fact a subnet, then the other
   local subnet MIATs could be kept.

   If a good algorithm is found for MIAT, comparing it to the average
   IAT (during data transfer) would give a good measure of the amount of
   network traffic load.  Since IP has no idea when the source of data
   is sending as fast as possible, to get a valid average, upper layer
   protocols would have to figure this out for themselves.  IP could
   however provide an interface to get the current MIAT for a given
   destination.










Prue & Postel                                                  [Page 17]

RFC 1016        Source Quench Introduced Delay -- SQuID        July 1987


References

   [1]  Postel, Jon, "Internet Protocol - DARPA Internet Program
   Protocol Specification", RFC 791, ISI, September 1981.

   [2]  Postel, Jon, "Internet Control Message Protocol - DARPA Internet
   Program Protocol Specification", RFC 792, ISI, September 1981.

   [3]  Karels, M., "Re: Source Quench", electronic mail message to J.
   Postel and INENG-INTEREST, Tue, 24 Feb 87.

   [4] Nagle, John B., "On Packet Switches With Infinite Storage", RFC
   970, FACC Palo Alto, December 1985.

   [5] Jacobson, Van, "Re: interpacket arrival variance and mean",
   electronic mail message to TCP-IP,  Mon, 15 Jun 87 06:08:01 PDT

   [6] Jacobson, Van, "Re: Appropriate measures of gateway performance"
   electronic mail message to J. Noel Chiappa  and INENG-INTEREST, Sun,
   22 Mar 87 15:04:44 PST.

   [7] Nagle, John B., "Source quench, and congestion generally",
   electronic mail message to B. Braden and INENG-INTEREST, Thu, 5 Mar
   87 11:08:49 PST.

   [8] Nagle, John B., "Congestion Control in IP/TCP Internetworks", RFC
   896, FACC Palo Alto, 6 January 1984.
























Prue & Postel                                                  [Page 18]