Re: [tsvwg] I-D Action: draft-xia-nvo3-vxlan-qosmarking-00.txt

["Black, David" <[e-mail]>]

> 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:[e-mail]] On Behalf Of Brian E Carpenter
> Sent: Friday, October 24, 2014 11:54 PM
> To: Xiayangsong
> Cc: [e-mail]; [e-mail]; [e-mail]; draft-xia-nvo3-
> [e-mail]
> 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:[e-mail]] 发送时间: 2014年10月25日 8:54 收
> > 件人: [e-mail];
> > [e-mail];
> > [e-mail] 主题: 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, [e-mail] 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 [e-mail]
> >> 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
> >>
> >