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

From: Adam Roach <[email-masked]>
Date: Mon, 30 Jul 2012 10:27:13 -0700

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

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?)

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