[Ieprep] Re: liason & the 5 priorities

[Curtis Villamizar <[e-mail]>]

In message <[e-mail]>
ken carlberg writes:
>  
> >   If there is an existing group that can extend a protocol or
> >   mechanism, IEPREP will generate only a requirements document for
> >   those groups to evaluate. If there is not an existing group that can
> >   extend a protocol or mechanism, IEPREP will prepare requirements and
> >   discuss the extension of that protocol/mechanism or
> >   protocols/mechanisms within IEPREP.
> >
> > This is a promise to liason with anybody and everbody that intends to
> > work in this area and to step back and let that other group do the
> > protocol work.  The IESG favors (with good reason) WG charters that
> > propose to do work rather than WG charters that propose to sit back
> > and watch the ITU do work in that area.  A good example (and closely
> > related to this sort of work) where the result coming from the ITU was
> > not at all useful is the ITU QoS requirements work in the mid to late
> > 1990s.  This may be looking too much like more of the same.
>  
> I don't believe the intention was for IEPREP to rubber stamp work  
> from other groups, and we can fix the passage to stress that IEPREP  
> would discuss and consider efforts from other groups.   I think there  
> is a bit more strength in having an existing set defined by another  
> group (and stronger if deployed), then in having a new set specified  
> from scratch.  Others may disagree.  But again, strength shouldn't  
> correlate to automatic acceptance.

Thanks.

btw- Defined for SS7 doesn't mean a good fit for SIP and IP.  Lets not
make others lack of foresight IETF's problem if it can be avoided.

> > As long as the number of priority/preemption classes remains too open
> > ended, the mapping onto DSCP and Diffserv-TE remains uncertain.  For
> > example, there has to be a strong technical justification for five
> > priority classes, not just "because ITU specified five" before there
> > is much of a chance for a set of new DSCP values to be assigned as
> > anything other than experimental.
>  
> yes, a good point.  one thing to take note of is that there are  
> several installed deployments of the "five" specified by ITU (and  
> other groups).  one example can be found in land mobile radio used by  
> first responders and specified by APCO on their Project 16 and  
> Project 25 efforts.  Another is the MLPP work from ITU and deployed  
> in systems like Autovon by DoD, NATO, and some others.  There is also  
> the "five" found in cellular networks in the UK and in WPS in the US.
>  
> In looking at these deployments, one will notice that the five are  
> pretty much in the form of role-based priorities, where the priority  
> is assigned based on the role of the user (executive leader,  
> battalion chief, etc).  Where older historic systems like Autodin  
> rely on content-based prioritization is based on the importance of  
> the content of the data being sent regardless of the role of the  
> user.  Its easier to implement role-based instead of content-based  
> prioritization.
>  
> There are some other examples, but a question arises of whether its  
> productive to have 5 pushed down into a one-to-one mapping at the IP  
> layer in the form of DSCPs given the limited number of bits to work  
> with.  One expired draft advocated this direct mapping, while  
> RFC-4542 makes an argument for a different approach.  In either case,  
> the headache is compounded if other organizations raise the number  
> from 5 to 7, 9, 15(?).
>  
> -ken

If priority and preemption can be accomplished at the admission level
(SIP and/or microflow RSVP level) then it may be that policing and the
existing EF is sufficient.  Its only where insufficient bandwidth is
allocated and carved into categories and adaptive elastic services are
carried is something like AF needed.  None of the above existing
examples fit the latter category.  It would be nice though if one more
first responder needed to communicate that flow was not blocked but
service quality for some dropped to a more efficient but slightly less
clear audio compression.  Currently that is not possible in any of the
above deployments (afaik).

The EF service is currently unused by most if not all providers.
Since policing and EF would work fine for a capability analogous to
existing services it may be a good start.  If there is a chance of
using an AF like class of service it would certainly be above and
beyond what is provided in PSTN or cellular and could start out as
experimental.  RFC4542 seems to discuss using EF but doesn't seem to
recommend this.

Curtis

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