Re: [Sip] -resource-priority-05.txt: Comments and Recommendations (3)

In a message dated 11/11/2004 6:12:39 PM Eastern Standard Time, 
coreya@nortelnetworks.com writes:

> 3. With "preferential treatment" of messages based on R-P content, 
> should not scenarios be considered and listed in which a lower priority 
> message  would need to be handled before a higher priority message?  My 
> example: it would be wise to handle a BYE message with dsn.routine 
> before an INVITE with dsn.flash-override...  At least in certain 
> situations, say when the BYE is sent as a result of a preemption event 
> (which the Reason header should likely indicate).
> ---- Certainly something to consider, especially for DSN.
> 

Yes, this is an interesting idea. However, as in the SS7 world, it is a bad 
idea to intentionally do things that might change the sequence of messages. In 
the example you mention, I would expect that some entity controlling 
preemption would simply send the BYE for the routine call before it sends the INVITE 
for the new flash-override call. If two different entities send these two 
messages, it is a virtually non-existent case that both messages would happen to be 
in the same queue waiting to be sent to even allow some entity to reorder them.

What sometimes confuses this issue is what is done in SS7 (see 
draft-pierce-tsvwg-pref-treat-examples-01). SS7 has a "congestion priority level" associated 
with each signaling message, which is really a discard priority. Some 
(including me) have been confused into thinking that it changed the order to 
transmission, by sending the higher priority messages first. It does not. For the SS7 
messages corresponding to BYE and INVITE and for routine and high priority 
calls, the congestion priority leveI defined for SS7 (and the corresponding SIP 
message) are as follows:

IAM (INVITE) (routine)  0
IAM (INVITE  (priority) 1 or 2
REL (BYE)    (all)      1

This means that, if the signaling system 7 network gets congested, the new 
call setup messages (IAM) for routine calls are the first to be discarded (which 
helps to prevent catastrophic overload).

The draft mentioned about only raised this issue as something to consider to 
provide "preferential treatment" for the various signaling messages, as you 
suggested in your question. But I would only see it as being similar to the SS7 
implementation - determining which messages to discard when you have to 
discard something, not changing the order. It could use AF behavior with 3 drop 
probabilities.

My initial belief is that such a mechanism is not needed, presuming that 
other techniques can ensure the the SIP signaling traffic will never get to the 
congestion point. If not, then I think we need to consider such a mechanism, but 
it's not something that needs to be described in the R-P header draft.

Mike Pierce
Artel