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

[Brian E Carpenter <[e-mail]>]

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