Subject: [Detnet-dp-dt] draft update

From: Jouni Korhonen <[email-masked]>
Date: Wed, 10 Feb 2016 12:24:47 -0800

Folks,

updated again.. I also tweaked the IPv6 section a bit.

@Lou - could you provide the QoS/CoS text so that we can use that as the 
criteria and align to that.

- Jouni

---

From: Lou Berger <[email-masked]>
Date: Wed, 10 Feb 2016 22:23:09 -0500

> criteria and align to that.
Jouni/All,

I know I have a some slides/text on this -- probably dating back to the
late 90s.  But I can't find it at the moment.  The key points to make are:

CoS -- class based traffic treatment
- Traffic classified based on course markings (DSCP, MPLS DS bits, 802.1p)
- May be remarked based on DPI/5 tuple policies
- Resources may or may not be assigned to class
- Rarely uses: admission control, shaping, policing
- May use ECN/QCN, e.g.,Two-Rate, Three-Color Marking

QoS ~=flow specific traffic treatment
- Specific flows are mapped against specific resources
    (typically at least bandwidth)
- traffic classified (i.e., flow identification) based on existing (IP)
headers or
     based on new headers (e.g., MPLS or v6 labels)
- usually includes admission control (e.g., bandwidth accounting)
    - sometimes includes over booking
- often uses shaping, policing
- may account for delay, jitter, loss

Does this help to get things started?

Lou

> - Jouni
>
> _______________________________________________
> Detnet-dp-dt mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/detnet-dp-dt
>

---

From: Jouni Korhonen <[email-masked]>
Date: Wed, 10 Feb 2016 20:40:33 -0800

Sure. Thx.

- JOuni

> On 10 Feb 2016, at 19:23, Lou Berger <[email-masked]> wrote:
> 
> 
> 
>

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Thu, 11 Feb 2016 11:04:30 +0000

Hello Lou:

I've seen tons of variations of these definitions over the last 20 years+. 

In the days (say SNA years) a class in networks was similar to class in planes. You have so many seats per class in the plane and the extra you have to refuse. Being able to reject a request was key. CAC relates to that. What is accepted has some guarantees such as arrival in time. DetNet fits there for the most part. 

QoS OTOH related to prioritization but with virtually infinite queues, so no way to guarantee time of delivery. Like the boss piling up work on the desk. And since queues are not effectively infinite, QoS would end up cutting piled-up traffic pseudo randomly. And the boss being less happy.

My reading of your definition is somewhat a reverse of that but it fits things I've been reading most of the time in the recent years. But since this is essential to our work, we probably need to either make our own terminology document or point on one that will be the reference for our work. 

What do you think?

Pascal

> -----Original Message-----
> From: Detnet-dp-dt [mailto:[email-masked]] On Behalf Of Lou
> Berger
> Sent: jeudi 11 février 2016 04:23
> To: [email-masked]
> Subject: Re: [Detnet-dp-dt] draft update
> 
> 
> 
> 
> > @Lou - could you provide the QoS/CoS text so that we can use that as
> > the criteria and align to that.
> Jouni/All,
> 
> I know I have a some slides/text on this -- probably dating back to the late
> 90s.  But I can't find it at the moment.  The key points to make are:
> 
> - traffic classified (i.e., flow identification) based on existing (IP) headers or

---

From: Lou Berger <[email-masked]>
Date: Thu, 11 Feb 2016 10:15:00 -0500

Hi Pascal,

> In the days (say SNA years) a class in networks was similar to class in planes. You have so many seats per class in the plane and the extra you have to refuse. Being able to reject a request was ke…

Interesting.  I've been around for a while and never ran into the
combination of network class of service and cac.

> QoS OTOH related to prioritization but with virtually infinite queues, so no way to guarantee time of delivery. Like the boss piling up work on the desk. And since queues are not effectively infini…
Sounds like someones very broken implementation. 

>
> My reading of your definition is somewhat a reverse of that but it fits things I've been reading most of the time in the recent years. 
found this -- and looks like a reasonable (and aligned definition) summary
http://www.differencebetween.com/difference-between-qos-and-vs-cos/
or
https://supportforums.cisco.com/discussion/9867531/difference-between-cos-and-qos

> But since this is essential to our work, we probably need to either make our own terminology document or point on one that will be the reference for our work. 
>
> What do you think?

I think you are right and we need to ensure we have good definitions. 
Hopefully pointing to IETF and IEEE definitions and standards.

starting points could include:
https://tools.ietf.org/html/rfc2212
https://tools.ietf.org/html/rfc2211
https://tools.ietf.org/html/rfc2475
https://tools.ietf.org/html/rfc2474
802.1p
SRP
other TSN docs.

Thanks,
Lou

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Thu, 11 Feb 2016 16:38:22 +0000

Hello Lou:

Where should these references be placed? I'd suggest the detnet architecture doc.

About CoS, the session in SNA was a key element with pacing and CoS. In subarea and appn, the CoS settings would determine which virtual route is acceptable per the constraints specified in the CoS tables. IOW the CoS was an upper layer thingy that impacted the route selection.

Cheers,

Pascal

> From: Lou Berger [mailto:[email-masked]]
> Sent: jeudi 11 février 2016 16:15
> To: Pascal Thubert (pthubert) <[email-masked]>; [email-masked]
> > In the days (say SNA years) a class in networks was similar to class in
> planes. You have so many seats per class in the plane and the extra you
> have to refuse. Being able to reject a request was key. CAC relates to that.
> What is accepted has some guarantees such as arrival in time. DetNet fits
> there for the most part.
> 
> Interesting.  I've been around for a while and never ran into the combination
> of network class of service and cac.
> 
> > QoS OTOH related to prioritization but with virtually infinite queues, so no
> way to guarantee time of delivery. Like the boss piling up work on the desk.
> And since queues are not effectively infinite, QoS would end up cutting
> piled-up traffic pseudo randomly. And the boss being less happy.
> > My reading of your definition is somewhat a reverse of that but it fits
> things I've been reading most of the time in the recent years.
> > But since this is essential to our work, we probably need to either make
> our own terminology document or point on one that will be the reference
> for our work.
> >
> > What do you think?
> 
> >> From: Detnet-dp-dt [mailto:[email-masked]] On Behalf
> >> Of Lou Berger
> >> I know I have a some slides/text on this -- probably dating back to
> >> the late 90s.  But I can't find it at the moment.  The key points to make
> are:
> >>

---

From: Pat Thaler <[email-masked]>
Date: Thu, 11 Feb 2016 11:33:16 -0800

IEEE 802.1Q doesn't have a definition of QoS and CoS.
The way it uses the terms is in line with the meanings of "quality" and
"class" -
Quality of service is the kind of service I want - e.g. delay, throughput
Class of service is the group I need to be in to get that quality on this
network - the marking on the packets and how the markings are treated.

With what has been added by TSN, IEEE 802.1Q provides a variety of tools
for how a class of service can operate. Some use reservations,
pacing/shaping and admission control or policing.

I'm comfortable with this in Lou's Class of Service bullets:

but not so much with:

On Thu, Feb 11, 2016 at 8:38 AM, Pascal Thubert (pthubert) <
[email-masked]> wrote:

> About CoS, the session in SNA was a key element with pacing and CoS. In
> subarea and appn, the CoS settings would determine which virtual route is
> acceptable per the constraints specified in the CoS tables. IOW the CoS was
> an upper layer thingy that impacted the route selection.
>
> Cheers,
>
> Pascal
>
>
> > >> - traffic classified (i.e., flow identification) based on existing
> (IP) headers
> > or