Subject: Re: [sip-overload] Comments on SOC Event Package

From: <[email-masked]>
Date: Wed, 1 Aug 2012 08:31:49 +0000

Finally, I note that we cite GR-2938-CORE at the top of page 24. Certainly we can cite an international specification for the discussion of call gapping -- doesn't Q.1248 cover this?.
[BC] As far as Intelligent Networks are concerned, this is covered in Q.1248.2 (CallGap and CallFiltering procedures). Despite its name, the first procedure is for gapping service requests towards IN services (e.g. 800 services), the second procedure enables switch-based  call filtering (to any destination, not just IN services) to be configured by an IN server.  PSTN congestion control is addressed in E.412.

_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
France Telecom - Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, France Telecom - Orange is not liable for messages that have been modified, changed or falsified.
Thank you.

---

From: <[email-masked]>
Date: Wed, 29 Aug 2012 14:10:00 +0000

Two comments/questions below.

De : [email-masked] [mailto:[email-masked]] De la part de Adam Roach
Envoyé : lundi 30 juillet 2012 19:27
À : [email-masked]
Cc : SOC (SIP Overload Control) WG
Objet : [sip-overload] Comments on SOC Event Package

I apologize for coming in so late after WGLC with these comments.

The first, and most important comment is that this document is presently based on the obsolete RFC3265. That document has been replaced by RFC 6665. This has a number of impacts. The first, most obvious one is that the references to the SIP events document need to be replaced to cite RFC6665 instead. This also necessitates that the section numbers cited in RFC3265 need to be updated to match the corresponding sections in 6665. If you have trouble figuring out where any specific bit of text went, I'll be happy to point you in the right direction.

One of the concepts that is now deprecated by 6665 is sharing multiple subscriptions on the same dialog. This means that the final sentence of the second paragraph of section 4.3 (starting "The same subscription dialog can also be used...") needs to be removed.

Section 5.12 can be removed. The concept of State Agents has been removed from 6665.

Related to SIP events, but not the 6665 changes: I looked very carefully for an indication of which Request URI is supposed to be used in the SUBSCRIBE messages sent for this event package, but saw no guidance. I suspect that you want a URI of the form "sip:server.example.com"<sip:server.example.com> (i.e., without a user) where "server.example.com" represents the server whose overload state is being requested. Full example messages would help to make this clearer.

The second paragraph on page 13 effectively turns the soft state mechanism of SUBSCRIBE/NOTIFY into a hard-state mechanism. This is problematic, as you can end up with a situation in which a communication disruption (say, a change in authentication) can lead to persistent throttling when it is not appropriate to do so. This artificially limits throughput, which is somewhat counter to what the overload control effort is supposed to do. What is the justification for keeping state beyond the duration of a subscription?

The third paragraph on page 13 says that a NOTIFY request that does not contain a body MUST be ignored. In contrast, section 4.3 says that a notification includes an empty body indicates that no overload rules are in effect. These statements are in conflict with each other, unless you are intending to distinguish between a message containing an *empty* (but present) body, and a message that does not contain a body. If that's the distinction being made, you need to be far more explicit that such is the intention. I would strongly counsel against such a decision; even if the difference is made clear in the text, it is such a subtle distinction that it is unlikely to be implemented correctly.

Unrelated to the 6665 issues, I have some additional comments. At the top of page 9, there is a statement that the proxies to which proxies should subscribe can be learned from the signaling messages sent and received. I think we need some guidance about when this learned information can be purged. Presumably we don't want a single interaction between proxies to result in a subscription that is kept in place for the rest of all time.

Near the top of page 16, the document specifies that elements containing multiple <one>, <except>, and <many> elements are ORed together. I don't think this is quite what you intend. If you have a <many> and an <except>, you don't really want to match everything that is in the <many> OR everything excluded by the <exclude>. I can kind of figure out what you really meant, but the language needs to be adjusted to actually say it.

On page 19, one of the specified actions is "drop." There is passing implication that doing this over an unreliable link will cause retransmissions. This needs more treatment in the text. In fact, as dropping requests over an unreliable link will *always* make overload worse rather than better, I would strongly recommend that we add text that specifies that any "drop" rule applied to an unreliable transport MUST be treated as if it were "reject."

Similarly, we run into an issue in which an ACK response to a 200 is dropped, as doing so will cause the 200 to be retransmitted, which again exacerbates any overload condition that may arise. In other words, I think we need to specify that "drop" cannot be applied to ACK (and reject clearly can't, since ACK never sees a response) -- so ACKs must always go through regardless of overload filters. For the same reason, proxies that receive an ACK response to a non-200 need to always process the ACK rather than dropping it.

   [BC] I don't think this can happen. The current text says that "Conditions are evaluated on receipt of an initial SIP request for a dialog or
 standalone transaction". So my understanding is that conditions are not evaluated on receipt of an ACK. Moreover, the "ACK" is not a valid value for the <method> element and the current text says that when the <method> element is not included in a filter, the rule actions are applicable to all initial methods. A formal definition of initial method may be missing but I assume ACK is not an initial method.

On the other hand, I'm wondering whether this comment about ACK should not be made against draft-ietf-soc-overload-control, section 5.10?

On to topic of rejects, I note that the current draft simply gives an example (500 Server Internal Error) rather than specifying how rejection is performed. This will make troubleshooting a system more difficult. I would suggest that we add a new 500-class error code that is used to indicate this specific situation. We also need to think about whether "Retry-After" handling is appropriate in this case. I think it is, but we need to work through how it is set (i.e., is it part of the overload rule, or is it set by the server itself?)

[BC] Is there any reason for rejecting calls with a different response code depending on whether overload control information was obtained using the feedback-based or even-based solution? I guess the answer is no. Section 5.10.2 of draft-ietf-soc-overload-control says that the SIP server must reject requests with a 503 response.

Finally, I note that we have a "forward" rule. I think we would be well served by a very similar "redirect" rule that sends a 300-class response rather than forwarding the request to an alternate destination.

Small editorial nit: while the use of the date "79 AD" in the example at the top of page 21 is both clever and amusing to those who have both received an education on the topic of Vesuvius' destruction of Pompeii and recall its details, the use of a two-digit year in an example is likely to lead to confusion on the part of implementors. We really don't need examples from which implementors might incorrectly infer that omitting the century portion of the year in ISO-style dates is acceptable.

Finally, I note that we cite GR-2938-CORE at the top of page 24. Certainly we can cite an international specification for the discussion of call gapping -- doesn't Q.1248 cover this?. It seems a bit provincial to use a Bellcore spec to the exclusion of an ITU-T spec in the context of a document to be published by an international standards body such as the IETF.

/a