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

From: Henning Schulzrinne <[email-masked]>
Date: Tue, 01 Oct 2002 14:42:09 -0400

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

I believe this can be done with existing drafts, such as the R-P 
document. It could also be done with ISUP bridging, but that assumes 
that both sides use ISUP and the same version of it. RFC 3372 describes 
this architecture in some detail.

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

I believe the security issues aren't all that different than those we 
already face - you need to prevent unauthorized access. I don't see how 
this increases protocol complexity. It may increase implementation 
complexity slightly, but many existing media systems already have 
priorities of one sort or another. Maintaining two (or more) queues 
instead of one isn't terribly challenging for an application, 
particularly if you don't do preemption. The pseudo is nothing but

if (incoming request has high priority)
    insert into queue1
else
    insert into queue2

and

if request is done
   pick next from queue1
   if empty, pick next from queue2

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

I'm confused by your distinction. A gateway *is* a special case of a SIP 
endpoint. (I'm treating a decomposed MG/MGC as a logical gateway here.) 
The gateway or, in case of a decomposed version, the MGC, speaks SIP.

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

Very much so.

> 
> 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.  
> 
> So, what SIP proxy server prioritization could do is possibly help a server
> decide which message requests in setting up sessions should be preferred.
> 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

This is not generally true. While SIP proxies *can* be fast, they often 
execute a significant amount of logic. One can usefully think of a SIP 
proxy as having some of the same properties as a web server. A web 
server can be very fast if all it does is serve static pages, but can 
take significant amounts of time to process cgi, servlet or similar 
requests. SIP servers can do the same type of processing - indeed, the 
mechanisms such as servlets and cgi are effectively the same in SIP and 
HTTP servers. Just as for web servers, services may be created by users 
and may very significantly in complexity. For example, they can include 
database accesses ("Is this person on the telemarketer list?" "Does this 
person making an outbound call have enough credit left?"). Some people 
don't just want to replicate the phone system in SIP :-)

Thus, a very reasonable mechanism for a robust server is to say 
"priority calls don't get to do cgi stuff".

That said, my perception is that whether we say anything about this or 
not, implementors can use the same techniques we specify for bridging or 
gateway resources to do resource priorities within a proxy. This is not 
something we need to specify since it is a matter of product 
differentiation. It is not externally visible, except possibly as a 
crashed server.

> 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

This sounds complicated, but is a red herring. You already need to match 
up requests with each other and with responses. (Among other reasons, to 
detect retransmissions and to deal with state at the cgi and servlet 
level.) Thus, this is in effect a freebie - if a request from A to B had 
priority, the response from B to A will be associated with that and can 
easily get the same treatment. (Systems that I'm familiar with already 
treat responses to existing requests with priority, since they help 
clean out work and avoid having a lot of half-completed requests hanging 
around and timing out.) Association is via a hard-to-fake 
cryptographically random identifier used as the hash key.

To be sure, this does not cover all cases. For example, for 
call-stateless proxies, mid-call requests from a low-privilege callee to 
the high-privilege caller will not be prioritized, in all likelihood. By 
definition, the call is already up at that time, so this is probably 
less of an issue in any event.

With a few exceptions in special cases (COMET comes to mind), call setup 
has requests only going from caller to callee.

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

See above. I think this is largely an implementation issue which we can 
safely ignore since everybody will have a different notion what their 
proxy is doing or not doing. Smart implementors will ignore the slides 
and build robust systems; dumb implementors will tell their boss that 
the IETF said this can't be done :-)

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

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

---

From: "King, Kimberly S." <[email-masked]>
Date: Fri, 11 Oct 2002 06:14:22 -0400

"I could see that becoming an interesting discussion point as to if the
higher
queue priority is an absolute (one never serves an n-1 queue if there is
an
entry in the n queue) or relative (after serving a handful of n queue
entries,
we serve 1 from the n-1 queue. This could be recursive.)"

Yes, interesting policy but we should focus on requirements, rather than
neat ways to schedule resources.  

-----Original Message-----
From: Stuart (Stu) Goldman
To: Gunn Janet
Cc: 'Henning Schulzrinne'; King Kimberly S.; Ieprep (E-mail)
Sent: 10/10/2002 4:28 PM
Subject: Re: [Ieprep] requirements document(s) to SIPPING

Janet,

I think you are right that it can become more complex very easily if one
adds
factors such as time in queue, etc.  I have seen systems that work from
the
highest priority queue but every so often visit the lower priority ones
so that
they are not completely denied service.

I could see that becoming an interesting discussion point as to if the
higher
queue priority is an absolute (one never serves an n-1 queue if there is
an
entry in the n queue) or relative (after serving a handful of n queue
entries,
we serve 1 from the n-1 queue. This could be recursive.)

"Gunn, Janet" wrote:

> -----Original Message-----
> From: Henning Schulzrinne [mailto:[email-masked]]
> Sent: Tuesday, October 01, 2002 2:42 PM
> To: King, Kimberly S.
> Cc: Ieprep (E-mail)
> Subject: Re: [Ieprep] requirements document(s) to SIPPING
>
> ...
>
>  Maintaining two (or more) queues
> [JPG] Agree that a simple set of multiple FIFO queues is "easy".
However,
> when there is a desire (based on business considerations) to "give
priority
> if there are only a few of them, but not let them take over
everything", the
> logic can become quite tortuous.  So, in making decisions, it is not
safe to
> ASSUME a simple queue logic.
>
 <<Card for Stuart (Stu) Goldman>> 
_______________________________________________
Ieprep mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ieprep