RE: [Sipping] Congestion Header

[Janet P Gunn <[e-mail]>]

"Emergency"
It is my understanding- based on emails and discussion at the IETF meeting-
that REQ 13
    " REQ 13: The mechanism must allow a proxy to prioritize requests, so
that
     certain ones, such as call for emergency services, are still
processed."
was intended to allow the proxy to prioritize requests based on any
criteria chosen by the network operator.  Emergency calls (both ECRIT-type
emergency calls and ETS-type emergency calls) are presented as an example,
but such prioritization could be based on many other criteria.

 For instance, a plausible congestion policy would be to prioritize so that
all messages associated with a session establishment "in progress" are
still processed, but  other messages (e.g. REGISTER, INVITE) are blocked.


Trunk congestion-
This may just be my lack of SIP expertise, but I am a little bit confused
by the use of this congestion header to indicate  a trunk group utilization
level (at a TDM gateway).

In 4412 it says:
   "If there is not enough bandwidth, or if there is an insufficient
   number of trunks, a 488 (Not Acceptable Here) response indicates that
   the RP actor is rejecting the request due to media path availability,
   such as insufficient gateway resources.  In that case, [RFC3261]
   advises that a 488 response SHOULD include a 'Warning' header field
   with a reason for the rejection; warning code 370 (Insufficient
   Bandwidth) is typical."

Is the congestion header intended to replace the 488 response, or is it
intended to convey additional information (beyond that provided by the 370
warning code) in the 488 response.

Congestion levels

You have specified a large number of "congestion levels"

CPU                    0, 1, 2, 3, 4
Application:      0, 1, 2, 3, 4
Network:            0, 1, 2, 3, 4
Memory:            0, 1, 2, 3, 4
Disk:                   0, 1, 2, 3, 4
TG:                      0, 1, 2, 3, 4
(General)           0, 1, 2, 3, 4

This seems more specificity than is needed.  When a device is severely
congested, it usually isn't a good idea to spend precious resources
calculating the utilization of each aspect of the system.  Most of the
(proprietary) congestion notification systems that I am familiar with use a
single easily computable overall level of congestion, such as the lengths
of specific internal queues, or the X%ile of time in (internal) queue (both
subject to hysteresis).  The recipient of the congestion message only needs
to know which messages to send, and which not to send.  it doesn't need to
know the details of which specific subsystems are causing congestion.

Why is the "retry after" permitted only at level 4?  Even at lower
congestion levels, some messages may need to be deferred.

Janet

--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

This is a PRIVATE message. If you are not the intended recipient, please
delete without copying and kindly advise us by e-mail of the mistake in
delivery. NOTE: Regardless of content, this e-mail shall not operate to
bind CSC to any order or other contract unless pursuant to explicit written
agreement or government initiative expressly permitting the use of e-mail
for such purpose.
--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------



"Malas, Daryl" <[e-mail]> wrote on 04/26/2006 12:33:45 PM:

> An,
>
> Yes, and any ETS labels added or modified denoting an emergency services
> request should be taken into consideration in the same manner as
> described.
>
> --Daryl M.
>
> -----Original Message-----
> From: Nguyen, An P CIV NCS NC2 [mailto:[e-mail]]
> Sent: Wednesday, April 26, 2006 9:32 AM
> To: Malas, Daryl
> Cc: [e-mail]
> Subject: RE: [Sipping] Congestion Header
>
>
> Daryl,
>
> Just a question for clarification: Section 5.3 of the draft talks about
> "emergency services". Do they include Emergency Telecommunications
> Services in the IEPREP WG?
>
> Thanks,
>
> An
>
> -----Original Message-----
> From: Malas, Daryl [mailto:[e-mail]]
> Sent: Tuesday, April 25, 2006 10:53 PM
> To: [e-mail]
> Subject: RE: [Sipping] Congestion Header
>
>
> FYI...for those who review the Congestion Header draft, I am aware some
> of the quote marks were inadvertently converted to question marks during
> the document conversion.  I will correct those in an updated revision.
>
> Thanks...--Daryl
>
> I also noticed the link was broken, so I'll try it again.
>
> http://www.ietf.org/internet-drafts/draft-malas-sipping-congestion-heade
> r-00.txt
>
>
> -----Original Message-----
> From: Malas, Daryl
> Sent: Tuesday, April 25, 2006 7:06 PM
> To: [e-mail]
> Subject: [Sipping] Congestion Header
>
> Hello,
>
> We wrote a draft to resolve the common overload issues as identified by
> Rosenberg's work in progress "draft-rosenberg-sipping-overload-reqs-00".
>
>
> Title      : The Session Initiation Protocol (SIP) CONGESTION
> Header Field
> Author(s)   : D. Malas, et al.
> Filename   : draft-malas-sipping-congestion-header-00.txt
>
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-malas-sipping-congestion-heade
> r-00.txt
>
> We would appreciate feedback regarding the draft to see if the approach
> is sound, and can be further refined providing a solid method for
> alleviating this issue.
>
> Thanks,
>
> Daryl
>
> _______________________________________________
> Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
> This list is for NEW development of the application of SIP
> Use [e-mail] for questions on current sip
> Use [e-mail] for new developments of core SIP
>
> _______________________________________________
> Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
> This list is for NEW development of the application of SIP
> Use [e-mail] for questions on current sip
> Use [e-mail] for new developments of core SIP
>
> _______________________________________________
> Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
> This list is for NEW development of the application of SIP
> Use [e-mail] for questions on current sip
> Use [e-mail] for new developments of core SIP


_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use [e-mail] for questions on current sip
Use [e-mail] for new developments of core SIP