Re: [nvo3] [tsvwg] I-D Action: draft-xia-nvo3-vxlan-qosmarking-00.txt
"Black, David" <david.black@emc.com> Sun, 26 October 2014 18:41 UTC
Return-Path: <david.black@emc.com>
X-Original-To: nvo3@ietfa.amsl.com
Delivered-To: nvo3@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AB5121A0365; Sun, 26 Oct 2014 11:41:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.311
X-Spam-Level:
X-Spam-Status: No, score=-4.311 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, 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 R71g1bFBHVuS; Sun, 26 Oct 2014 11:41:22 -0700 (PDT)
Received: from mailuogwdur.emc.com (mailuogwdur.emc.com [128.221.224.79]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 847671A0019; Sun, 26 Oct 2014 11:41:22 -0700 (PDT)
Received: from maildlpprd56.lss.emc.com (maildlpprd56.lss.emc.com [10.106.48.160]) by mailuogwprd51.lss.emc.com (Sentrion-MTA-4.3.0/Sentrion-MTA-4.3.0) with ESMTP id s9QIfCGM031719 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 26 Oct 2014 14:41:13 -0400
X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd51.lss.emc.com s9QIfCGM031719
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=emc.com; s=jan2013; t=1414348873; bh=LGSlGApwRgXJ7QGOyKqwCDblVtI=; h=From:To:CC:Subject:Date:Message-ID:References:In-Reply-To: Content-Type:Content-Transfer-Encoding:MIME-Version; b=AKdGhpMrVYNgKKzYsohaRF0HE9YVNjD3UlNZxfyzwsFISRWd01LaUp/PRxh+PHBqc ILEXzGtPoW4DigiCzbcvM44eHgRouoI4DLdYRBhyP1MI875LOgnyQa53E82xBPgWwz Ibc+wmaWJ4CE//GbCMbzKUp7DmV1caIgPvPHATws=
X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd51.lss.emc.com s9QIfCGM031719
Received: from mailusrhubprd01.lss.emc.com (mailusrhubprd01.lss.emc.com [10.253.24.19]) by maildlpprd56.lss.emc.com (RSA Interceptor); Sun, 26 Oct 2014 14:40:28 -0400
Received: from mxhub10.corp.emc.com (mxhub10.corp.emc.com [10.254.92.105]) by mailusrhubprd01.lss.emc.com (Sentrion-MTA-4.3.0/Sentrion-MTA-4.3.0) with ESMTP id s9QIewIN009397 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sun, 26 Oct 2014 14:40:59 -0400
Received: from MXHUB106.corp.emc.com (10.253.58.23) by mxhub10.corp.emc.com (10.254.92.105) with Microsoft SMTP Server (TLS) id 8.3.327.1; Sun, 26 Oct 2014 14:40:58 -0400
Received: from MX104CL02.corp.emc.com ([169.254.8.131]) by MXHUB106.corp.emc.com ([10.253.58.23]) with mapi id 14.03.0195.001; Sun, 26 Oct 2014 14:40:58 -0400
From: "Black, David" <david.black@emc.com>
To: Brian E Carpenter <brian.e.carpenter@gmail.com>, Xiayangsong <xiayangsong@huawei.com>
Thread-Topic: [tsvwg] I-D Action: draft-xia-nvo3-vxlan-qosmarking-00.txt
Thread-Index: AQHP7756nCxf6IJoF0O8TWroZ6IOLZxAP+qA///vW5OAAoJbAA==
Date: Sun, 26 Oct 2014 18:40:57 +0000
Message-ID: <CE03DB3D7B45C245BCA0D24327794936066F2C@MX104CL02.corp.emc.com>
References: <20141024191612.9331.19202.idtracker@ietfa.amsl.com> <544AF4AD.50503@gmail.com> <CB60645E6241144CB82269604373757A603D4009@nkgeml503-mbx.china.huawei.com> <544B1EEF.7040002@gmail.com>
In-Reply-To: <544B1EEF.7040002@gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.238.44.101]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-Sentrion-Hostname: mailusrhubprd01.lss.emc.com
X-RSA-Classifications: DLM_1, public
Archived-At: http://mailarchive.ietf.org/arch/msg/nvo3/gYUiQqoEOUYR4p_NO2JkvBgGWRA
Cc: "Black, David" <david.black@emc.com>, "nvo3@ietf.org" <nvo3@ietf.org>, "tsvwg@ietf.org" <tsvwg@ietf.org>, "draft-xia-nvo3-vxlan-qosmarking@tools.ietf.org" <draft-xia-nvo3-vxlan-qosmarking@tools.ietf.org>
Subject: Re: [nvo3] [tsvwg] I-D Action: draft-xia-nvo3-vxlan-qosmarking-00.txt
X-BeenThere: nvo3@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "Network Virtualization Overlays \(NVO3\) Working Group" <nvo3.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/nvo3>, <mailto:nvo3-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/nvo3/>
List-Post: <mailto:nvo3@ietf.org>
List-Help: <mailto:nvo3-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/nvo3>, <mailto:nvo3-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 26 Oct 2014 18:41:25 -0000
> I suggest carefully reviewing RFC 2474 and RFC 2475, and the > specific descriptions of per-hop behaviours in RFC 2597 and RFC > 3246. Also it is worth reviewing RFC 4594, > draft-geib-tsvwg-diffserv-intercon, and the work of the AQM WG > (http://datatracker.ietf.org/wg/aqm/charter/). Truly there is a > lot more to queue management than simple priority. To be more specific, section 4 of draft-xia-nvo3-vxlan-qosmarking appears to be headed towards reinventing RFC 4594, so I strongly suggest reviewing that RFC. In addition to the documents Brian listed, there's also some shorter diffserv background information in draft-ietf-dart-dscp-rtp that may be helpful. If bit conservation is really important, I recommend reviewing RFC 5127 in addition to draft-geib-tsvwg-diffserv-intercon. It is unfortunate that draft-xia-nvo3-vxlan-qosmarking normatively references RFC 2474, but appears to effectively ignore that RFC. Thanks, --David > -----Original Message----- > From: tsvwg [mailto:tsvwg-bounces@ietf.org] On Behalf Of Brian E Carpenter > Sent: Friday, October 24, 2014 11:54 PM > To: Xiayangsong > Cc: nvo3-chairs@tools.ietf.org; nvo3@ietf.org; tsvwg@ietf.org; draft-xia-nvo3- > vxlan-qosmarking@tools.ietf.org > Subject: Re: [tsvwg] I-D Action: draft-xia-nvo3-vxlan-qosmarking-00.txt > > Hi, > > On 25/10/2014 14:37, Xiayangsong wrote: > > Hi Brian > > > > Thanks for your attention on this topic. I am an engineer not > > a standard guy . I discussed this idea with Behcet who > > kindly put me as the first author. > > > > So I try to respond you from engineering perspective. > > Understood, but IETF standards are supposed to correspond to > real engineering, so that is no problem. > > > > > Thanks Frank > > > > -----邮件原件----- 发件人: Brian E Carpenter > > [mailto:brian.e.carpenter@gmail.com] 发送时间: 2014年10月25日 8:54 收 > > 件人: tsvwg@ietf.org; > > draft-xia-nvo3-vxlan-qosmarking@tools.ietf.org; > > nvo3-chairs@tools.ietf.org 主题: Re: I-D Action: > > draft-xia-nvo3-vxlan-qosmarking-00.txt > > > > Hi, > > > > This draft needs to be discussed in tsvwg I think. It has > > some significant problems IMHO: > > > > 1. It confuses QoS and priority in a strange way. > > > Frank=>QoS > > is about packet loss, bandwidth, latency and jitter. > > Those are the usual QoS metrics of course. > > > Bandwidth can be controller by CAR technology. As for latency > > and jitter, they are kind of inherent parameter of a given > > network, and there is hardly a way to controller them . > > Thus, in most scenario, QoS is about packet loss control > > which is based on priority. > > I suggest carefully reviewing RFC 2474 and RFC 2475, and the > specific descriptions of per-hop behaviours in RFC 2597 and RFC > 3246. Also it is worth reviewing RFC 4594, > draft-geib-tsvwg-diffserv-intercon, and the work of the AQM WG > (http://datatracker.ietf.org/wg/aqm/charter/). Truly there is a > lot more to queue management than simple priority. > > > 2. It repeats the MPLS error of trying to express service > > differentiation in 3 bits. > > > > Frank=>I don't know the MPLS > > error, please teach me. However, in engineering area, MPLS 3 > > bit has a pragmatic purpose. You can check switches/routers > > specification from different vendors about this. > > The problem is that re-using the three EXP (experimental) bits > in MPLS for quality of service signalling was an afterthought. > Three bits simply isn't enough to express a reasonable range of > service classes. Unfortunately it is all we have in MPLS, but > that is not a valid reason for copying the same mistake. If you > adopt 6 bits, it should be fairly easy to adopt the whole > diffserv model. That would save a lot of work, both in > specification and in implementation. > > > > > 3. It makes a completely inaccurate statement about diffserv: > > "The first three bits of DS field are used for IP precedence > > and the last three are used as diff serv bits." > > > > Frank=>I > > guess the statement was copied from some RFC, and I would > > double check it. > > If so, that RFC is wrong. It is true that in some cases, the > recommended diffserv code points were chosen to have the same > bit pattern as the old ToS precedence bits. This was done so > that if packets marked with diffserv code points happened to > pass through a legacy router that supported the ToS bits, the > results would be reasonable. However, diffserv code points are > in fact defined as opaque 6-bit values. The above references > should make this clear. > > In summary my suggestion is > 1) use 6 bits > 2) state that they are to be interpreted exactly like the DSCP > defined in RFC 2474 > 3) this simplifies the question of mapping between the vxlan > header and the IP header, when needed. > 4) it would also simplify interworking with the QoS model for > WebRTC that is under development. > > Regards > Brian > > > > > Brian > > > > On 25/10/2014 08:16, internet-drafts@ietf.org wrote: > >> A New Internet-Draft is available from the on-line > >> Internet-Drafts directories. > >> > >> > >> Title : Quality of Service Marking in Virtual > >> eXtensible Local Area Network Authors : Frank Xia > >> Behcet Sarikaya Filename : > >> draft-xia-nvo3-vxlan-qosmarking-00.txt Pages : 9 > >> Date : 2014-10-24 > >> > >> Abstract: The Virtual eXtensible Local Area Network enables > >> multiple tenants to operate in a data center. Each tenant > >> needs to be assigned a priority group to prioritize their > >> traffic. Cloud carriers wish to use quality of service to > >> differentiate different applications. For these purposes, > >> three bits are assigned in the eXtensible Local Area > >> Network header. How these bits are assigned and are > >> processed in the network are explained in detail. > >> > >> > >> The IETF datatracker status page for this draft is: > >> https://datatracker.ietf.org/doc/draft-xia-nvo3-vxlan-qosmarking/ > >> > >> > >> There's also a htmlized version available at: > >> http://tools.ietf.org/html/draft-xia-nvo3-vxlan-qosmarking-00 > >> > >> > >> > >> Please note that it may take a couple of minutes from the > >> time of submission until the htmlized version and diff are > >> available at tools.ietf.org. > >> > >> Internet-Drafts are also available by anonymous FTP at: > >> ftp://ftp.ietf.org/internet-drafts/ > >> > >> _______________________________________________ > >> I-D-Announce mailing list I-D-Announce@ietf.org > >> https://www.ietf.org/mailman/listinfo/i-d-announce > >> Internet-Draft directories: http://www.ietf.org/shadow.html > >> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > >> > >
- Re: [nvo3] [tsvwg] I-D Action: draft-xia-nvo3-vxl… Black, David
- Re: [nvo3] I-D Action: draft-xia-nvo3-vxlan-qosma… Brian E Carpenter
- Re: [nvo3] [tsvwg] I-D Action: draft-xia-nvo3-vxl… Black, David