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

From: [email-masked]
Date: Tue, 12 Mar 2002 11:08:24 EST

In a message dated 3/12/02 7:40:54 AM Eastern Standard Time, 
[email-masked] writes:

> hi,
> 
> > 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.
> 
> 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.
> 
I thought your draft was proposing two values: "authorized-emergency" and 
"general-emergency".

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

But the absence of a value has to default to something. Text is being added 
to the Resource-priority draft to indicate that one of the defined values 
needs to be specified as being the default. So, in addition to the defined 
levels, there needs to be a "Normal" level defined, even if it is never 
signaled.

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

The effort in SG16 seems to be allowing for expansion, but it isn't clear to 
me yet from their drafts how such expansion would occur.
Right now, the Resource-header draft is not allowing expansion within a 
defined namespace.
I thought previous discussions on this subject identified the need to 
identify various users for possible multiple levels. The MLPP model for the 
similar service uses 5 levels: Routine, and 4 "emergency" levels.

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

Yes, I suspect what you said is true - changes to existing AF definitions, 
even if simply two new drop precedence levels for one of the classes ("very 
low" and "very high"?) might be very difficult. But my comment (as in 
draft-pierce-sipping-assured-service) is that 5 levels is probably unecessary.

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

Yes, that's possible, I just dodn't think that a non-consecutive numering 
would be a good idea. Hard for my brain to deal with, anyway. How about 4 = 
higher and 5 = highest.
> Mike Pierce

---

From: Ken Carlberg <[email-masked]>
Date: Tue, 12 Mar 2002 16:58:37 +0000

> I thought your draft was proposing two values: "authorized-emergency" 
> and "general-emergency". 

yes, originally i did.

> But the absence of a value has to default to something.

correct.  and it seems that it will be helpful to add text about this
in the Framework draft.

> Text is being
> added to the Resource-priority draft to indicate that one of the defined 
> values needs to be specified as being the default. So, in addition to
> the defined levels, there needs to be a "Normal" level defined, even if
> it is never signaled. 

my assumption was that the text you speak of was in relation to the 
example DSN NameSpace.  Otherwise, the Resource Header draft is 
implicitly requiring that any defined namespace must have at least 2 
values.  i'd prefer not to see that constraint in there.

> The effort in SG16 seems to be allowing for expansion, but it isn't clear
> to me yet from their drafts how such expansion would occur. 

a fair assessment.  i don't know how ITU documents are structured.
perhaps one needs either an appendix that defines the format of the
values stored in the 'emergency' related field, or a subsequent document
needs to be written with the explanation.  i'll ask the fellows putting
it together.

> Right now, the Resource-header draft is not allowing expansion within a 

this is probably a question to James and Henning, but couldn't one
define a new NameSpace?  like MLPPv2, or extended-MLPP?

> identify various users for possible multiple levels. The MLPP model for
> the similar service uses 5 levels: Routine, and 4 "emergency" levels.

the 5 levels that have been discussed are strictly for MLPP.  I may have
introduced confusion by trying to have IEPS be symbiotic with MLPP.  so
I may go back and add some clarity in that regard to the Framework draft.

> even if simply two new drop precedence levels for one of the classes 
> ("very low" and "very high"?) might be very difficult. But my comment 
> (as in draft-pierce-sipping-assured-service) is that 5 levels is probably 
> unecessary. 

ok, i think i understand.  it could be the existing 3 + 1 additional one
for IEPS.  but in the end, its mostly a trial balloon of an idea.

> would be a good idea. Hard for my brain to deal with, anyway. How about 
> 4 = higher and 5 = highest. 

something to consider.

cheers,

-ken

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