Subject: [Sipping] draft-niemi-sipping-subnot-issues-00: NOTIFY timeouts

From: Adam Roach <[email-masked]>
Date: Wed, 27 Jul 2005 18:00:32 -0500

This draft has two main thrusts. One is suppression of NOTIFY requests under certain circumstances. The other is the removal of a MUST-strength requirement that does not actually exist.

This second goal is summarized in the document itself as:

   Currently, the notifier is instructed to terminate the subscription
   ("MUST" strength) in case a NOTIFY request times out.

This is presumably referring to the following passage from RFC 3265:

   If the NOTIFY request fails (as defined above) due to a timeout
   condition, and the subscription was installed using a soft-state
   mechanism (such as SUBSCRIBE), the notifier SHOULD remove the
   subscription.

RFC 3265 then goes on to describe precisely why this is in place (network overload protection), so that implementors can make intelligent decisions regarding when they can go against this normative suggestion. Deployments where the primary clients can be disconnected from the network without knowing that they have been disconnected are certainly one such situation.

It is my opinion that the sections of this document dealing with NOTIFY timeout handling arise from misunderstanding on the part of the author, and do not represent an actual protocol issue.

/a

_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use [email-masked] for questions on current sip
Use [email-masked] for new developments of core SIP

---

From: Aki Niemi <[email-masked]>
Date: Fri, 29 Jul 2005 16:47:58 +0300

Inline.

ext Adam Roach wrote:
> This draft has two main thrusts. One is suppression of NOTIFY requests 
> under certain circumstances. The other is the removal of a MUST-strength 
> requirement that does not actually exist.
> 

My mistake, it is actually SHOULD strength. However, in the absence of 
description of cases when the SHOULD does not apply, it is equivalent to 
a MUST.

> RFC 3265 then goes on to describe precisely why this is in place 
> (network overload protection), so that implementors can make intelligent 
> decisions regarding when they can go against this normative suggestion. 

Really? That is not something I got from the informative passage that 
follows the "SHOULD remove" statement:

       This behavior prevents unnecessary transmission of state
       information for subscribers who have crashed or disappeared from
       the network.  Because such transmissions will be sent multiple
       times, per the retransmission algorithm defined in SIP [1]
       (instead of the typical single transmission for functioning
       clients), continuing to service them when no client is available
       to acknowledge them could place undue strain on a network.  Upon
       client restart or reestablishment of a network connection, it is
       expected that clients will send SUBSCRIBE messages to refresh
       potentially stale state information; such messages will re-install
       subscriptions in all relevant nodes.

Perhaps it is explained somewhere else in the document when going 
against this SHOULD is appropriate?

> Deployments where the primary clients can be disconnected from the 
> network without knowing that they have been disconnected are certainly 
> one such situation.

I think this assumes that the notifier knows something about the 
client's connection status, which is sometimes true, but not an 
assumption that holds universally true.

Also, there is no definition of how the notifier would actually go 
against the SHOULD. For example, would it still keep the subscription 
state "active", and keep sending the notifications carrying full-state, 
and for how long?

So perhaps my description of the problem was not the most comprehensive 
and accurate, but if the normal behavior is to expect a client 
re-subscribe, then at least there is a restart avalanche problem (think 
of IETF WLAN access points coming and going, as well as the problem that 
is discussed in the first part of my draft -- the inability to persist 
state accross a re-subscribe -- that creates an inefficiency.

Cheers,
Aki

> It is my opinion that the sections of this document dealing with NOTIFY 
> timeout handling arise from misunderstanding on the part of the author, 
> and do not represent an actual protocol issue.
> 
> /a
> 
>