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

From: "Gordon Ledgard" <[email-masked]>
Date: Fri, 29 Jul 2005 10:14:33 -0400

Given that it is impossible for the NOTIFY sender to determine why its
NOTIFY message did not reach the subscriber, and that the subscriber
having
crashed is only one of the possible reasons, maybe it would make more
sense
to suggest that the NOTIFYer attempt some kind of backoff algorithm at
the application level, in addition to the normal transmission level
before deciding to yank the subscription.

The cost to the client (subscriber) side of A) missing notifications
until
it figures out that the NOTIFYer thinks the SUBSCRIBER died, and B) the
potential for NOTIFY cascades in the event that the subscription has to
go
to some kind of NOTIFY concentrator, seems rather burdensome for what
could
be a simple network hiccup.

In other words, the notifier sends NOTIFY at t=0s, t=0.5s, t=1.5s,
t=2.5s
t=4.5s,  as per the transmission backoff, and then the agent waits
(e.g.) 2 minutes, and tries again. Then 4 minutes later. And only THEN
does it decide
to yank the subscription.

Comments?

Gordon R. Ledgard,
IPeria, Inc.

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
Behalf
> Of Aki Niemi
> Sent: Friday, July 29, 2005 9:48 AM
> To: ext Adam Roach
> Cc: SIPPING WG
> Subject: Re: [Sipping] draft-niemi-sipping-subnot-issues-00: NOTIFY
> timeouts
> 
> 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.
> >
> > 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.
> 
> 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
> >
> >
> > _______________________________________________
> > 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
> >
> 
> _______________________________________________
> 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

_______________________________________________
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 17:30:12 +0300

> to yank the subscription.

Yes, this is along the lines I was thinking as well. In addition to the 
backoff, the NOTIFYs could, for instance, be sent without a body, and 
with something like a subscription-state: zombie;reason=timeout header 
field.

Cheers,
Aki