Re: [tsvwg] Tsvwg meeting: Diffserv - some thoughts

[<[e-mail]>]

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:[e-mail]]
Sent: Friday, November 09, 2012 5:08 PM
To: Geib, Rüdiger
Cc: [e-mail]
Subject: RE: Tsvwg meeting: Diffserv - some thoughts

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: [e-mail] [mailto:[e-mail]]
> Sent: Friday, November 09, 2012 4:01 AM
> To: Black, David
> Cc: [e-mail]
> Subject: Tsvwg meeting: Diffserv - some thoughts
>
> 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
>
>
>
>
>
>