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

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

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

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

Thanks,
--David


> -----Original Message-----
> From: Brian E Carpenter [mailto:[e-mail]]
> Sent: Tuesday, November 13, 2012 2:58 AM
> To: Black, David
> Cc: [e-mail]; [e-mail]
> Subject: Re: [tsvwg] Tsvwg meeting: Diffserv - some thoughts
> 
> On 12/11/2012 18:59, Black, David wrote:
> >> 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.
> 
> 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.
> 
> >> 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.
> 
> 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
> > 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
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>
> >
> >
>