> 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:[email protected]] On Behalf Of Brian E Carpenter > Sent: Friday, October 24, 2014 11:54 PM > To: Xiayangsong > Cc: [email protected]; [email protected]; [email protected]; draft-xia-nvo3- > [email protected] > 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:[email protected]] 发送时间: 2014年10月25日 8:54 收 > > 件人: [email protected]; > > [email protected]; > > [email protected] 主题: 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, [email protected] 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 [email protected] > >> 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 > >> > > _______________________________________________ nvo3 mailing list [email protected] https://www.ietf.org/mailman/listinfo/nvo3
