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

From: Brian E Carpenter <[email-masked]>
Date: Sat, 25 Oct 2014 08:37:54 +1300

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.

2. It repeats the MPLS error of trying to express service differentiation
in 3 bits.

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

  Brian

On 25/10/2014 08:16, [email-masked] 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-masked]
> 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
>

---

From: "Black, David" <[email-masked]>
Date: Fri, 24 Oct 2014 19:54:16 +0000

[+nvo3 list]

Well, item 3 is definitely a mistake.  We went over that point at length during
one of the tsvwg sessions in London in the context of another draft, so it's
disappointing to see that mistake showing up again so soon (see Section 3 of
RFC 2474 to understand why it's a mistake).

Thanks,
--David (as tsvwg co-chair, who needs to start assembling the Honolulu agenda)

> -----Original Message-----
> From: tsvwg [mailto:[email-masked]] On Behalf Of Brian E Carpenter
> Sent: Friday, October 24, 2014 3:38 PM
> To: [email-masked]; [email-masked]; nvo3-
> [email-masked]
> Subject: Re: [tsvwg] I-D Action: draft-xia-nvo3-vxlan-qosmarking-00.txt
> 
> Hi,
>

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 25 Oct 2014 13:54:05 +1300

Hi,

  Brian

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 25 Oct 2014 16:54:23 +1300

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-masked]] 发送时间: 2014年10月25日 8:54 收
> 件人: [email-masked];
> [email-masked];
> [email-masked] 主题: 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:
> 

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

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

>> 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.
>> 
>> 
>> 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.
>> 
>> I-D-Announce mailing list [email-masked]

---

From: "Black, David" <[email-masked]>
Date: Sun, 26 Oct 2014 18:40:57 +0000

> 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

> Sent: Friday, October 24, 2014 11:54 PM
> To: Xiayangsong
> Cc: [email-masked]; [email-masked]; [email-masked]; draft-xia-nvo3-
> [email-masked]

---

From: Xiayangsong <[email-masked]>
Date: Sat, 25 Oct 2014 01:37:16 +0000

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.

Thanks
Frank

-----邮件原件-----
发件人: Brian E Carpenter [mailto:[email-masked]] 
发送时间: 2014年10月25日 8:54
收件人: [email-masked]; [email-masked]; [email-masked]
主题: 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.  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.

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.  

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.

  Brian

On 25/10/2014 08:16, [email-masked] wrote:
> 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-Draft directories: http://www.ietf.org/shadow.html or 
> ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>

---

From: Xiayangsong <[email-masked]>
Date: Mon, 27 Oct 2014 01:12:34 +0000

Hi David

Thanks for your review.
Please check my inline response.

Thanks
Frank

-----邮件原件-----
发件人: Black, David [mailto:[email-masked]] 
发送时间: 2014年10月27日 2:41
收件人: Brian E Carpenter; Xiayangsong
抄送: [email-masked]; [email-masked]; [email-masked]; 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

> Cc: [email-masked]; [email-masked]; [email-masked]; 
> draft-xia-nvo3- [email-masked]
> > 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.
> >
> Understood, but IETF standards are supposed to correspond to real 
> engineering, so that is no problem.
> 
> >
> > Thanks Frank
> >
> > 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.
> 
> > error, please teach me.  However, in engineering area, MPLS 3 bit 
> > has a pragmatic purpose.  You can check switches/routers 
> The problem is that re-using the three EXP (experimental) bits in MPLS 
> for quality of service signalling was an afterthought.
> 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.
> 
> >
> >  "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.
> 
> 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.
> 
> 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
> >
> >> 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.
> >>
> >>

---

From: Xiayangsong <[email-masked]>
Date: Sat, 25 Oct 2014 11:13:03 +0000

Hi  Brian

Thank for your constructive suggestion.

Please see my inline response.

Thanks
Frank

-----邮件原件-----
发件人: Brian E Carpenter [mailto:[email-masked]] 
发送时间: 2014年10月25日 11:54
收件人: Xiayangsong
抄送: [email-masked]; [email-masked]; [email-masked]; [email-masked]
主题: Re: I-D Action: draft-xia-nvo3-vxlan-qosmarking-00.txt

Hi,

On 25/10/2014 14:37, Xiayangsong wrote:
> standard  guy . I discussed this idea with Behcet who kindly put me as 
> the first author.
> 

Understood, but IETF standards are supposed to correspond to real engineering, so that is no problem.

> Thus, in most scenario, QoS is about packet loss control which is  

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 .

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

> 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

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