RE: [Sipping] Congestion Header

["Malas, Daryl" <[e-mail]>]

Comments inline...

Daryl M.
[e-mail]

Ernest Hemingway - "Never mistake motion for action."


-----Original Message-----
From: Janet P Gunn [mailto:[e-mail]] 
Sent: Sunday, April 30, 2006 5:03 PM
To: Malas, Daryl
Cc: Nguyen, An P CIV NCS NC2; [e-mail]
Subject: RE: [Sipping] Congestion Header






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

[Malas] The congestion header would preferably be provided prior to a
488 response, allowing the upstream proxy to alleviate (if possible) a
traffic burden on the TDM gateway.  It can do this as described in the
document.  

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.

[Malas]  Only one system-descr header would be included per proxy
congestion header information.  It is optional, and is not required in
the congestion header.  The only required information is congestion and
level unless additional proxy information is included...then a server ID
is associated with additional information.

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

[Malas]  I suppose it's up to the working group to decide if a
retry-after header is desirable at all levels.  If it is, I can easily
change this.

[Malas]  Thanks for the feedback.

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