Subject: RE: [Ieprep] requirements document(s) to SIPPING

From: "King, Kimberly S." <[email-masked]>
Date: Wed, 18 Sep 2002 09:48:06 -0400

[MAP] As I see it, pure "SIP bridging" is intended to pass things like
priority level transparently through SIP and prevents the use of this
information in providing preferential treatment within the IP world. I don't
believe this is sufficient to address the problem.

[KSK] Step 1 is to preserve what you have on the CSN. It doesn't
necessitate preferential treatment within the IP world but it doesn't
prevent it either.

In reviewing some prior messages to this list, it seems a great deal of
emphasis has been placed upon QoS so that packets associated with emergency
communications are less likely to be dropped during transport in the event
of congestion. This type of prioritization is in the realm of techniques
like DiffServ or RSVP and hence out of scope for SIP or SIPPING.

[MAP] This seems to be referring to packets transferring the user's
information, i.e., voice.

[KSK] No, prioritization in transport need not only apply to media (voice)
packets. For example, it is perfectly reasonable to mark signaling traffic
with a different code point than media packets and ensure each receives an
appropriate amount of queuing and scheduling resources. However, the point
I'm trying to make is that this is out of scope for the requirements
document for SIPPING.

[MAP] To get to an endpoint, the SIP messages would have to traverse the
same path as the media stream if there is only one path available. (Maybe we
have a different understanding of what a "path" is in this case.) The issue
of priority of SIP messages is not so much of one message having priority
over another, but how do you manage the relative priority of SIP (call
control) messages vs media packets that need to share the same bandwidth.

[KSK] This isn't what my comment referred to, but there are ways to handle
the problem you mention by using DiffServ, for example see the above
comment.
So, what SIP proxy server prioritization could do is possibly help a server
decide which message requests in setting up sessions should be preferred.

[MAP] There should not be any prioritization of SIP messages, in the sense
of either sending or processing one before the other, since this just makes
the out-of-order problem more serious. As I suggested in
draft-pierce-pref-treat-examples.00, there may be utility in applying
different drop precedences to various SIP (call control) messages, just as
was done in ISUP, in order to deal with congestion in whatever path is used
to transfer these messages. However, if these messages are sharing a
transport path with media streams, it is probably always better to send the
messages and drop some media packets.

[KSK] The potential prioritization of messages within a SIP proxy isn't
related to the transport of signaling messages and their possible
co-existence with media packets on some congested path. The potential
prioritization of SIP messages is something that would occur after routing
has delivered the SIP messages to a SIP server. What is at stake is what
happens at a SIP server. In any event, the point is that we have our hands
full in achieving step 1 and 2 before tackling this one.

[MAP] The above seems to be talking about the Call Control messages, not the
media stream.

[KSK] Yes, that is what I am talking about.

[MAP] Priority treatment (or drop procedures) for call control messages
needs to be defined, but it is not the problem mentioned above. If the
setup (INVITE) is marked somehow for distinct priority treatment, the
responses to that INVITE could use the same treatment. This is not
"transferring the priority to the callee".

[KSK] Let's imagine SIP proxies prioritize messages. Then this is what I
mean by "transferring priority"...Imagine a high ranking official makes a
"flash" call to a low ranking one. That high ranking official is authorized
to send INVITES (and other messages) at "flash" level. Now the call setup
in the other direction will also have SIP messages associated with it. But
the low-ranking official isn't really authorized to make "flash" calls.
Instead, the priority of the SIP messages that are sent, if they also are to
be sent at "flash" must have been transferred by virtue of who was calling.
We have just described the same thing. I called it transferring the
priority to the callee and you called it "just use the same treatment". So,
independent of what you call it, it is complicated.

[MAP] I believe that consideration of "priority" of media stream packets
must to included, where "priority" really refers to "preferential treatment"
of one voice packet over another.

[KSK] This is not a SIP issue. This might be something to talk about later
but now we need to focus on requirements specific to send to SIPPING.  

Kimberly

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Tuesday, September 17, 2002 3:38 PM
To: [email-masked]; [email-masked]
Subject: Re: [Ieprep] requirements document(s) to SIPPING

In a message dated 9/17/2002 8:21:14 AM Eastern Standard Time,
[email-masked] writes: 

Recall that we need to get requirements document(s) to SIPPING.  I would 
like us to focus on the VoIP scenario with SIP for a moment with the 
scenarios of IP to Circuit-Switched Network (CSN), CSN to IP to CSN (SIP 
bridging), or CSN to IP.  Where it makes sense, we can also consider other 
real-time SIP sessions such as instant message or conferencing. 

One could examine this in stages: 

1. Preserve any priority scheme in the CSN when applying SIP bridging 

This would prevent loss of information in the CSN.  It might also make sense

to limit this case to where both CSN's use the same priority scheme (e.g., 
suppose CSN 1 is employing MLPP.  Then MLPP information is presented in full

to CSN 2 but there is no attempt in the IP network to translate MLPP into a 
different priority scheme). 

Question for WG:  Can this be done with existing RFCs or new drafts?  Are 
there any specific security or other requirements in this case?

[MAP] For support of "MLPP" in the "SIP Bridging" case, it makes sense to
assume that both CSNs use the same priority scheme, since there is an
international standard for this. However, one can not assume that both CSNs
use the exact same ISUP. While existing RFCs/drafts would support the "MLPP"
parameters, they do not support the interworking of slightly different ISUP
versions. But that is not for IEPREP to solve. 

For other priority schemes (e.g., emergency service) there may not be an
exact match between two networks nor does there need to be. One or the other
gateway must provide interworking (mapping) between two different sets of
priority values, just as the interworking point between two different ISUP
versions today might have to map some parameter which is not fully
compatible. That mapping in the SIP gateway is part of the ISUPside of the
implementation and thus not of direct concern here (in the "SIP Bridging"
case). 

The security requirement for the bridging case is really no different for
"MLPP" or other priority services. It must be solved for regular call setup,
that is, the egress gateway must verify that the call it is asked to send
back into the CSN came from a legitimate originator (whether ingress gateway
or another SIP user). 

As I see it, pure "SIP bridging" is intended to pass things like priority
level transparently through SIP and prevents the use of this information in
providing preferential treatment within the IP world. I don't believe this
is sufficient to address the problem. 

2. Introduce priority scheme at SIP endpoints (e.g., SIP user agents, 
gateways, media servers). 

This would allow new optional functionality such as providing emergency 
users preferred access to gateway or media server resources, allowing 
preemption to occur at endpoints, etc.  This option increases complexity and

has security issues that will also need to be addressed. 

Questions for WG:  What are the requirements for these endpoints?  Would a 
SIP endpoint be required to determine what priority scheme(s) a gateway 
employs?  Would the gateway be required to communicate the security 
information it must have before allowing priority access to resources?  

[MAP] It certainly would not be good if an endpoint (originating a call)
needed to know anything about a gateway that might be used to get the call
into the PSTN. 

3. Introduce priority of SIP messages within SIP proxy servers. 

This would allow certain SIP messages to have preferred treatment over other

messages.  Now on the surface, it might seem like this kind of preferred 
treatment addresses one of the working groups expressed concerns - 
congestion.  However, there are different types of congestion.  

[MAP] This seems to be referring to treatment of the SIP messages used for
call control. See notes below. 

In reviewing some prior messages to this list, it seems a great deal of 
emphasis has been placed upon QoS so that packets associated with emergency 
communications are less likely to be dropped during transport in the event 
of congestion.  This type of prioritization is in the realm of techniques 
like DiffServ or RSVP and hence out of scope for SIP or SIPPING.  

[MAP] This seems to be referring to packets transferring the user's
information, i.e., voice. The issue with QoS (and dropping) should not be
viewed as giving the emergency call "better" QoS. They need the normal QoS,
and can even tolerate worse if needed to get the call through. My
suggestions of a preferential treatment in the case of congestion was to
first drop media packets for the lower priority call so that it gets worse
QoS. If it gets too bad, the parties will hang up, thereby freeing up the
resources for the higher priority calls. (This also presumes sufficient CAC
to prevent the lower priority call from being immediately reconnected.) 

The priority of SIP messages within SIP proxy servers isn't likely to 
address the transport congestion issue-SIP proxies typically don't have 
knowledge of QoS resources and SIP messages don't typically traverse the 
same path as the media streams.  The congestion with respect to gateway or 
other endpoint resources has been handled in 2 above.  

[MAP] To get to an endpoint, the SIP messages would have to traverse the
same path as the media stream if there is only one path available. (Maybe we
have a different understanding of what a "path" is in this case.) The issue
of priority of SIP messages is not so much of one message having priority
over another, but how do you manage the relative priority of SIP (call
control) messages vs media packets that need to share the same bandwidth. 

So, what SIP proxy server prioritization could do is possibly help a server 
decide which message requests in setting up sessions should be preferred.

[MAP] There should not be any prioritization of SIP messages, in the sense
of either sending or processing one before the other, since this just makes
the out-of-order problem more serious. As I suggested in
draft-pierce-pref-treat-examples.00, there may be utility in applying
different drop precedences to various SIP (call control) messages, just as
was done in ISUP, in order to deal with congestion in whatever path is used
to transfer these messages. However, if these messages are sharing a
transport path with media streams, it is probably always better to send the
messages and drop some media packets. 

It was pointed out in the joint IEPREP-SIPPING meeting in Yokohama, that SIP

proxies are fast and prioritizing the individual handling of messages may 
have limited value.  SIP proxies must also be DOS resistant.  Also recall 
that there are many SIP requests per session and they occur in both 
directions.  Suppose a caller with priority calls a caller with regular 
capabilities.  SIP proxies will send setup requests in both directions. 
Would one want priority treatment of exclusively the direction from the 
priority user to the regular one?  If not, there will be additional 
complexity and security concerns in "transferring" the priority of the 
caller to that of the callee.  There is also complexity in checking requests

have the necessary authentication per SIP message, per SIP proxy over 
possibly different security domains.  This is a formidable problem for a 
feature whose utility has already been questioned (see 
http://www.softarmor.com/sipping/meets/ietf54/slides/ieprep-sipping-joint.pp

t ).

[MAP] The above seems to be talking about the Call Control messages, not the
media stream. Priority treatment (or drop procedures) for call control
messages needs to be defined, but it is not the problem mentioned above.  If
the setup (INVITE) is marked somehow for distinct priority treatment, the
responses to that INVITE could use the same treatment. This is not
"transferring the priority to the callee". 

Media flow is a different case. In all discussions of priority services, it
has been assumed that the originator of the call determines the priority
level or treatment desired. If the level or treatment is allowed, it must
apply to the media flow in both directions, so the callee must be given the
"authorization" to send voice packets at the higher level. There is no case
that I know of in which the choice of priority is also dependent on the
capabilities of the called party. 

I suppose one could define a service in which a call made by a regular
caller becomes "priority" when it reaches the destination (e.g., call to a
police station, not 911), but I don't believe there has been any suggestion
for this. However, it would still need to affect media flow in both
directions. 

Given the above and our tight deadlines, I am going to suggest we first 
focus on the requirements for 1 and 2 above.

[MAP] I believe that consideration of "priority" of media stream packets
must to included, where "priority" really refers to "preferential treatment"
of one voice packet over another. For SIP (call control) messages, I believe
that "priority" should also be considered, that is, preferential treatment
of one type message over another. 

The difficult part is the consideration of preferential treatment of voice
packets vs SIP messages. But without consideration of this issue, we could
end up with a perfect system that passes the voice packets for the high
priority call over those of the low priority call, but is unable to pass the
call setup messages to establish a new high priority call or to release an
existing low one. 

Granted, this final item is not something that SIPPING needs to directly
deal with, but it needs to be considered in Requirements. Although the
actual procedures to apply preferential treatment at the packet level are
not in SIP, there may be a need to carry specific information in SIP to
allow it to happen. 

Kimberly 

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

---

From: Henning Schulzrinne <[email-masked]>
Date: Wed, 18 Sep 2002 10:46:52 -0400

> independent of what you call it, it is complicated.

Actually, it's pretty trivial. The logic is simple:
- for each request, see if it belongs to an existing dialog or is a 
high-priority authenticated request
- if not either of these, either drop (if no space in queue) or put on 
lower-priority queue or perform other treatment

Most of the heavy-duty work in a SIP server happens *after* the 
classification of the request.

However, this is something any competent implementor of a resilient 
server can (and will) do without the aid of the IETF. That implementor 
will have to write similar code to deal with DOS attacks, where certain 
requests will also need to be treated with preference, namely requests 
that have been authenticated and responses within existing dialogs. Both 
are much less likely to come from the attacker.

In other words, this is probably not a protocol issue, even if some of 
the protocol mechanisms that may get designed may end up being useful 
for smart queue management.

Henning