[lmap] draft-ksubram-lmap-router-buffer-sizes-00

Kamala Subramaniam <kasubra@microsoft.com> Mon, 10 November 2014 20:06 UTC

Return-Path: <kasubra@microsoft.com>
X-Original-To: lmap@ietfa.amsl.com
Delivered-To: lmap@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 561B61ACD6B for <lmap@ietfa.amsl.com>; Mon, 10 Nov 2014 12:06:41 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.002
X-Spam-Level:
X-Spam-Status: No, score=-0.002 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, HTML_MESSAGE=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iIjdl8bRD4DG for <lmap@ietfa.amsl.com>; Mon, 10 Nov 2014 12:06:36 -0800 (PST)
Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0797.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:797]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D04C11ACDB6 for <lmap@ietf.org>; Mon, 10 Nov 2014 12:06:27 -0800 (PST)
Received: from CY1PR0301MB0633.namprd03.prod.outlook.com (25.160.158.139) by CY1PR0301MB0635.namprd03.prod.outlook.com (25.160.158.141) with Microsoft SMTP Server (TLS) id 15.1.11.14; Mon, 10 Nov 2014 20:06:05 +0000
Received: from CY1PR0301MB0633.namprd03.prod.outlook.com ([25.160.158.139]) by CY1PR0301MB0633.namprd03.prod.outlook.com ([25.160.158.139]) with mapi id 15.01.0011.000; Mon, 10 Nov 2014 20:06:05 +0000
From: Kamala Subramaniam <kasubra@microsoft.com>
To: "lmap@ietf.org" <lmap@ietf.org>
Thread-Topic: draft-ksubram-lmap-router-buffer-sizes-00
Thread-Index: Ac/9IIXhaghu935KTUSEb734GjxF2Q==
Date: Mon, 10 Nov 2014 20:06:05 +0000
Message-ID: <f471f76bae06499a8cac9bc3b9c66c16@CY1PR0301MB0633.namprd03.prod.outlook.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [31.133.179.85]
x-microsoft-antispam: BCL:0;PCL:0;RULEID:;SRVR:CY1PR0301MB0635;
x-exchange-antispam-report-test: UriScan:;
x-exchange-antispam-report-cfa: BCL:0;PCL:0;RULEID:;SRVR:CY1PR0301MB0635;
x-forefront-prvs: 039178EF4A
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(189002)(199003)(46034005)(4396001)(19625215002)(99286002)(120916001)(76576001)(107886001)(46102003)(99396003)(101416001)(15975445006)(19300405004)(2501002)(97736003)(108616004)(107046002)(229853001)(95666004)(2351001)(230783001)(106356001)(105586002)(2656002)(74316001)(40100003)(21056001)(15202345003)(33646002)(64706001)(50986999)(110136001)(20776003)(19580395003)(54356999)(16236675004)(87936001)(86612001)(122556002)(92566001)(77156002)(62966003)(86362001)(77096003)(450100001)(66066001)(31966008)(24736002); DIR:OUT; SFP:1102; SCL:1; SRVR:CY1PR0301MB0635; H:CY1PR0301MB0633.namprd03.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; MX:1; A:1; LANG:en;
Content-Type: multipart/alternative; boundary="_000_f471f76bae06499a8cac9bc3b9c66c16CY1PR0301MB0633namprd03_"
MIME-Version: 1.0
X-OriginatorOrg: microsoft.onmicrosoft.com
Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/wwW_I4ix7f_JewSZqmTz01krtsQ
Subject: [lmap] draft-ksubram-lmap-router-buffer-sizes-00
X-BeenThere: lmap@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Large Scale Measurement of Access network Performance <lmap.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/lmap>, <mailto:lmap-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/lmap/>
List-Post: <mailto:lmap@ietf.org>
List-Help: <mailto:lmap-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/lmap>, <mailto:lmap-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 10 Nov 2014 20:06:41 -0000

Dear LMAP WG,

We have submitted a draft "Router Buffer Sizes in the WAN". It will be presented this Thursday. I wanted to take this opportunity to introduce this draft, and get some feedback. This draft has received some input from the AQM WG.

The lmap-use-cases draft is what initiated the request to be presented in the LMAP WG.  Let me get more in to the details by elaborating the issue with each of the 4 subsections in this ISP use case.

Before that, maybe listing the goals would give a better idea:

*        Drive down the unit cost in $/GB by building efficient but cheaper networks. Do our networks really need the buffers we deal with today at high costs?

*        Maximize throughput in the backbone by always keeping the links busy so that the router buffers never underflow and the router does not lose throughput.

*        To take into consideration variables such as {short Vs long flows, packet sizes, queue depth/model, traffic classes, etc.} as factors while reducing the whistles, bells, and knobs to keep it simple to configure as well as manage.
Now, for the subsections:

*        Identifying, isolating and fixing problems: we observe that there are numerous issues at different layers that have an effect (directly or indirectly) on the sizing of router buffers. Could this be solved by high layer optimizations (ECN, tweaking TCP flows),  or something like just a different queuing model. Studying the nature of the traffic that exists in an ISP world today is an important way to determine this. Where really is this problem? Is it the way we design our networks for example by not taking into consideration how scavenger class really affects us?

*        Design and planning: One the problem has been identified it becomes easier to design and plan the networks. Perhaps all we need are small size buffers driving down the cost.

*        Understanding the quality experienced by customers: again a huge chunk of the study would have packet discards (WAN facing/ outgoing egress interface perhaps?). Do the new methods involved in this study work better for QoS?

*        Understanding the impact and operation of new devices and technology: let's say that the conclusion of this study is that we do not need large size buffers (we are talking 125MB per port), then can we convince the vendors (switch/router/chip) to go down that path.
There have been many studies which provide theories to what the size should be. However, most of these are theoretical in nature and do not take into account any empirical data. While we continue to mine the big data available to us to further study this, we'd also like to start a draft which would in the minimum entail a problem statement, get an idea of the amount of interest, and hopefully lead to some collaboration.

Regards,
Kamala