Keith,
I agree with your assessment, there is little benefit and several
drawbacks in adding a Resource-Priority header to responses.
- for proxies there is no benefit in processing one response before
another (at least of the same type, i.e. INVITE or non-INVITE) that was
received earlier. Both free up memory resources, take about the same CPU
time and prevent retransmissions in the same way, so all other things
being equal FIFO processing is preferable (because statistically it
avoids more retransmissions and achieves a lower memory*time product)
- dropping non-provisional responses is a bad idea, especially in overload
- queuing such responses for too long: idem
One could perhaps argue that provisional responses could be treated with
lower priority than final responses, but if so this is better
implemented as a local policy; no need to mark individual responses for
this.
Some additional points:
- responses cannot be challenged, so responders could claim any priority
they feel appropriate
- a R-P header would add quite some bytes to the response size, filling
the network buffers sooner which makes overload situations worse
- is there / should there be a relationship between the priority of the
request and that of its associated responses? if so, the proxy has
better ways of achieving this (i.e. encoding an integrity protected
value in the request, no need for standardization here)
Regards,
Jeroen
DRAGE, Keith (Keith) wrote:
(As WG chair)
Dean attempted to get this one started a while back and it fell on stony
ground.
We have now set charter milestones for all the documents we agreed to
progress at the last IETF meeting except for the draft above.
The reason for this absence is that after discussion with the AD, we are
not convinced that doing this provides a significant benefit. Part of
this may be clarified by revising the draft as an author draft but...
The essence of the problem is that the application is to that of a
transaction stateless proxy. Of the list of activities specified by RFC
4412:
1. The request can be given elevated priority for access to PSTN
gateway resources, such as trunk circuits.
2. The request can interrupt lower-priority requests at a user
terminal, such as an IP phone.
3. The request can carry information from one multi-level priority
domain in the telephone network (e.g., using the facilities of
Q.735.3 [Q.735.3]) to another, without the SIP proxies themselves
inspecting or modifying the header field.
4. In SIP proxies and back-to-back user agents, requests of higher
priorities may displace existing signaling requests or bypass
PSTN gateway capacity limits in effect for lower priorities.
The only reason for including a Resource-Priority header in a response
for use in a transaction stateless proxy is item 4 above. This means
that a response for (namespace x, priority 5) could be handled ahead of
a response for (namespace x, priority 4).
The question is what is the impact of such handling on an overloaded
system, where such priority handling could have a benefit (we assume
that in a system that is not overloaded then responses can be pushed
back pretty much as fast as they are received). If a response processing
gets delayed according to some queueing mechanism, then eventually
timers related to the request at the entity before this proxy will time
out, and the request will be repeated. This increases the processing
load on an overloaded system.
So in terms of resource priority, is the appropriate model that
responses should always be handled immediately and before the request
queues are handled, or is there a justification for some other model.
Please respond and tell us we have got it wrong.
Regards
Keith
_______________________________________________
Sip mailing list https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [EMAIL PROTECTED] for questions on current sip
Use [EMAIL PROTECTED] for new developments on the application of sip
_______________________________________________
Sip mailing list https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [EMAIL PROTECTED] for questions on current sip
Use [EMAIL PROTECTED] for new developments on the application of sip
