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

[Xiayangsong <[e-mail]>]

Hi David

Thanks for your review.
Please check my inline response.

Thanks
Frank

-----邮件原件-----
发件人: Black, David [mailto:[e-mail]] 
发送时间: 2014年10月27日 2:41
收件人: Brian E Carpenter; Xiayangsong
抄送: [e-mail]; [e-mail]; [e-mail]; Black, David
主题: RE: [tsvwg] I-D Action: draft-xia-nvo3-vxlan-qosmarking-00.txt

> 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.
Frank=>ok. We will definitely study the 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.
Frank=>ok, Thank you again for the material.

It is unfortunate that draft-xia-nvo3-vxlan-qosmarking normatively references RFC 2474, but appears to effectively ignore that RFC.
Frank=>Thank you pointing out this. We will modify the draft  and hopefully you can  review it again.

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
> >>
> >