Re: [tsvwg] RFC 4594 bis

<Ruediger.Geib@telekom.de> Fri, 07 August 2015 06:53 UTC

Return-Path: <Ruediger.Geib@telekom.de>
X-Original-To: tsvwg@ietfa.amsl.com
Delivered-To: tsvwg@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 589F11B3761 for <tsvwg@ietfa.amsl.com>; Thu, 6 Aug 2015 23:53:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.86
X-Spam-Level:
X-Spam-Status: No, score=-3.86 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] 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 aq9uqk4vwuGv for <tsvwg@ietfa.amsl.com>; Thu, 6 Aug 2015 23:53:21 -0700 (PDT)
Received: from tcmail43.telekom.de (tcmail43.telekom.de [80.149.113.173]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1C8FC1B3760 for <tsvwg@ietf.org>; Thu, 6 Aug 2015 23:53:19 -0700 (PDT)
Received: from q4de8psa169.blf.telekom.de ([10.151.13.200]) by tcmail41.telekom.de with ESMTP; 07 Aug 2015 08:53:15 +0200
X-IronPort-AV: E=Sophos;i="5.15,628,1432591200"; d="scan'208";a="886937918"
Received: from he113443.emea1.cds.t-internal.com ([10.134.93.103]) by q4de8psazkj.blf.telekom.de with ESMTP/TLS/AES128-SHA; 07 Aug 2015 08:52:15 +0200
Received: from HE110884.EMEA1.CDS.T-INTERNAL.COM ([10.134.92.128]) by HE113443.emea1.cds.t-internal.com ([::1]) with mapi; Fri, 7 Aug 2015 08:52:14 +0200
From: Ruediger.Geib@telekom.de
To: fred@cisco.com
Date: Fri, 07 Aug 2015 08:52:12 +0200
Thread-Topic: RFC 4594 bis
Thread-Index: AQHQ0F0PflTI/DEutk2MQ5RqJzYAIp4AGHfQ
Message-ID: <C44A73D17F5F0349BD75617B4D89627801EDB8C9F726@HE110884.EMEA1.CDS.T-INTERNAL.COM>
References: <31222528.108407.1438875148989.JavaMail.totemomail@he111460>
In-Reply-To: <31222528.108407.1438875148989.JavaMail.totemomail@he111460>
Accept-Language: en-US, de-DE
Content-Language: de-DE
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US, de-DE
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: <http://mailarchive.ietf.org/arch/msg/tsvwg/olQ9zZKwNdOxxQWArilfVYHMpQQ>
Cc: tsvwg@ietf.org
Subject: Re: [tsvwg] RFC 4594 bis
X-BeenThere: tsvwg@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Transport Area Working Group <tsvwg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tsvwg>, <mailto:tsvwg-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tsvwg/>
List-Post: <mailto:tsvwg@ietf.org>
List-Help: <mailto:tsvwg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tsvwg>, <mailto:tsvwg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 07 Aug 2015 06:53:23 -0000

Hi Fred,

I support your proposal to revise RFC 4594. Putting it on standards track - from my point of view requires consensus from network operators on the result. That may become a challenge, but let's try.

Regards,

Ruediger


-----Ursprüngliche Nachricht-----
Von: tsvwg [mailto:tsvwg-bounces@ietf.org] Im Auftrag von Fred Baker (fred)
Gesendet: Donnerstag, 6. August 2015 17:32
An: tsvwg@ietf.org
Betreff: ***CAUTION_Invalid_Signature*** [tsvwg] RFC 4594 bis

At IETF 93, there was ad hoc discussion of revising RFC 4594 and taking it to Proposed Standard. At minimum, such a project would include incorporating RFC 5865 and editing out statements that, in retrospect, may be ill-advised. Personally, I might want to collapse some of the video services into a single service. Most important, to me, would be incorporating operational experience. One of the key triggers for me to think about this has been statements made in draft-szigeti-tsvwg-ieee-802-11e that I wasn't sure were a good idea, and which Tim pointed out came directly from RFC 4594. Oops...

It will be a big job, I think.

Before I seriously consider it, I would like to know the opinion of the working group, and of the chairs. Is this something we want to accomplish? Who would be willing to report their experience and suggest text or review the outcome?

A little history: the process of writing RFC 4594 took at least three phases. I made an initial suggestion in ieprep at IETF 54, in Yokohama. This was met with significant resistance from at least one key participant in the Diffserv work, and I dropped it. My Nortel co-authors picked up the concept and the initial draft and took it to the ITU effort that was then developing what became (IIRC) G.1010, and then brought it back to the IETF and solicited my participation in the further development. We had differences of opinion, and we had a fair bit of operational input on certain services. However, much of it was a literature review - EF came from RFCs 3246 and 3247, CS* code points came from RFC 2474, AF from RFC 2597, Scavenger ("Low Priority") from Internet2's service and RFC 3662, and I suspect (but don't know) that the logic regarding service requirements came at least in part from the ITU discussions. Further subdivisions, especially in the video classes, came from several vendors' products at the time, which were using AF code points for video but complaining that the service as described had issues (they wanted to use the AFx2 and AFx3 code points to identify the more disposable bits in layered codecs, which doesn't work if an ISP uses AF as described).

More recently, James Polk sought to add services in draft-polk-tsvwg-rfc4594-update. It proposed four services for admitted traffic, building on RFC 5685, to whit:

> This document will import in four new '*-Admit' DSCPs from [ID-DSCP], 
> 2 others that are new but not capacity-admitted, one from RFC 5865, 
> and change the existing usage of 2 DSCPs from RFC 4594.
> This is discussed throughout the rest of this document.

It also changed some DSCP numbers, which is not backward compatible. It was a significant revision. I did not support the effort, in large part because of lack of operational input to it.

So, *if* this is to be done, I want to be sure folks are interested in doing it, and that operational experience will be reflected, not just the opinions of armchair theorists.

Who's in?