Subject: [Ieprep] Comments on draft-carlberg-ieprep-framework

From: [email-masked]
Date: Mon, 11 Mar 2002 12:33:51 EST

To all,

Some comments on details in the draft:

4.1.1 Current SIP (RFC2543) and its revision define only four levels. There 
is no "other-priority". (There was a new value proposed in an earlier draft, 
but this has been removed.)

The draft referenced for [15] has expired and does not represent current 
thinking. The information is now included in the new Resource-priority header 
defined in draft-polk-sipping-resource-00, February 2002. It would probably 
be advisable to add a new "namespace" for IEPS to that draft for the values: 
"authorized-emergency", "general-emergency", "high", and "normal". If not 
included in the draft, they would be added later through IANA.

At this point, it would be good to consider whether the possibility should be 
included for multiple levels of "authorized". (Note that the parallel work in 
SG16 on H.460.4 is leaning towards including such a capability.)

4.1.2 Diff-Serv

Since it is unlikely that a new class with 5 drop precedence values would be 
approved, the alternative is to add 2 values to one of the current classes, 
resulting in 5 ascending levels. The problem with either of these plans 
concerns the potential use of the existing 4 classes. As depicted in 
draft-baker-ieprep-requirements, an example of their use could be the 
following:

EF for voice, with signaling of bandwidth
AF4 for video, with signaling of bandwidth
AF3 for voice/video signaling
AF2 for transaction/ERP traffic
AF1 for traffic that will potentially move large volumes

In this example, there would need to be the 5 drop precedence levels for EF, 
as well as for each AF class, since eventually there should be a need to 
apply precedence type services to other traffic types besides voice. Clearly, 
there are not enough available DSCP code points.

The description at the end of the third paragraph relates the 5 drop 
precedence levels of a possible new class with the 3 levels of the existing 
ones. There is a confusion, first of all, in the numbers. RFC 2597 defines 
1=low drop precedence and 3=high. That means the emergency traffic would use 
the low numbers (1 or 2) to get a lower probability of packet loss. Secondly, 
the values assigned within one class can't be compared with those of another 
class. They are completely disjoint sets of values, since each class 
represents difference queues or traffic types. (As RFC 2597 states: "Packets 
in one AF class MUST be forwarded independently from packets in another AF 
class, i.e., a DS node MUST NOT aggregate two or more AF classes together.")

If a new class were defined with 5 levels, then, for other non-emergency 
traffic, "the lowest drop precedence they are assigned to is 3" and 
"Emergency traffic would be set to 2 or 1".

As described in draft-pierce-assured-service, the preferential treatment for 
Assured Service traffic needs to be provided by a combination of call setup 
priority and packet forwarding priority. Since the most important capability 
is provided by the call setup priority, the presently defined 3 drop 
precedence levels per class may be sufficient for packet forwarding 
preferential treatment, as shown in Annex A of that draft.

Mike Pierce
Artel

---

From: Fred Baker <[email-masked]>
Date: Mon, 11 Mar 2002 16:49:16 -0800

At 09:33 AM 3/11/2002, [email-masked] wrote:
>At this point, it would be good to consider whether the possibility should 
>be included for multiple levels of "authorized". (Note that the parallel 
>work in SG16 on H.460.4 is leaning towards including such a capability.)

are these "levels of authorization" or "kinds of authorization"? My 
experience with levels is that the discussion is always about winners and 
losers: "my stuff is more important than his stuff, so I think there needs 
to be another level."

What makes sense to me in SIP is a simple statement: "I assert that this 
call is an emergency call". If you are not authorized to make that 
assertion, the correct policy is to ignore the statement. If you are 
authorized, the network will have a policy to apply such as "permit this 
call even if we are well into the overload zone" or "drop a random call in 
order to complete this one." The network should determine the policy, not 
the standard.

>4.1.2 Diff-Serv
>
>[snip] In this example, there would need to be the 5 drop precedence 
>levels for EF, as well as for each AF class, since eventually there should 
>be a need to apply precedence type services to other traffic types besides 
>voice. Clearly, there are not enough available DSCP code points.

I think you have a very different understanding of diffserv than I do. When 
you talk about a drop precedence for EF (which doesn't have a drop 
precedence), what are you talking about - dropping packets, or dropping calls?

Recall that in GETS, you don't get differing qualities of circuits. You get 
differing probabilities of getting a circuit, but once you have a circuit, 
it is just a circuit and works exactly like any other circuit. In IP 
telephony, you might have varying call preferences, but once you decide to 
carry voice at all, EF is the service that carries voice. If you're trying 
to model GETS in IP Telephony, dropping packets makes no sense. Dropping 
calls might make sense.

So it's not in the least obvious where diff-serv fits here. Please advise?

>As described in draft-pierce-assured-service...

is that draft-pierce-sipping-assured-service-01.txt?

BTW, in view of RFC 2597 "Assured Forwarding PHB Group", which is often 
called "Assured Service", I'd personally appreciate it if you could find 
another name. My head snaps every time I hear the name :^)

_______________________________________________
Ieprep mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ieprep

---

From: Ken Carlberg <[email-masked]>
Date: Tue, 12 Mar 2002 12:40:29 +0000

hi,

> but this has been removed.)

thanks.  this will be updated accordingly.

> thinking. 

well, technically the old draft hasn't expired yet.  but the point
is taken that a new draft, under a new name, exists.  however,...

> The information is now included in the new Resource-priority header 

...this newer draft wasn't available when the Framework draft was 
submitted.  James and I will probably sit down and hash out some 
of the finer details next week.

> included in the draft, they would be added later through IANA.

the current Framework draft only recomends a single value be defined for
a new NameSpace to be associated with IEPS, and I prefer not to go
beyond this single value.  one reason is that this single value would
correlate nicely to a one-to-one association with the existing single
NS/EP code point in the ISUP/IAM message used for GETS in the U.S. PSTN.

the other reason is that the absence of any other value implies that the
default mode is an INVITE without the Resource Header value -- which is
what we have today (and which reflects the installed base of existing
implementations).  i'll add wording to this effect in the next version
of the draft to clarify this position.

> work in SG16 on H.460.4 is leaning towards including such a capability.)

given the reasons above, i'd rather stay away from multiple levels for
IEPS unless there is a very strong compelling reason not to.  the effort
in SG16 involves the introduction of a field that has room for expansion.
the Resource Header for SIP by James and Henning also allows for
expansion, albeit it in a different form.

> resulting in 5 ascending levels. 

your first contention is possible.  but i don't have much confidence that
your latter proposal would ever come to pass because it involves changes 
in specifying the existing classes of what AF, not to mention the domino
effect with existing implementations.  but i'll defer to Fred on his
view about the possibility of redefining existing classes of AF.

> The problem with either of these plans 
> apply precedence type services to other traffic types besides voice. 
> Clearly, there are not enough available DSCP code points.
>
> ones. 

ok, it seems you're mixing together two different and separate
"candidate recomendations" put forth in the draft.  i used the word
"candidate" as way of indicating ideas to be considered beyond what we
have now.  i didn't mean that they should be combined.  i'll add some
wording to make this more clear.

note, for those that haven't read this section, I also state that one
could use the existing mix of AF & EF code points to accomplish our
goals in the near term.  however, i think down the line there may be a
need to go beyond what we currently have (and the reasons for this are
in the draft, so as not to repeat myself here) -- hence, the candidate
recommendations.

> There is a confusion, first of all, in the numbers. RFC 2597 defines 

your statement above is correct: a different class is disjoint.  if a
single new class for AF were defined, one could potentially have the
following:

  AFx                               Ken's New Class
  ---                               ---------------
  High Drop Precedence = 3      ->  3 = High Drop Precedence
  Mid   "      "       = 2      ->  2 = Mid   "        " 
  Low   "      "       = 1      ->  1 = Low   "        "
                                ->  4 = Lower  Drop Precedence
                                ->  5 = Lowest Drop Precedence

there would be three levels in the new class; each correlating to the
same numeric value order as the current set of classes defined in AF.
there doesn't need to be a continuing ascending order of values for
adding types of precedence.

again, its just a candidate proposal and not to be treated as the only
one to consider.

> preferential treatment, as shown in Annex A of that draft.

agreed.  the Framework already draft states that for the time being we
can use the existing DSCP values.  i would add that one shouldn't get
too attached to always relying on a combination of EF and AF in cases
where diff-serv is supported because there may be providers that only
offer AF and Best Effort, and nothing else.  my hunch is that AT&T, who
recently announced support for diff-serv, only supports AF.

thanks for the feedback,

-ken