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

From: Charles Shen <[email-masked]>
Date: Fri, 12 Oct 2012 12:45:48 -0400

will update. thanks

Charles

On Wed, Aug 1, 2012 at 4:31 AM, <[email-masked]> wrote:

>  ** **
>
> 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.
>
>
> _______________________________________________
> sip-overload mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sip-overload
>
>

---

From: Charles Shen <[email-masked]>
Date: Fri, 12 Oct 2012 13:10:20 -0400

Hi Adam, thanks a lot for your review, sorry I was just able to catch up
with the draft. please see detailed reply inline.

On Mon, Jul 30, 2012 at 1:27 PM, Adam Roach <[email-masked]> wrote:

>  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.
>
>
Thank you. the -4 version partially migrated to 6665, the -5 version should
complete it with your help.

 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.
>
>
Thanks for pointing out the concept change. actually the sentence "The same
subscription dialog can also be used to convey policies for multiple
different load filtering events in a set of rules (Section 6.1)." is meant
to say that same subscription dialog may convey multiple rules (in a
ruleset) each for different load filtering events (e.g., applicable to
different destinations). Do you still think it is really in conflict with
the 6665 change you mentioned? Maybe the sentence should be clarified
instead of removed?

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

done

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

Below is the flow I plan to add to Section 6.5, please see if they suffice

   atlanta                biloxi
      | F1 SUBSCRIBE |
      |------------------------>|
      | F2 200 OK         |
      |<------------------------|
      | F3 NOTIFY        |
      |<------------------------|
      | F4 200 OK         |
      |------------------------>|

   F1 SUBSCRIBE atlanta.example.com -> biloxi.example.com

      SUBSCRIBE sip:biloxi.example.com SIP/2.0
      Via: SIP/2.0/TCP atlanta.example.com;branch=z9hG4bKy7cjbu3
      From: sip:atlanta.example.com;tag=162ab5
      To: sip:biloxi.example.com
      Call-ID: [email-masked]
      CSeq: 2012 SUBSCRIBE
      Contact: sip:atlanta.example.com
      Event: load-control
      Max-Forwards: 70
      Accept: application/load-control+xml
      Expires: 3600
      Content-Length: 0

   F2 200 OK   biloxi.example.com -> atlanta.example.com

      SIP/2.0 200 OK
      Via: SIP/2.0/TCP biloxi.example.com;branch=z9hG4bKy7cjbu3
        ;received=192.0.2.1
      To: <sip:biloxi.example.com>;tag=331dc8
      From: <sip:atlanta.example.com>;tag=162ab5
      Call-ID: [email-masked]
      CSeq: 2012 SUBSCRIBE
      Expires: 3600
      Contact: sip:biloxi.example.com
      Content-Length: 0

   F3 NOTIFY  biloxi.example.com -> atlanta.example.com

      NOTIFY sip:atlanta.example.com SIP/2.0
      Via: SIP/2.0/TCP biloxi.example.com;branch=z9hG4bKy71g2ks
      From: <sip:biloxi.example.com>;tag=331dc8
      To: <sip:atlanta.example.com>;tag=162ab5
      Call-ID: [email-masked]
      Event: load-control
      Subscription-State: active;expires=3599
      Max-Forwards: 70
      CSeq: 1775 NOTIFY
      Contact: sip:biloxi.example.com
      Content-Type: application/load-control+xml
      Content-Length: ...

      [Load Control Document]

   F4 200 OK atlanta.example.com -> biloxi.example.com

      SIP/2.0 200 OK
      Via: SIP/2.0/TCP atlanta.example.com;branch=z9hG4bKy71g2ks
        ;received=192.0.2.2
      From: <sip:biloxi.example.com>;tag=331dc8
      To: <sip:atlanta.example.com>;tag=162ab5
      Call-ID: [email-masked]
      CSeq: 1775 NOTIFY
      Content-Length: 0

> 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 reason behind the existing text is to separate the contents that the
mechanism conveys from the mechanism itself. With the current text, the
situtaion you mentioned should be avoided by requiring the Notifier sending
explicit filter modification messages while the subscription is still in
place. However, I am fine revising it to state that terminating the
Subscribe/Notify relationship also requires the subscriber to terminate all
the filtering rules from the specific Notifier.

> 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.
>
>
 OK. So how about combining them to "a NOTIFY request that does not contain
a body or contains an empty body indicates that no filtering rules need to
be updated."?

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.
>
>
I agree. We can add a sentence requiring the SIP entities to decide on when
the relationship information needs to be purged (e.g., after certain period
of inactivity). I am not sure if we need to/can specify a "standard" value
for that inactivity period, do you have any thoughts?

> 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.
>
>
Good point, possible update as the following:

... When the <from>, <to>, <request-uri> and <p-asserted-identity> elements
contain multiple <one> or <many> sub-elements, the result is also combined
using logical OR. When the <many> sub-element further contains one or more
<except> sub-elements, the result of each <except> sub-element is combined
using a logical OR, similar to that of the <identity> element in <xref
target="RFC4745"/>...

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

MUST is a bit strong, but it seems to make sense. Here is the proposed
revised text:

"If the "alt-action" value is "drop", it should be noted that when running
SIP over an unreliable transport such as UDP, using the "drop" action will
create message retransmissions that further worsen the overload situation.
Therefore, any "drop" action 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.
>

see response on a separate thread.

> 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?)
>
>
I personally think "Retry-After" maybe something more appropriate for the
server itself, as the overload control rules might be relatively static
here.

> 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.
>
>
That makes sense. So I am changing it to:

"When the "alt-action" value is "redirect", an "alt-target" attribute MUST
be defined. The "alt-target" specifies a list of one or more URIs where the
request should be redirected. The server responds to the filtered request
with a 300-class response message containing the list of redirection URIs,
as in the behavior of a SIP redirect server."

and also define the alt-target as a list of URIs where the requests can be
redirected to.

   <xs:attribute name="alt-target" type="alt-target-type" use="optional"/>

   <!-- ALT TARGET TYPE -->
   <xs:simpleType name="alt-target-type">
      <xs:list itemType="xs:anyURI"/>
   </xs:simpleType>

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

OK, I will change it to Katrina in 2005, hope it will be a better example.

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

Done.

Thanks!

Charles

> /a