[Docs] [txt|pdf] [Tracker] [WG] [Email] [Nits]

Versions: 00 draft-ksubram-lmap-router-buffer-sizes

Internet Engineering Task Force                      K. Subramaniam, Ed.
Internet-Draft                                                  D. Loher
Intended status: Informational                                 Microsoft
Expires: April 30, 2015                                 October 27, 2014


                     Router Buffer Sizes In The WAN
             draft-ietf-lmap-router-buffer-sizes-ksubram-00

Abstract

   This draft identifies the set of data that needs to be collected, and
   analyzed to quantify router buffer sizes used in routers in the Wide
   Area Network (WAN).  The scope of this draft is limited to WAN links
   that have link latencies of 40 to 150 milliseconds.

   Reducing router buffer sizes has many advantages, the most important
   being cost.  However, there is not much data available today to
   effectively calculate this.  This draft details use cases for the
   study, and lists data that needs to be taken into consideration to be
   able to quantify the size of router buffers.  The details of the
   individual measurement metrics are beyond the scope of this document.
   Neither does the draft identify methods to gather the data.  What it
   identifies is a need to be able to collect, and report this empirical
   data in a readable fashion thus providing the ability to study and
   compare data in a more standardized method.

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on April 30, 2015.








Subramaniam & Loher      Expires April 30, 2015                 [Page 1]


Internet-Draft       Router Buffer Sizes in the WAN         October 2014


Copyright Notice

   Copyright (c) 2014 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

   This document may not be modified, and derivative works of it may not
   be created, except to format it for publication as an RFC or to
   translate it into languages other than English.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   4
   3.  Use Case  . . . . . . . . . . . . . . . . . . . . . . . . . .   4
     3.1.  Discards with small buffer sizes  . . . . . . . . . . . .   4
     3.2.  Discards with large buffer sizes  . . . . . . . . . . . .   4
   4.  List of required data for study of router buffer sizes  . . .   4
     4.1.  Number of concurrent flows, N . . . . . . . . . . . . . .   5
     4.2.  Length of a flow, L . . . . . . . . . . . . . . . . . . .   6
     4.3.  Packet Discards, D  . . . . . . . . . . . . . . . . . . .   6
     4.4.  Reason for Packet Discards, R . . . . . . . . . . . . . .   6
     4.5.  Resolution of time interval, T  . . . . . . . . . . . . .   6
     4.6.  5 Tuple Flow Identity, I  . . . . . . . . . . . . . . . .   7
   5.  Conclusion  . . . . . . . . . . . . . . . . . . . . . . . . .   7
   6.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .   7
   7.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   7
   8.  Security Considerations . . . . . . . . . . . . . . . . . . .   7
   9.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   7
     9.1.  Normative References  . . . . . . . . . . . . . . . . . .   8
     9.2.  Informative References  . . . . . . . . . . . . . . . . .   8
   Appendix A.  Additional Stuff . . . . . . . . . . . . . . . . . .   9
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   9

1.  Introduction

   "How much buffering do core links need?" is a question that has been
   under study for a while.  The question boils down to quantify buffer




Subramaniam & Loher      Expires April 30, 2015                 [Page 2]


Internet-Draft       Router Buffer Sizes in the WAN         October 2014


   sizes and yet achieve 100% utilization on links with maximum
   throughput at a feasible cost.

   Buffer design could substantially increase costs.  While over-
   buffering seems intuitive it can complicate the design of high speed
   routers, lead to higher power consumption, more board space, and
   lower density.  It can actually increase end-to-end delay in the
   presence of congestion.  This can make congestion more persistent.
   Additionally, there is always a tradeoff between buffer sizes and the
   capacity of a router.

   On the other hand, under-buffering while doing away from the above
   cons of over-buffering could lead us away from our primary goal of
   100 percent link utilization.  This could happen in a scenario using
   a simple Additive Increase Multiplicative Decrease (AIMD) for TCP
   flows when the sender has packets to send but the window size
   advertised is less and as a result the receiver consumes far less
   that it could.

   The rule of thumb for router buffers has been defined as [Villamizar]
   : B = 2RTT*C.  Where B, was the buffer size, RTT the Round Trip Time,
   and C the capacity of the bottleneck link.  [RFC3429]  also talks
   about the buffer size being at least one TCP window size.

   However later studies [Appenzeller], show that the rule of thumb
   works either for a single flow or a perfectly synchronized large
   number of flows.  Further they postulate that the buffer size is
   actually (2RTT * C)/sqrt(n), where n is the number of flows.  This
   indicates a significant reduction in the buffer chip promoting lower
   costs.

   As seen, there have been proponents for large buffers and small.
   However, most of these studies are based on theoretical models and
   simulations.  Today, there is no model or protocol to mine big data
   from a providers network to be able to answer this question
   efficiently.  The nature of WAN traffic can be uncertain and varying.
   Furthermore the traffic could vastly vary between individual ISPs.
   This document implored the need for a model of mining empirical big
   data in a providers network to be able to build a network that drives
   down the $/GB and at the same time maximizing link utilization.

   This document outlines use cases for the study of router buffer sizes
   in the WAN and identifies the data that needs to be collected and
   analyzed.  It could be further extended to the edge and datacenters,
   but it is outside the scope of this draft.






Subramaniam & Loher      Expires April 30, 2015                 [Page 3]


Internet-Draft       Router Buffer Sizes in the WAN         October 2014


2.  Terminology

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in RFC 2119 [RFC2119].

3.  Use Case

   From an operator's perspective it is imperative to monitor discards
   and link utilization over WAN links to be able to study the router
   buffer sizes.  But these alone will be unable to provide an operator
   with enough information as to why the discards happened.  The two use
   cases outlined here argue that more data needs to be collected,
   reported, and analyzed.

3.1.  Discards with small buffer sizes

   Trans-pacific and trans-atlantic links of latencies in the range of
   150 ms and 90 ms respectively, with low link utilization of 30
   percent, and small buffers have seen dropped packets.  The most
   intuitive method has been to increase the buffer sizes for these
   links on noticing packet discards.  While this might alleviate the
   issue temporarily, unless the right problem has been identified this
   could readily lead to buffer bloat which has many issues on its own.

3.2.  Discards with large buffer sizes

   Operators have also observed dropped packets on WAN links within
   North America with as large buffers as 125 MB per port with link
   utilizations of 60%. If this happens even if the router has not been
   specifically configured to drop certain type of packets, or there are
   no routing misconfigurations, then clearly the issue here is not the
   size of the router buffer.

4.  List of required data for study of router buffer sizes

   This section talks about the absolute minimum requirements of the
   type of data that needs to be collected to be able to effectively
   quantify router buffer size.












Subramaniam & Loher      Expires April 30, 2015                 [Page 4]


Internet-Draft       Router Buffer Sizes in the WAN         October 2014


   +---+-------------------------+-------------------------------------+
   |   |           Data          |               Details               |
   +---+-------------------------+-------------------------------------+
   | 1 |   Number of concurrent  |        For aggregate traffic        |
   |   |         flows, N        |                                     |
   | 2 |  Length of the flow, L  |  [Flow start time - flow end time]  |
   | 3 |    Packet Discards, P   |            Per Interface            |
   | 4 |    Reason for Packet    |   Buffer overflow, configuration,   |
   |   |       Discards, R       |                 etc.                |
   | 5 |    Resolution of Time   |  [Flow start time - flow end time]  |
   |   |       Interval, T       |                                     |
   | 6 |  5 tuple flow identity, |   Src IP, Dest IP, Src port, Dest   |
   |   |            I            |           Port, Protocol.           |
   +---+-------------------------+-------------------------------------+

          Table 1: List of required data for Router Buffer Sizes

   A service provider needs to take into consideration several
   attributes to determine the right buffer size for its WAN routers.
   This section enlists the details as to why the five above have been
   identified as the minimum essential data needed to aid the study of
   router buffer sizes.

4.1.  Number of concurrent flows, N

   Studies [Feldmann]  and [Stevens] show that 95% of flows in the
   internet today are attributed to TCP [Postel] flows.  The nature of
   these flows can vary significantly not only with various time
   periods, but also between providers.  Flows that spend most of their
   time in slow-start require significantly less buffering than flows
   that live mostly in congestion avoidance.  Due to this it is
   important to identify the type of concurrent flows that can live on a
   WAN link.

   Short (non-persistent) flows are those that live for less than one
   RTT, and large (persistent) flows are those whose lifetime is larger
   that one RTT with congestion overhead.  Internet measurements [Avra]
   show that while a smaller number of large flows contribute to maximum
   packet transfer, short flows dominate most TCP sessions and large
   flows are known to have a larger effect on buffer sizes.  These
   combination flows could in turn have an effect on Round Trip Time
   (RTT), loss probability and flow lengths.  The ability to detect
   large flows is necessary because while the flows can be constant in
   steady state, the aggregate traffic can keep changing due to various
   arrival and departure rates.  There needs to be a way for the number
   of concurrent flows to be collected and analyzed with the granularity
   of the lifetime of short flows, as low as one millisecond.




Subramaniam & Loher      Expires April 30, 2015                 [Page 5]


Internet-Draft       Router Buffer Sizes in the WAN         October 2014


4.2.  Length of a flow, L

   Length of a flow can be defined as its duration: [flow stop time -
   flow start time], or the number of packets/bytes sent in this time
   duration.  Identifying the length of flow in a provider's network
   will give information of the mix of short and large flows that are
   present in the WAN.  This will lead to modeling implications in TCP
   flow control.

4.3.  Packet Discards, D

   Number of packet discards per interface is probably the most
   important metric.  Of this the number of outward (WAN) facing
   interface discards would be more intuitive to the study of buffer
   sizes.  Interface discards can be referred to in [RFC2893]

4.4.  Reason for Packet Discards, R

   There can be several reasons for packet discards especially when it
   is observed on less utilized links.  Some of them could be due to
   routing misconfigurations, or designed to drop certain packets due to
   configurations.  Clearly stating a reason as insufficient buffer will
   help narrow down the data required.  This is especially true in the
   case of smart buffer allocations when some ports run out of buffers
   but not others.  We could observe that a port has been allocated
   only, say, 30 percent of the available total buffer space but is
   experiencing the highest utilization and as a result of that is
   seeing packet drops pointing to the fact that dynamic buffers' smart
   allocations scheme is not adaptive and predictive to the nature of
   the WAN traffic.

4.5.  Resolution of time interval, T

   The time interval should be granular such that it captures not only
   the number of concurrent flows in steady state but also the aggregate
   traffic over the lifetime of a short flow.  It should also be able to
   correlate the discards per interface to the number of concurrent
   flows.

   Today via IPFIX we can calculate the number of concurrent flows.  Via
   Sflow counters or flows, we can calculate the discards.  Using
   counters requires upto two times the granularity set for any changes
   to be visible due to Nyquist rate.  Reducing the counter export
   interval would increase the responsiveness, but at the cost of
   increased overhead and reduced scalability.  On the other hand,
   packet sampling automatically allocates monitoring resources to busy
   links, providing a highly scaleable way to quickly detect traffic




Subramaniam & Loher      Expires April 30, 2015                 [Page 6]


Internet-Draft       Router Buffer Sizes in the WAN         October 2014


   flows wherever they occur in the network.  Responsiveness is
   important for a more stable control.

4.6.  5 Tuple Flow Identity, I

   5 tuple flows have a source IP, destination IP, source port,
   destination port, and protocol to identify endpoints for
   unidirectional flows.  Having this functionality gives the network
   operator a way to identify the offending flows, legitimate elephant
   flows, and high priority flows which may happen at certain periods
   during the day.  Being able to separate traffic using the 5 tuple,
   further increases the strength of the sample set of empirical data
   available for the study of router buffer sizes.

5.  Conclusion

   We see that there are numerous issues at different layers that have
   an effect (directly or indirectly) on the sizing of router buffers.
   We also notice that there is no study that takes empirical data into
   consideration.  Ideally, what would be required is an all knowing
   oracle that sees the traffic flow on an end-to-end network across all
   layers.  Due to a lack of the resource, the first step to the study
   of router buffer sizes is to effectively mine the big data repository
   of a provider for the data identified in this draft.

6.  Acknowledgements

7.  IANA Considerations

   This memo includes no request to IANA.

   All drafts are required to have an IANA considerations section (see
   the update of RFC 2434 [I-D.narten-iana-considerations-rfc2434bis]
   for a guide).  If the draft does not require IANA to do anything, the
   section contains an explicit statement that this is the case (as
   above).  If there are no requirements for IANA, the section will be
   removed during conversion into an RFC by the RFC Editor.

8.  Security Considerations

   This document does not introduce new security issues.

9.  References








Subramaniam & Loher      Expires April 30, 2015                 [Page 7]


Internet-Draft       Router Buffer Sizes in the WAN         October 2014


9.1.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

9.2.  Informative References

   [Appenzeller]
              G. Appenzeller, I. Klesassy, and N. McKeown, "Some
              Internet Architectural Guidelines and Philosophy", 2004,
              <SIGCOMM '04 Proceedings of the 2004 conference on
              Applications, technologies, architectures, and protocols
              for computer communications>.

   [Avra]     Konstantin Avrachenkov, INRIA Sophia Antipolis,
              "Differentiation Between Short and Long TCP Flows:
              Predictability of the Response Time", 2004, <IEEE
              INFOCOMM>.

   [Feldmann]
              A. Feldmann, J. Rexford, and R. Caceres, "Efficient
              policies for carrying Web traffic over flow-switched
              networks", Dec. 1998, <IEEE/ACM Trans. Networking, vol. 6,
              pp. 673-685>.

   [I-D.narten-iana-considerations-rfc2434bis]
              Narten, T. and H. Alvestrand, "Guidelines for Writing an
              IANA Considerations Section in RFCs", draft-narten-iana-
              considerations-rfc2434bis-09 (work in progress), March
              2008.

   [Postel]   J. Postel, "Transmission Control Protocol", Sep. 1981,
              <RFC 793>.

   [RFC2893]  K. McCloghrie, F. Kastenholz, "The Interfaces Group MIB",
              Jun. 2000, <RFC 2893>.

   [RFC3429]  R. Bush and D. Meyer, "Some Internet Architectural
              Guidelines and Philosophy", Dec. 2002, <RFC 3429>.

   [Stevens]  W. R. Stevens, "Transmission Control Protocol", 1994,
              <TCP/IP Illustrated. Reading, MA: Addison-Wesley, vol. 1>.

   [Villamizar]
              C. Villamizar and C. Song, "High performance tcp in
              ansnet", 1994, <ACM Computer Communications Review,
              24(5):45-60>.




Subramaniam & Loher      Expires April 30, 2015                 [Page 8]


Internet-Draft       Router Buffer Sizes in the WAN         October 2014


Appendix A.  Additional Stuff

   This becomes an Appendix.

Authors' Addresses

   Kamala Subramaniam (editor)
   Microsoft
   Mountain View, CA  94043
   US

   Phone: +1 919 345 8778
   Email: kasubra@microsoft.com


   Darren Loher
   Microsoft
   Redmond, WA  98052
   US

   Email: daloher@microsoft.com






























Subramaniam & Loher      Expires April 30, 2015                 [Page 9]


Html markup produced by rfcmarkup 1.124, available from https://tools.ietf.org/tools/rfcmarkup/