Subject: [sip-overload] FW: A few comments/questions on the overload drafts

From: "Moran, Timothy L." <[email-masked]>
Date: Mon, 23 Nov 2009 20:54:25 -0500

Oops - wrong email address. No wonder these comments never showed up on
the list.

Timothy Moran

_____________________________________________
From: Moran, Timothy L. 
Sent: Sunday, November 08, 2009 12:29 PM
To: [email-masked]
Subject: A few comments/questions on the overload drafts

A couple of questions/comments on the current SIP Overload Drafts

Draft-hilt-sipping-overload-07.txt
-	3.5 and 4.0: It is not clear what an "element" should do if it
has exhausted all of its downstream elements (ran the oc test on
multiple servers with no success).  Should it send a 500 or oc or 503
??? What is the answer for an upstream element that supports oc vs. one
that does not?
-	3.6 Self Limiting:  "The SIP server SHOULD occasionally forward
a single request to probe ..." Is a default value for "occasionally"
needed?
-	4.1 Message Prioritization: "A SIP server should honor the
Resource-Priority header ..."  Could this be restated to something like:
"A SIP server that supports resource priority as defined in RFC 4412,
SHALL honor the Resource-Priority header field if it is present in a SIP
message."

Draft-shen-sipping-load-control-event-package-03.txt
-	8.2: "When the user is identified by the source and a favorable
action is specified, the result may be comparable to identifying a
priority user based on authorized Resource Priority Headers {RFC 4412}
in the requests."    I'm not sure this is comparable since the
invocation of priority calls is regulated to be for emergency purposes
only.  Thus, a fire chief ordering pizza does not constitute the need
for priority treatment - even though the source is an authorized
priority service user.
-	4.4: "Therefore, the entity that initiates the filter needs to
take counter-measures towards any non-conforming neighbors. A simple
mode is to just drop excessive requests..."  Should this section
(paragraph) note the possibility of using priority policy as in RFC 4412
before "dropping" requests?  It is recognized that section 8.1 mentions
this, but this section especially warrants reference to 4412 (IMHO).

Is it possible (in the future) to provide an example scenario (or two)
of how the shen and hilt drafts are complementary - a BCP for their
combined use so to speak?

BR,

Timothy Moran 
703-676-2334 (W)
571-268-0858 (C)

---

From: Volker Hilt <[email-masked]>
Date: Wed, 25 Nov 2009 16:45:30 -0500

Timothy,

some clarifications inline.
> -       3.5 and 4.0: It is not clear what an “element” should do if it 
> ??? 
Section 4.2. Rejecting Requests has text for this case. It defines the 
use of the 503 code for these cases.

> What is the answer for an upstream element that supports oc vs. one 
> that does not?
> 
This case is also described in Section 4.2 (second an third paragraph).

> -       3.6 Self Limiting:  “The SIP server SHOULD occasionally forward 
> a single request to probe …” Is a default value for “occasionally” needed?
> 
Yes, it makes sense to give a recommendation. I would assume 3 seconds 
is reasonable.

> -       4.1 Message Prioritization: “A SIP server should honor the 
> Resource-Priority header …”  Could this be restated to something like: 
> ”A SIP server that supports resource priority as defined in RFC 4412, 
> message.”
The current wording is SHOULD. I'm not sure what would be changed by the 
new wording.

Thanks,

Volker

> -       8.2: “When the user is identified by the source and a favorable 
> in the requests.”    I’m not sure this is comparable since the 
> for priority treatment – even though the source is an authorized 
> priority service user.
> 
> -       4.4: “Therefore, the entity that initiates the filter needs to 
> mode is to just drop excessive requests…”  Should this section 
> before “dropping” requests?  It is recognized that section 8.1 mentions 
> of how the shen and hilt drafts are complementary – a BCP for their