Re: Comment on draft-asechoud-rtgwg-qos-model-03

"Aseem Choudhary (asechoud)" <asechoud@cisco.com> Fri, 06 April 2018 08:53 UTC

Return-Path: <asechoud@cisco.com>
X-Original-To: rtgwg@ietfa.amsl.com
Delivered-To: rtgwg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6874912D7EC for <rtgwg@ietfa.amsl.com>; Fri, 6 Apr 2018 01:53:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.511
X-Spam-Level:
X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com
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 dGoiXNRTSPmm for <rtgwg@ietfa.amsl.com>; Fri, 6 Apr 2018 01:53:01 -0700 (PDT)
Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E65C81200F1 for <rtgwg@ietf.org>; Fri, 6 Apr 2018 01:53:00 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=12596; q=dns/txt; s=iport; t=1523004780; x=1524214380; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=Dw3bXED/QM5tqp55Cq8K2Z02CXfA7cx4dS/xgfb2ZEk=; b=akq25EnM2lGXsrh8Eg6oGT8HLb6FmSsQq9Fj8ob26N3eP6Ck6yG+OYDP aXfN14pH4Jo+JlCTUd9kqPt5J9NPDibtM805GRwDFsEihegDqqsBdtexA NeI7NFXLhJwkaixReN7zSa4WqcUz+6vKEtmrtKXbIin+BV+VDnhF/ZxPi U=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0DzAACKNMda/5RdJa1dGQEBAQEBAQEBAQEBAQcBAQEBAYJNdWFvKAqLVY0KgXSBD410hGSBeguFAwKCMiE0GAECAQEBAQEBAmwdC4UiAQEBAQMtTBACAQgRAwECKAcyFAkIAQEEDgUbhA5kq2KEV4N2giWHa4FUP4EMgwSESDUShTQCjCqEIoZ3CAKOMYxAj18CERMBgSQBHDiBUnAVgn2QTm+LH4EugRcBAQ
X-IronPort-AV: E=Sophos;i="5.48,414,1517875200"; d="scan'208,217";a="375632800"
Received: from rcdn-core-12.cisco.com ([173.37.93.148]) by rcdn-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 06 Apr 2018 08:52:59 +0000
Received: from XCH-RCD-002.cisco.com (xch-rcd-002.cisco.com [173.37.102.12]) by rcdn-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id w368qxMr021065 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 6 Apr 2018 08:52:59 GMT
Received: from xch-rcd-004.cisco.com (173.37.102.14) by XCH-RCD-002.cisco.com (173.37.102.12) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Fri, 6 Apr 2018 03:52:59 -0500
Received: from xch-rcd-004.cisco.com ([173.37.102.14]) by XCH-RCD-004.cisco.com ([173.37.102.14]) with mapi id 15.00.1320.000; Fri, 6 Apr 2018 03:52:59 -0500
From: "Aseem Choudhary (asechoud)" <asechoud@cisco.com>
To: "Ruediger.Geib@telekom.de" <Ruediger.Geib@telekom.de>
CC: "rtgwg@ietf.org" <rtgwg@ietf.org>
Subject: Re: Comment on draft-asechoud-rtgwg-qos-model-03
Thread-Topic: Comment on draft-asechoud-rtgwg-qos-model-03
Thread-Index: AdPANyL7vVQZPo4ESnS+mtGN2HW0QQNPL+WA
Date: Fri, 06 Apr 2018 08:52:59 +0000
Message-ID: <D6EC8203.88615%asechoud@cisco.com>
References: <FRXPR01MB0037D39619737D34396951CF9CAB0@FRXPR01MB0037.DEUPRD01.PROD.OUTLOOK.DE>
In-Reply-To: <FRXPR01MB0037D39619737D34396951CF9CAB0@FRXPR01MB0037.DEUPRD01.PROD.OUTLOOK.DE>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/14.7.1.161129
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.24.123.53]
Content-Type: multipart/alternative; boundary="_000_D6EC820388615asechoudciscocom_"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/rtgwg/-xwhLnvx1C3PCxzCgSZhQBAxaZQ>
X-BeenThere: rtgwg@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Routing Area Working Group <rtgwg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtgwg>, <mailto:rtgwg-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/rtgwg/>
List-Post: <mailto:rtgwg@ietf.org>
List-Help: <mailto:rtgwg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtgwg>, <mailto:rtgwg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 06 Apr 2018 08:53:03 -0000

Hi Ruediger,

Thanks for your comments.

We are looking into adding support for buffer/burst in ms and percentages for rate.

Also, I have forwarded the draft to TSVWG and will follow up for any comment/suggestion.

Regards,
Aseem

From: "Ruediger.Geib@telekom.de<mailto:Ruediger.Geib@telekom.de>" <Ruediger.Geib@telekom.de<mailto:Ruediger.Geib@telekom.de>>
Date: Tuesday, March 20, 2018 at 4:12 AM
To: asechoud <asechoud@cisco.com<mailto:asechoud@cisco.com>>
Cc: "rtgwg@ietf.org<mailto:rtgwg@ietf.org>" <rtgwg@ietf.org<mailto:rtgwg@ietf.org>>
Subject: Comment on draft-asechoud-rtgwg-qos-model-03

Aseem,

the current draft provides limited support for standard parameters supporting scheduling and WRED. The solution suggested by the authors is to allow for flexible vendor specific extensions.

Vendor advice for many QoS configuration tasks  often results in application of following  generic formula:

Assign_buffer_in_[ms]@bitrate to configure some buffer in [byte].    Percentages related to a rate my replace an absolute rate.

This holds for the following configurations:

  *   Policer / Burst
  *   Shaper / Burst
  *   Guaranteed Scheduler Rate / Queue depth (and WRED threholds)

Further, an option might be useful to allow to configure a bitrate deviating from the guaranteed scheduler rate for dimensioning scheduler queue depth. This makes sense if overbooking of a class is allowed.

My proposal is to support the following input commands per shaper/policer/class.... in a generic way:

  *   a buffer/burst in [ms]
  *   a rate (either as a rate or as a percentage referring to a rate)

And from there to calculate buffers in Byte. Providers preferring to configure in byte should of course be able to continue doing so, I don't suggest to prevent that.

The advantage is as I mentioned above that this is a generic way of configuring a scheduler (queue depth and WRED)/policer/shaper. That may allow providers to specify a standard input determining at least major parts of the vendor specific parameters.

I'd also like to suggest to present this work at TSVWG, as this may result in additional QoS configuration related feedback.

Regards,

Ruediger