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

[Xiayangsong <[e-mail]>]

Hi  Brian

Thank for your constructive suggestion.

Please see my inline response.

Thanks
Frank

-----邮件原件-----
发件人: Brian E Carpenter [mailto:[e-mail]] 
发送时间: 2014年10月25日 11:54
收件人: Xiayangsong
抄送: [e-mail]; [e-mail]; [e-mail]; [e-mail]
主题: Re: 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.


Frank=>Thank for the instruction, and I will study through these documents .

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


Frank=>understood.

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


Frank=>understood.

In summary my suggestion is
1) use 6 bits
Frank=>I am not sure.  VxLAN is a MAC over UDP technology, and it is for emulating Ethernet link layer through underlying  IP infrastructure.  
IEEE 802.1q specifies 3 bits for differentiating Class of Service (CoS).  These 3 bits are  one-to-one  mapped  to  VxLAN encapsulation.
I don't know how fill the other 3 bits if using 6 bits for VxLAN QoS.

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