Subject: [tsvwg] Today's tsvwg meeting: Diffserv

From: "Black, David" <[email-masked]>
Date: Thu, 8 Nov 2012 10:53:07 -0500

I've agreed to act as a co-chair for today's tsvwg session on diffserv
to enable James Polk to focus on his drafts.  One of the goals of
today's discussion is to figure out what to do with those drafts.

Here's some background and context material on the Diffserv Classes
topics and a related Interconnect problem that's been raised in a
liaison from ITU-T SG12:

http://www.ietf.org/proceedings/85/slides/slides-85-tsvwg-8.pdf

Thanks,
--David
----------------------------------------------------
David L. Black, Distinguished Engineer
EMC Corporation, 176 South St., Hopkinton, MA  01748
+1 (508) 293-7953             FAX: +1 (508) 293-7786
[email-masked]        Mobile: +1 (978) 394-7754
----------------------------------------------------

---

From: <[email-masked]>
Date: Fri, 9 Nov 2012 10:00:31 +0100

David,

I'm not fully clear about which problem we (should) try to solve on DiffServ in tsvwg:

- the backbone or SP networks don't seem to be a QoS issue. A few classes probably will be sufficient.
- tsvwg isn't chartered to solve application problems (like wireless access, rtp packets only
  all x milliseconds and so on.
- if a bottleneck is overbooked, DiffServ can distribute capacity, but not create additional one.

Then some thoughts on streaming and teleconferencing
- streaming is delay tolerant. Where would one locate the large buffer? On a 10 GE interface?
  On a bottleneck interface? Very close to the application?
- streaming does not reduce traffic during congestion (multicast can't). What's the effect of
  assigning a deep buffer for it at backbone interfaces, if there's congestion?
- what's a good argument not to produce both across the same queue/class?

In sum: what does a DS RFC reader learn from a class description in terms loss tolerance yes/no,
delay tolerance yes/no and so on? My take: without understanding the present or required transport
properties of an application, a purely application based performance requirement description can
be misleading.

If we conclude that many classes are required to deal with bottleneck behaviour and we expect
this bottleneck to be present (and DiffServ t kick in), then what do we need:

- many classes, each of which has to be engineered by non-QoS-experts based on a configuration
  guidance given by 4594? That would be preconfigured, I guess and every implementor will
  apply phantasy. If like 10 PHBs are implemented, which gets what share of the bottleneck
  bandwidth? How do they compete for spare capacity? How is traffic admitted?

- or do we try to solve an admission control (or traffic engineering) problem by creating ever
  new class defintions.

Maybe it's worth to think about a problem statement to get a clear description of the issues,
we want to deal with. DiffServ created a set of tools, applicable for routers or networks
largely. It seems to me, that now the community starts to look at QoS more from an end to
end perspective, but tries to solve issues with router mechanisms. That's not what DiffServ
is designed for.

Regards,

Rüdiger

---

From: James Polk <[email-masked]>
Date: Fri, 09 Nov 2012 06:44:56 -0600

<with my individual hat on>

Some reactions

- We're chartered with everything that has to do 
with a document we produced in the past, which includes RFC 4594.

- the only interface speed you mention is 10Gb/s, 
as it that is the only interface we need to be concerned with.

- what about all the millions of Linksys, D-Link 
and Netgear type routers that connect to the Internet?

- video streaming and teleconferencing are 
mentioned, then only examples of buffered 
streaming are given - and nothing is said about 
interactive communications - which is one of the 
bigger points of this RFC4594-update draft.

I think this note below is colored by looking 
through a core interconnect lens exclusively, as 
if that's all we should be concerned with and 
that's the only place DS is used.

James

At 03:00 AM 11/9/2012, [email-masked] wrote:
>David,
>
>I'm not fully clear about which problem we 
>(should) try to solve on DiffServ in tsvwg:
>
>- the backbone or SP networks don't seem to be a 
>QoS issue. A few classes probably will be sufficient.
>- tsvwg isn't chartered to solve application 
>problems (like wireless access, rtp packets only
>- if a bottleneck is overbooked, DiffServ can 
>distribute capacity, but not create additional one.
>
>- streaming is delay tolerant. Where would one 
>locate the large buffer? On a 10 GE interface?
>- streaming does not reduce traffic during 
>congestion (multicast can't). What's the effect of
>In sum: what does a DS RFC reader learn from a 
>class description in terms loss tolerance yes/no,
>delay tolerance yes/no and so on? My take: 
>without understanding the present or required transport
>properties of an application, a purely 
>application based performance requirement description can
>be misleading.
>
>If we conclude that many classes are required to 
>deal with bottleneck behaviour and we expect
>- many classes, each of which has to be 
>engineered by non-QoS-experts based on a configuration
>   guidance given by 4594? That would be 
> preconfigured, I guess and every implementor will
>   apply phantasy. If like 10 PHBs are 
> implemented, which gets what share of the bottleneck
>- or do we try to solve an admission control (or 
>traffic engineering) problem by creating ever
>   new class defintions.
>
>Maybe it's worth to think about a problem 
>statement to get a clear description of the issues,
>we want to deal with. DiffServ created a set of 
>tools, applicable for routers or networks
>largely. It seems to me, that now the community 
>starts to look at QoS more from an end to
>end perspective, but tries to solve issues with 
>router mechanisms. That's not what DiffServ
>is designed for.
>
>Regards,
>
>Rüdiger

---

From: "Black, David" <[email-masked]>
Date: Fri, 9 Nov 2012 11:07:36 -0500

Rüdiger,

<newly-acquired tsvwg co-chair hat off>

While Diffserv was significantly motivated by service provider core
and backbone networks, the applicability of Diffserv has never been
limited to that class of networks.  For example, see slide 2 in the
slide deck that James used yesterday:

http://www.ietf.org/proceedings/85/slides/slides-85-tsvwg-13.pptx

There are almost certainly opportunities to differentiate treatment
of interactive media traffic (that needs a low jitter budget) from
non-interactive media traffic selectively near known/expected
bottlenecks even if there may not be a rationale for doing that
differentiation globally.

The sense of the room in yesterday's tsvwg meeting (will need to be
confirmed on this list, separate message coming soon) was that the
IETF should work on the diffserv interconnect problem represented
in the ITU-T SG12 liaison and your draft.  IMHO, that work is likely
to result in a small number of interconnect traffic classes that may
or may not resemble the treatment aggregates in RFC 5127.  There will
be nothing to stop a network from choosing to deploy just those
interconnect classes internally in addition to using them for
interconnection.  A network could also internally deploy a subset
of the RFC 4594 (or successor) traffic classes, or even just some
or all of the four treatment aggregates in RFC 5127 (or successor).

In particular, there is no current or intended requirement that any
network deploy all of the diffserv service classes in RFC 4594 or any
successor.  I also want to be clear that I am not assuming that the
interconnect traffic classes will be based on an update to RFC
5127, as they address different problems - the approach here is
TBD by the WG.

Thanks,
--David

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
> Sent: Friday, November 09, 2012 4:01 AM
> To: Black, David
> Cc: [email-masked]
> Subject: Tsvwg meeting: Diffserv - some thoughts
> 
> David,
> 
> - tsvwg isn't chartered to solve application problems (like wireless access,
>	rtp packets only all x milliseconds and so on.
> - streaming is delay tolerant. Where would one locate the large buffer? On a
>	10 GE interface? On a bottleneck interface? Very close to the application?
> - streaming does not reduce traffic during congestion (multicast can't).
>	What's the effect of assigning a deep buffer for it at backbone interfaces,
>	if there's congestion?

---

From: <[email-masked]>
Date: Mon, 12 Nov 2012 09:32:44 +0100

David, James,

got the point related to interconnection and no, I do not just
look at DiffServ from a Backbone perspective. The company I work
for runs some million DSL accesses and if any of you bothers,
you'll find at least one SIP related QoS publication I wrote.

The reason for my last mail was that James goes for treating video
conference audio different than the pictures. That's probably
based on customer feedback. What that implies is, there has
been a packet dropping bottleneck. And at least one option of
application based class design should assume its presence.

The audio/video experts of my company (on of them Alexander Raake,
http://en.wikipedia.org/wiki/Alexander_Raake)
recommend forwarding audio and video frames in the same queue.
His efforts on objective video quality models show,
that viewers regard a loss of lip-synch as quality degradation.
I'll probably see him this week and ask hom for his view.

That may be a streaming versus conferencing issue (different
environments and audience) and I'm open for discussion.

What I suggest is to get more clarity about which problem we
try to solve by DiffServ regarding bottlenecks. Sorry if
that is clear to all and I'm a bit thick here.

Regards, Rüdiger

-----Original Message-----
From: Black, David [mailto:[email-masked]]
Sent: Friday, November 09, 2012 5:08 PM
To: Geib, Rüdiger
Cc: [email-masked]
Subject: RE: Tsvwg meeting: Diffserv - some thoughts

Rüdiger,

Thanks,
--David

---

From: "Black, David" <[email-masked]>
Date: Mon, 12 Nov 2012 13:59:53 -0500

> environments and audience) and I'm open for discussion.

Good - even if/when audio and video are in different service
classes in RFC 4594, they don't have to be in different queues
in the implementation, e.g., see RFC 5127.

> that is clear to all and I'm a bit thick here.

We're on the same page here.  The only initial result of the
discussion of James' draft last week is that we definitely have
a problem with the absence of the distinction between interactive
vs. non-interactive media traffic.  I have the action items to
draft crisp questions to the list about the other things that
James proposes changing so that we can have focused discussions
around whether to change them.

Thanks,
--David

> Sent: Monday, November 12, 2012 3:33 AM
> To: Black, David; [email-masked]
> Cc: [email-masked]

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 13 Nov 2012 07:58:01 +0000

> in the implementation, e.g., see RFC 5127.

Isn't there a problem when mixing elephants and mice in this way?
Although they might have closely related requirements for QoS
metrics, video elephants can trample on audio mice when they
share a queue.

> vs. non-interactive media traffic.  

Especially given that interactive traffic is often enough hidden
in TCP streams these days. There's no easy way to classify
this traffic except at the source.

   Brian

> I have the action items to

---

From: "Black, David" <[email-masked]>
Date: Tue, 13 Nov 2012 09:33:12 -0500

> metrics, video elephants can trample on audio mice when they

Sure, but I believe that's a network operator's decision on how
to deploy the potentially limited number of queues available.

Thanks,
--David

> From: Brian E Carpenter [mailto:[email-masked]]
> Sent: Tuesday, November 13, 2012 2:58 AM
> To: Black, David
> Cc: [email-masked]; [email-masked]
> Subject: Re: [tsvwg] Tsvwg meeting: Diffserv - some thoughts
> 
> >>> I'm not fully clear about which problem we (should) try to solve on
> DiffServ
> >>> in tsvwg:
> >>>
> >>> delay tolerance yes/no and so on? My take: without understanding the
> present
> >> or required transport
> >>> - many classes, each of which has to be engineered by non-QoS-experts
> based
> >> on a configuration
> >>>   apply phantasy. If like 10 PHBs are implemented, which gets what share
> of
> >> the bottleneck