Subject: [MMUSIC] Traffic Class Labels and classes

From: "Paul E. Jones" <[email-masked]>
Date: Fri, 24 Feb 2012 12:58:43 -0500

Folks,

We have a draft that describes Traffic Class Labels (TCL) for SDP:

http://tools.ietf.org/html/draft-ietf-mmusic-traffic-class-for-sdp-00

The syntax for the TCL is basically:

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

The admitted and non-admitted part on the end is an admission qualifier.  I
was asked a couple of questions:

1)      Is there any reason to require the admission qualifier on the end?

2)      What if there is no admission qualifier or if we want to introduce
other values?

The admission qualifier does not necessarily have to be at the end, but it
is called out specifically since it is a class of adjectives for which we
have defined values and we want to be able to quickly identify.

It was suggested that perhaps we actually consider grouping adjectives into
classes.  The admission qualifier is just one class of adjectives, after
all.  I like the idea, since it would allow an application to quickly
identify a type of adjective, even if it does not understand what the
adjective value is.

The class concept would use a syntax like "classname:adjective".  For the
admission qualifier, we might use "aq".  So, an example TCL might be:

   Conversational.video.alpha.beta.aq:admitted.gamma

I would like to hear others' opinions on use of classes to logically group
adjectives.

We would want to keep classless adjectives, too.  So, the modified syntax
would be roughly:

  parent "." application *("." [class] adjective)

Comments?

Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 24 Feb 2012 15:15:26 -0500

I just got around to taking a look at this draft.

I noted the following while reading it:

- is this only for RTP? I presume not. Presumably it includes all sorts 
of traffic. So why don't I find anything for much common traffic, such 
as browsing and file transfer, backup, ...? Of course many of those are 
not typically described in SDP, which might explain it. What traffic 
class would you recommend for a SIMPLE session to be used for a file 
transfer?

- it sounds like there may be a variety of places where these traffic 
class labels might be used. I think it would be wise to separate the 
definition of the labels themselves from any particular use, such as in 
SDP. (One RFC for the definition of syntax of the traffic class label 
itself, and the IANA registration of the initial values. A different RFC 
for the SDP trafficclass attribute.

- The "Multiplex" application seems to be sweeping a major issue under 
the rug. There are now a lot of plans to multiplex many RTP streams on a 
single RTP session. (Sorry if I have that terminology wrong.) This is 
showing up in at least RTCWEB and CLUE. This is likely to evolve into a 
lot of traffic. Its likely that there will need to be a way to describe 
traffic class at a finer granularity than a port.

- the parent, application, and adjective definitions seem to be very 
subjective. Its far from clear that two people would choose the same 
ones to describe a particular class of traffic.

- the cac-class is hacked into the syntax. It might be better if it were 
distinguished more clearly - perhaps using a distinctive syntax. (And I 
see that Paul J is proposing something for that.)

- the restriction to one traffic class per m-line seems problematic for 
rtp sessions that are multiplexed. This could be addressed by allowing 
traffic classes to be specified per SSRC. (An alternative is to use the 
proposed Bundle mechanism to allow more than one m-line for the same 
port. But its not clear if that is sufficient.)

- another issue about making this per-m-line is: what about the traffic 
class of the RTCP session? Is there a need to describe it too?

- it seems highly likely that additional app-types and app-params will 
eventually be defined. This will probably require use of IANA 
registries. Assuming that, I suggest it would be advisable to take the 
initial set of names out of the ABNF and instead put them into IANA 
registration templates.

- non-standard adjectives require careful thought, because they can 
cause interop problems. What is to prevent two unrelated organizations 
from using the same non-standard adjective to mean two different things. 
An alternative would be an IANA registry with a low bar for additions.

- I don't understand why the cac-class must be last. Seems very arbitrary.

- section 4.1 Offer Behavior

    Offerers of this 'trafficclass' attribute MUST NOT change the label
    in transit (e.g., wrt to B2BUAs).  SBCs at domain boundaries can
    change this attribute through local policy.

This is unclear. Can you try again? Which things cannot change the 
label? ISTM that anything that terminates the media and then 
reoriginates it should be able to change the value.

- section 4.2

I'm not at all sure of this, but I *think* this is telling me that the 
traffic class in the offer/answer describes the characteristics of the 
data the offerer/answerer will *receive*. This means that neither side 
has a way to describe the characteristics of the traffic it plans to 
send. Is that sufficient?

	Thanks,
	Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 24 Feb 2012 15:35:32 -0500

> We have a draft that describes Traffic Class Labels (TCL) for SDP:

I just posted some comments on the draft.

> parent “.” application *(“.” adjective) “.” (“admitted” / “non-admitted”)
>
> The admitted and non-admitted part on the end is an admission qualifier.
> I was asked a couple of questions:
>
> 1)Is there any reason to require the admission qualifier on the end?
>
> 2)What if there is no admission qualifier or if we want to introduce
> other values?
>
> The admission qualifier does not necessarily have to be at the end, but
> it is called out specifically since it is a class of adjectives for
> which we have defined values and we want to be able to quickly identify.

Its far from evident that putting it at the end makes it quicker to 
identify.

If it is really different from an adjective, then it might be helpful to 
syntactically distinguish it. Putting it at the end is one way. What you 
suggest below is another. We can find others. But first we should figure 
out if it really is different from an adjective, or if it is simply an 
adjective that is of more general interest than most.

One difference might be how its registered. Apparently the admission 
qualifiers apply to all parents and applications, while maybe (I'm not 
certain) adjectives need to be registered separately for each 
parent+application combination they are valid with.

> It was suggested that perhaps we actually consider grouping adjectives
> into classes. The admission qualifier is just one class of adjectives,
> after all. I like the idea, since it would allow an application to
> quickly identify a type of adjective, even if it does not understand
> what the adjective value is.

This seems interesting. But only if the significance of a class can be 
nailed down. Perhaps my musing above relates to this:

If adjectives are gathered into classes, then maybe the registration of 
an application could specify the classes that are relevant to it, rather 
than the specific adjectives. All adjectives from any of the allowed 
classes would then be permitted.

> The class concept would use a syntax like “classname:adjective”. For the
> admission qualifier, we might use “aq”. So, an example TCL might be:
>
> I would like to hear others’ opinions on use of classes to logically
> group adjectives.

Is it necessary to actually code the adjective class in the name? It is 
if the same adjective names can be used with differing meanings in 
different classes. But if you require all adjective names to be unique 
regardless of class, then you don't need to encode the class name.

The class concept might also be a way to deal with non-registered 
adjectives.

> parent “.” application *(“.” [class] adjective)

Maybe rather than classless adjectives, how about a default class. That 
way all adjectives would have some class, which would be useful in IANA 
registration templates, documentation, etc.

	Thanks,
	Paul

---

From: "Paul E. Jones" <[email-masked]>
Date: Sun, 26 Feb 2012 16:48:06 -0500

Paul,

> Its far from evident that putting it at the end makes it quicker to

Programmatically, it is. That was part of the reason we specified it this
way.  One would not have to inspect the actual values of adjectives: just
jump to the end and you'd find the admission qualifier.
 
> adjective that is of more general interest than most.

It isn't different from other adjectives.  This is why it was suggested we
change the syntax.  It was also argued that some labels may not have an
admission qualifier, so it should not be required.  So, it now becomes an
adjective that is no different than any other.
 
> parent+application combination they are valid with.

That was our initial thinking, but we got push back on that.  However, I
think we can have our cake and eat it too by using classes.  The adjective
is placed anywhere, yet still quickly identified -- even if not understood.

> If adjectives are gathered into classes, then maybe the registration of an
> application could specify the classes that are relevant to it, rather than
> the specific adjectives. All adjectives from any of the allowed classes
> would then be permitted.

I think we would need to specify both.  However, I believe it's really the
other way around.  A class or adjective that we define and register should
indicate what categories and applications to which it is relevant.  After
all, we will introduce new adjectives and new classes as we go forward.  As
those are registered, we should not have to update the category or
application registrations.
 
> > The class concept would use a syntax like "classname:adjective". For
> > the admission qualifier, we might use "aq". So, an example TCL might be:
> >
> > I would like to hear others' opinions on use of classes to logically
> > group adjectives.
> 
> Is it necessary to actually code the adjective class in the name? It is if
> the same adjective names can be used with differing meanings in different
> classes. But if you require all adjective names to be unique regardless of
> class, then you don't need to encode the class name.

Including the class name allows us to quickly identify adjectives of a
certain class, even if the adjective itself is not understood.  It would
also allow the same name to be used in two different classes.  This might be
useful, though I do not have a good example right now.

> > We would want to keep classless adjectives, too. So, the modified
> > syntax would be roughly:
> >

Classless, no class, or "default" class -- does not matter to me.  I just
think we need to allow some adjectives to be defined that are not part of a
specific class.

Paul