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

["Black, David" <[e-mail]>]

> That may be a streaming versus conferencing issue (different
> 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.

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

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


> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]]
> Sent: Monday, November 12, 2012 3:33 AM
> To: Black, David; [e-mail]
> Cc: [e-mail]
> Subject: RE: Tsvwg meeting: Diffserv - some thoughts
> 
> 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
> >
> >
> >
> >
> >
> >
>