Subject: [Sip] Updated draft-niemi-sip-subnot-etags

From: Aki Niemi <[email-masked]>
Date: Sun, 05 Nov 2006 09:24:57 -0800

Hodwy,

Managed to squeeze in an update to the conditional subscribe draft:

http://www.ietf.org/internet-drafts/draft-niemi-sip-subnot-etags-02.txt

Major changes include:

- Bunch of clarifications and fixes contributed by Johnny Vrancken

- Added the concept of "*" entity-tag, as suggested by Christian Schmidt

The rationale for the latter change is that it turns out if you're
suppressing NOTIFYs within the subscription, it doesn't matter what the
actual value of the entity-tag is; the superfluous notifications should
simply get suppressed by default. It is now possible by including

   Suppress-Notify-If-Match: *

to the SUBSCRIBE in subscription refreshes/unsubscribes. This has some
other interesting uses as well, like being able to do a HEAD like query
for the current entity-tag, or a heartbeat-type function to check the
liveliness of a resource (without the extra cost of receiving the
notification).

In essence, the client need not bother tracking the etags unless it is
resuming a subscription, or using polling to query the state. To me,
this is a simple addition that doesn't introduce any complexity, and
ought to be the default behavior anyway.

I'm planning to make a fairly extensive rewrite of this draft to make it
look more like an implementation spec, including adding detailed
examples and moving some of the requirements text to an appendix.

However, before I commit to that, it would be nice to get some traction
to the draft from the working group.

Is this something the SIP WG is interested in progressing as a WG effort?

Cheers,
Aki

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

---

From: Avshalom Houri <[email-masked]>
Date: Mon, 6 Nov 2006 00:58:42 +0200

I really think that this is a simple and important optimization and we
need to adopt this as WG item.

--Avshalom

Aki Niemi <[email-masked]> 
05/11/2006 19:24

To
IETF SIP List <[email-masked]>
cc

Subject
[Sip] Updated draft-niemi-sip-subnot-etags

Hodwy,

Major changes include:

Cheers,
Aki

---

From: <[email-masked]>
Date: Wed, 8 Nov 2006 04:30:15 +0200

Hi,

I think this is a useful optimization for SIP events in general, and
definitely needed for Presence. 

The main problem in deploying SIP presence in wireless networks is still
that the amount of traffic it generates is too large. Even if the actual
state changes were infrequent, the subscription refreshes can generate a
lot of traffic, as each refresh triggers a full-state NOTIFY. The
partial notification mechanism in SIMPLE does not help with this, since
it does not apply to refreshes. It is of course possible to increase the
subcription refresh interval, but that has its tradeoffs too. And
besides helping with the refreshes, this draft is helpful in polling and
re-subscriptions after connectivity breaks. 

The proposed mechanism seems relatively simple, so complexity should not
be an issue. Also, as this is a backwards compatible extension with
support negotiation, no-one is forced to implement it if they think it's
not useful for them.

So, I strongly support adopting this as a WG item.

For the further work, I think it would be essential to clarify how this
works with the resource list mechanism, as people would like to use the
two mechanisms together. 

Regards,
	Markus

>-----Original Message-----
>From: ext Aki Niemi [mailto:[email-masked]] 
>Sent: 05 November, 2006 19:25
>To: IETF SIP List
>Subject: [Sip] Updated draft-niemi-sip-subnot-etags
>
>Hodwy,
>
>The rationale for the latter change is that it turns out if 
>you're suppressing NOTIFYs within the subscription, it doesn't 
>matter what the actual value of the entity-tag is; the 
>superfluous notifications should simply get suppressed by 
>default. It is now possible by including
>
>to the SUBSCRIBE in subscription refreshes/unsubscribes. This 
>has some other interesting uses as well, like being able to do 
>a HEAD like query for the current entity-tag, or a 
>heartbeat-type function to check the liveliness of a resource 
>(without the extra cost of receiving the notification).
>
>In essence, the client need not bother tracking the etags 
>unless it is resuming a subscription, or using polling to 
>query the state. To me, this is a simple addition that doesn't 
>introduce any complexity, and ought to be the default behavior anyway.
>
>I'm planning to make a fairly extensive rewrite of this draft 
>to make it look more like an implementation spec, including 
>adding detailed examples and moving some of the requirements 
>text to an appendix.
>
>However, before I commit to that, it would be nice to get some 
>traction to the draft from the working group.
>
>This list is for NEW development of the core SIP Protocol Use 
>[email-masked] for questions on current sip

---

From: "Schmidt, Christian" <[email-masked]>
Date: Wed, 8 Nov 2006 04:03:26 +0100

Hi,

currently, performance load caused by Presence service is very 
difficult to predict. Any method to avoid redundant traffic
(without adding much complexity and decreasing functionality)
is useful. This is the case for this etag draft. Therefore I
also support, to adopt this as a WG item.

Regards
Christian

-----Ursprüngliche Nachricht-----
Von: [email-masked] [mailto:[email-masked]] 
Gesendet: Mittwoch, 8. November 2006 03:30
An: [email-masked]; [email-masked]
Betreff: RE: [Sip] Updated draft-niemi-sip-subnot-etags

Hi,

Regards,
	Markus

---

From: Avshalom Houri <[email-masked]>
Date: Wed, 8 Nov 2006 05:26:01 +0200

Same here as I said once or twice before.

See also the discussion in draft-rang-simple-problem-statement-01.txt.
subnot-etags is one of the only optimizations that save both on the 
network
and on the processing load on the presence server.

Thanks
--Avshalom

"Schmidt, Christian" <[email-masked]> 
08/11/2006 05:03

To
<[email-masked]>, <[email-masked]>, <[email-masked]>
cc

Subject
AW: [Sip] Updated draft-niemi-sip-subnot-etags

Hi,

Regards
Christian

-----Ursprüngliche Nachricht-----
Von: [email-masked] [mailto:[email-masked]] 
Gesendet: Mittwoch, 8. November 2006 03:30
An: [email-masked]; [email-masked]
Betreff: RE: [Sip] Updated draft-niemi-sip-subnot-etags

Hi,

Regards,
                 Markus

---

From: "Vrancken, Johnny" <[email-masked]>
Date: Wed, 8 Nov 2006 08:50:28 +0100

I'd like to confirm my full support expressed in a former mail to adopt
Aki's document as a WG item.
As Markus stated, it is important to clarify how the proposed mechanism
can be combined with other optimization techniques.

Johnny

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: woensdag 8 november 2006 3:30
To: [email-masked]; [email-masked]
Subject: RE: [Sip] Updated draft-niemi-sip-subnot-etags

Hi,

Regards,
	Markus

---

From: David Viamonte <[email-masked]>
Date: Fri, 10 Nov 2006 16:34:21 +0100

Hello,

Regardless of the general thread about the draft traction, I have a
technical question (suggestion) about a minor detail in this very
interesting document.

The I-D defines in section 4.3 the behavior of a notifier, upon
reception of a "Supress-Notify-If-Match". According to the description,
there should be no difference in the "200 OK" message sent as an answer
to the "SUBSCRIBE" request, regardless of the "SIP-Etag" value being
equal or different to the "Supress-Notify-If-Match" value. That is: the
subscription refresh works exactly the same if the etag values are
equal or not, the only difference being whether the notifier will
afterwards send a "NOTIFY" or not. In particular, there is no explicit
need to carry a "SIP-Etag" header in the "200 OK" message issued by the
notifier.

The problem I see with this is that the Watcher is not able to
determine whether the "etag" was the same, or simply a subsequent
"NOTIFY" message gets lost due to congestion problems.

I would propose that the text in 4.3 explicitly states that the
"SIP-Etag" header be included in the "200 OK" answer to the "SUBSCRIBE"
request, in case that is feasible (I've checked RFC 3903 and I don't
see any issue with this). This way, a Watcher can determine, upon
receiving a "200 OK", if the entity tag is the same (and thus, no
additional "NOTIFY" is expected) or not (in this case, if a subsequent
NOTIFY is not received shortly, the client may suspect something wrong
is happenning, and act accordingly).

I think this was implicit in section 4.3, as is the case of RFC 3903
for the "mirror" use case related to PUBLISH messages, but it may be
worth to still mention it explicitly (?). Perhaps the general rule is:
if you receive a "(...)If-Match" header in a request, you SHOULD/MUST
answer with a "SIP-Etag" header in its response, but I don't find any
explicit text about this...

Sorry if I am missing anyething and/or my comment was already
implicitly tackled somewhere else...

Cheers,

David

PS.- I agree that covering the RLS case in this doc would be extremely
desirable, as Etags and RLS are seen as two major Presence traffic
optimization mechanisms, and it would be very convenient to be able to
use them together.

-----Original Message-----
From: ext Aki Niemi [mailto:[email-masked]]
Sent: 05 November, 2006 19:25
To: IETF SIP List
Subject: [Sip] Updated draft-niemi-sip-subnot-etags

Hodwy,

Major changes include:

- Added the concept of "*" entity-tag, as suggested by
Christian Schmidt

Is this something the SIP WG is interested in progressing as a
WG effort?

Cheers,
Aki