Subject: [MMUSIC] New rev of the Traffic Class attribute draft

From: "James M. Polk" <[email-masked]>
Date: Wed, 13 Jul 2011 16:36:46 -0500

MMUSIC

We have recently submitted the next version of the traffic class 
attribute, here

http://www.ietf.org/internet-drafts/draft-polk-mmusic-traffic-class-for-sdp-02.txt

Most of the work in this version has to do with a newly inserted 
Section 2 (i.e., the old section 2 is now section 3).

This new section 2 creates and defines the framework for this 
attribute (something Christer mentioned he would like to see.

Also, several mentioned they wanted to see term or string definitions 
we were proposing that the last version lacked. This is in the new version.

With the addition to this new section, the biggest changes are as follows:

- we changed the attribute string have this format

parent.application(.adjective)(.adjective)(.admitted/non-admitted)

(this isn't the exact ABNF, which is in Section 3 now)

- We added that the parent and application components are a pairing.

- we added that there can be zero or more adjective components 
describing the traffic class

- we provide a list of each component for we review, i.e., separate 
lists of parent, application, adjective and cac-class components. 
Some of the application components are settle (i.e., we have one for 
Netflix type of traffic, but don't have an actual string picked yet).

Most of the rest of the changes were minor nits or changes to the new 
attribute structure.

Comments are really appreciated.

James, Paul & Subha

---

From: Stephen Botzko <[email-masked]>
Date: Fri, 29 Jul 2011 01:13:01 -0400

Generally speaking, I like the new structure, and think the parent classes
and application components are pretty good.

I am thinking there is room for some more refinement on the adjective
substrings - particularly Immersive and Desktop-Video.  For one thing, there
is a space in between Immersive and Desktop-Video (room videoconferencing).
This usually has higher resolution and video quality than PC desktop video,
but less than Immersive.

Perhaps more importantly, I am not clear from the draft what the adjective
substrings are for.  In particular I do not understand if the adjective
strings are intended to nuance the traffic characteristics for the parent
class+application component in some way (and if so, how).

For video, the main distinction would appear to be bandwidth.  If so, we
should consider how to account for future codec improvements.  An HEVC video
codec (expected to be standardized in 2013) will reduce the bandwidth
requirement over today's AVC/H.264 by 50%.  So tomorrow's "Immersive" class
of system might have similar bandwidth requirements to an older traditional
videoconferencing system.

Stephen Botzko

On Wed, Jul 13, 2011 at 5:36 PM, James M. Polk <[email-masked]> wrote:

> MMUSIC
>
> We have recently submitted the next version of the traffic class attribute,
> here
>
> http://www.ietf.org/internet-**drafts/draft-polk-mmusic-**
> traffic-class-for-sdp-02.txt<http://www.ietf.org/internet-drafts/draft-polk-mmusic-traffic-class-for-sdp-02.txt>
>
> Most of the work in this version has to do with a newly inserted Section 2
> (i.e., the old section 2 is now section 3).
>
> This new section 2 creates and defines the framework for this attribute
> (something Christer mentioned he would like to see.
>
> Also, several mentioned they wanted to see term or string definitions we
> were proposing that the last version lacked. This is in the new version.
>
> parent.application(.adjective)**(.adjective)(.admitted/non-**admitted)
>
> - we added that there can be zero or more adjective components describing
> the traffic class
>
> - we provide a list of each component for we review, i.e., separate lists
> of parent, application, adjective and cac-class components. Some of the
> application components are settle (i.e., we have one for Netflix type of
> traffic, but don't have an actual string picked yet).
>
> ______________________________**_________________
> mmusic mailing list
> [email-masked]
> https://www.ietf.org/mailman/**listinfo/mmusic<https://www.ietf.org/mailman/listinfo/mmusic>
>

---

From: "Paul E. Jones" <[email-masked]>
Date: Fri, 29 Jul 2011 09:46:40 -0400

Stephen,

We do want the adjectives to help serve as a means of differentiating
traffic.  Conversational.audio is quite different from Conversational.video
in many respects.  Likewise, Conversational.video and
Conversational.video.immersive would suggest to me that we need to give
better treatment of media flows to the latter.

You suggestion to introduce Conversational.video.room-conferencing (or
similar) is quite reasonable.  It is because we might want to give different
treatment to different kinds of conversational video that we propose this
structure.  Exactly how that treatment might differ is beyond the scope of
this draft, though.

What we should do is have an IANA registry for the standard adjectives (as
suggested in the draft).  Whatever document proposes inclusion of a new
adjective should probably describe the type of traffic and why the adjective
is introduced, much as we did for Conversational in section 2.2.

I'm not sure how we would relate the bandwidth requirements with the traffic
class labels, though.  I personally view the labels as useful for logging,
QoS, etc.  What is important is understanding the traffic characteristics.
An immersive video system ("Telepresence"), regardless of how much bandwidth
is consumed, needs to have minimal delay in the network as compared to
things like Multimedia-Streaming or even Conversational.video.desktop-video.

In any case, we should definitely consider any proposed additional
adjectives at the outset.  We did not attempt to define adjectives for some
classes, but the framework is there: we can introduce them now or in the
future.  Some would most certainly be introduced in the future.

Paul

From: [email-masked] [mailto:[email-masked]] On Behalf Of
Stephen Botzko
Sent: Friday, July 29, 2011 1:13 AM
To: James M. Polk
Cc: [email-masked]; Subha Dhesikan (sdhesika); Paul Jones
Subject: Re: [MMUSIC] New rev of the Traffic Class attribute draft

Stephen Botzko

MMUSIC

http://www.ietf.org/internet-drafts/draft-polk-mmusic-traffic-class-for-sdp-
02.txt

- we provide a list of each component for we review, i.e., separate lists of
parent, application, adjective and cac-class components. Some of the
application components are settle (i.e., we have one for Netflix type of
traffic, but don't have an actual string picked yet).

James, Paul & Subha

_______________________________________________
mmusic mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/mmusic

---

From: Stephen Botzko <[email-masked]>
Date: Fri, 29 Jul 2011 10:07:15 -0400

Hi Paul

I am thinking there are at least two ways to approach the differentiation.

One way is to further refine the traffic characteristics of the base
component.  Presently "conversational" only specifies very low tolerance to
loss, delay and jitter.  So I could envision using the other components to
characterize other attributes about the traffic.  Personally I think that
has merit, but I think there needs to be some care in ensuring that the
characterization that is appropriate is clear.  That way, as new
applications are registered, there would hopefully be useful traffic
information provided.

Another way is to use the adjectives to somehow describe the priority or
"importance" of the flow.  Is that what you mean when you say Immersive
needs "better treatment"?  Personally I would find that problematic.
Certainly my own company's QOS classes are not organized that way.
Generally within the conversational class, the purpose of the meeting is a
more important criteria to drive the priority of the traffic.

All this is to say that the framework itself seems reasonable, but there
needs to be more discussion, particularly on the adjectives.

Stephen Botzko

On Fri, Jul 29, 2011 at 9:46 AM, Paul E. Jones <[email-masked]>wrote:

> Stephen,****
> ** **
> better treatment of media flows to the latter.****
>
> ** **
>
> this draft, though.****
> ** **
> is introduced, much as we did for Conversational in section 2.2.****
>
> ** **
>
> I’m not sure how we would relate the bandwidth requirements with the
> traffic class labels, though.  I personally view the labels as useful for
> logging, QoS, etc.  What is important is understanding the traffic
> characteristics.  An immersive video system (“Telepresence”), regardless of
> how much bandwidth is consumed, needs to have minimal delay in the network
> as compared to things like Multimedia-Streaming or even
> Conversational.video.desktop-video.****
>
> ** **
>
> future.  Some would most certainly be introduced in the future.****
>
> ** **
>
> Paul****
>
> ** **
>
> *From:* [email-masked] [mailto:[email-masked]] *On
> Behalf Of *Stephen Botzko
> *Sent:* Friday, July 29, 2011 1:13 AM
> *To:* James M. Polk
> *Cc:* [email-masked]; Subha Dhesikan (sdhesika); Paul Jones
> *Subject:* Re: [MMUSIC] New rev of the Traffic Class attribute draft****
>
> ** **
>
> Stephen Botzko****
> On Wed, Jul 13, 2011 at 5:36 PM, James M. Polk <[email-masked]> wrote:**
> **
>
> MMUSIC
>
> https://www.ietf.org/mailman/listinfo/mmusic****
>
> ** **
>

---

From: "Paul E. Jones" <[email-masked]>
Date: Sat, 30 Jul 2011 01:44:12 -0400

Stephen,

What we tried to do was limit the number of base classes to some finite
number that was largely, if not completely, representative of the classes of
traffic for which we might want to provide QoS.  We spent a fair amount of
time trying to figure out how to make just the base class sufficient, but
decided we needed a better approach that included adjectives.

The adjectives are just adjectives.  How one relates that to QoS policies is
another matter.  I am suggesting that we might want to consider
Conversational.immersive more important than Conversational.desktop-video.
However, I can accept an argument that Conversational.desktop-video._ceo or
Conversational.desktop-video._executive_summit might be given better
treatment than the routine Telepresence call.

The intent was that we define a structure such that the adjectives can help
dictate QoS policies, provide useful information to the endpoints as to the
nature of the media flow at the remote end, etc.  The old class names that
existed were insufficient for describing the various types of traffic
flowing on the network.

Paul

From: Stephen Botzko [mailto:[email-masked]] 
Sent: Friday, July 29, 2011 10:07 AM
To: Paul E. Jones
Cc: James M. Polk; [email-masked]; Subha Dhesikan (sdhesika)
Subject: Re: [MMUSIC] New rev of the Traffic Class attribute draft

Hi Paul

Stephen Botzko

On Fri, Jul 29, 2011 at 9:46 AM, Paul E. Jones <[email-masked]>
wrote:

Stephen,

Paul

Stephen Botzko

MMUSIC

James, Paul & Subha