Subject: RE: [Simple] WGLC: partial notification

From: [email-masked]
Date: Mon, 3 May 2004 12:01:38 +0300

> -----Original Message-----
> From: ext Schmidt Christian [mailto:[email-masked]]
> Sent: 30.April.2004 14:28
> To: Khartabil Hisham (Nokia-TP-MSW/Helsinki); [email-masked];
> [email-masked]
> Cc: Lonnfors Mikko (Nokia-NRC/Helsinki); [email-masked]
> Subject: AW: [Simple] WGLC: partial notification
> 
> 
> Hi Hisham,
> 
> this proposal would not solve the problem with a missing 
> NOTIFY (full or partial). 

Can you demonstrate why with some flows?

> 
> What´s about the following proposal:
> The notifier must not issue a NOTIFY (full or partial), 
> before it receives a 200 for the last issued NOTIFY (full or 
> partial). After experation of a timer t, the notifier should 
> send a full NOTIFY.

If a NOTIFY transaction does not complete, the subscription is terminated. If you are suggesting that timer t is less than 64*T1 (timer F, that's when the transaction terminates and subsequently the subscription), then you are suggesting support for overlapping NOTIFYs.

Sending a full state NOTIFY after timer t does not help since if no response arrives for the partial NOTIFY, the subscription will terminate.

/Hisham

> 
> This would also work without version number and would cover 
> reordering and packet loss cases.
> 
> Regards,
> Christian
> 
> 
> 
> -----Ursprüngliche Nachricht-----
> Von: [email-masked] [mailto:[email-masked]] Im 
> Auftrag von [email-masked]
> Gesendet: Freitag, 30. April 2004 08:27
> An: [email-masked]; [email-masked]
> Cc: [email-masked]; [email-masked]
> Betreff: RE: [Simple] WGLC: partial notification
> 
> 
> Ok, I also agree that overlapping partial NOTIFYs complicate 
> things without benefit. I also would like to propose 
> explicitly disallowing overlapping full state and partial. 
> I.e. A notifier must not issue a partial state NOTIFY without 
> first receiving the 200 for a full state NOTIFY. I believe 
> the converse is also required: the notifier must not issue a 
> full state NOTIFY before it receives a 200 for a partial state NOTIFY.
> 
> With all there restrictions, we can do without the version attribute.
> 
> Regards,
> Hisham
> 
> > -----Original Message-----
> > From: ext Paul Kyzivat [mailto:[email-masked]]
> > Sent: 29.April.2004 21:47
> > To: Robert Sparks
> > Cc: Khartabil Hisham (Nokia-TP-MSW/Helsinki); Lonnfors Mikko
> > (Nokia-NRC/Helsinki); [email-masked]
> > Subject: Re: [Simple] WGLC: partial notification
> > 
> > 
> > 
> > 
> > Robert Sparks wrote:
> > > Aside from that I'd like for you to think through this again
> > > from viewpoints besides active attack (use a transient malfunction
> > > of the application (above the layer that would screw up 
> basic SIP)),
> > > I'm ready to let this go as long as we have _a_ solid solution to
> > > dealing with reordered/missing notifies.
> > 
> > I'm not going to start down the path to speculation about how 
> > to recover 
> > from arbitrary malfunctions of an application. That is just plain 
> > impossible without some characterization of the kinds of 
> malfunctions 
> > that are to be recovered from.
> > 
> > > So, backing out a layer, lets look at my original question of
> > > whether or not we allow overlapping ->partial<- NOTIFYs at all
> > > in this case.
> > 
> > I don't see any compelling need to support overlapping 
> > partial notifies. 
> > It is very difficult to see how to make them work.
> > 
> > I can imagine a case where there might be some motivation: 
> I sent one 
> > notification and have had no response. But I already have a 
> bunch of 
> > additional changes that you should know about. It might be 
> > advantageous 
> > to start sending them as soon as possible. But until you know 
> > the prior 
> > one has been handled it isn't safe to send the new one.
> > 
> > > Why would you want to? What value would doing that bring? 
> > > 
> > > 3261 and even presence-10 left sending full-state presence
> > > NOTIFYs open. We wouldn't be changing that. If an application
> > > for some reason decided it needed to send a new full-state
> > > notify while a partial-state notify was pending, it could.
> > > So any of the arguments for allowing it from the 3261/presence-10
> > > are still satisfied. Can you see any use case where allowing
> > > a server to send overlapping partial NOTIFYs is a good idea?
> > > If not, disallowing it seems a powerful simplification.
> > >
> > 
> > I agree.
> > 
> > 	Paul
> > 
> > 
> 
> _______________________________________________
> Simple mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/simple
> 

_______________________________________________
Simple mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/simple

---

From: [email-masked]
Date: Mon, 3 May 2004 12:01:38 +0300

/Hisham

---

From: [email-masked]
Date: Mon, 3 May 2004 13:14:38 +0300

> Sent: 03.May.2004 12:47
> To: Khartabil Hisham (Nokia-TP-MSW/Helsinki); Schmidt Christian;
> [email-masked]; [email-masked]
> please see my comments in the text,
> 
> best regards
> Chrisitan
> 
> 
> 
> > Hi Hisham,
> > 
> Christian:
> Take for example the following flow
> ----> SUBSCRIBE
> <---- 200
> <---- NOTIFY1 (full)
> ----> 200
> <-X-- NOTIFY2 (full)
> <---- NOTIFY3 (partial)
> 
> The Receiver would not know, that NOTIFY2 was lost and take 
> NOTIFY3 as partial change on basis of NOTIFY1. That could 
> lead to incorrect information. Same in the following case.
> ----> SUBSCRIBE
> <---- 200
> <---- NOTIFY1 (full)
> ----> 200
> <-X-- NOTIFY2 (partial)
> <---- NOTIFY3 (partial)

These scenarios are no different than what we have been discussing. Version solves those problem. We have tracked a little back and started questioning the need for overlapping NOTIFYs. Why does disallowing overlapping partial NOTIFYs not solve the problem (which is what you were suggesting)?

> If a NOTIFY transaction does not complete, the subscription 
> is terminated. 
> 
> If you are suggesting that timer t is less than 64*T1 (timer 
> F, that's when the transaction terminates and subsequently 
> the subscription), then you are suggesting support for 
> overlapping NOTIFYs.
> 
> Sending a full state NOTIFY after timer t does not help since 
> if no response arrives for the partial NOTIFY, the 
> subscription will terminate.
> 
> Christian:
> If the notifier get no 200 for his last NOTIFY, either the 
> NOTIFY or the 200 was lost. Therefor the receiver possibly 
> can not benefit from a partial notification. If the receiver 
> gets a new upgrade and reply a 200, the notifier knows, that 
> the receiver is in sync again. Timer t should be selected 
> high enough, that overlapping NOTIFYs are nearly excluded.
> Is it necessary, that packet loss (timer F) will 
> automatically lead to a termination of the subscription? This 
> could lead to additional and perhaps not needed messages (new 
> subscription).

If sender of a NOTIFY (notifier) does not get a 200 for it and Timer F fires, it terminates the subscription. What is the point of sending a full NOTIFY if the subscription will termiante anyway?

/Hisham

---

From: [email-masked]
Date: Mon, 3 May 2004 13:14:38 +0300

/Hisham

---

From: Schmidt Christian <[email-masked]>
Date: Mon, 3 May 2004 11:47:03 +0200

Hi Hisham,

best regards
Chrisitan

Christian:

The Receiver would not know, that NOTIFY2 was lost and take NOTIFY3 as partial change on basis of NOTIFY1. That could lead to incorrect information. Same in the following case.
----> SUBSCRIBE
<---- 200
<---- NOTIFY1 (full)
----> 200
<-X-- NOTIFY2 (partial)
<---- NOTIFY3 (partial)

> partial). After experation of a timer t, the notifier should 

If a NOTIFY transaction does not complete, the subscription is terminated. 

If you are suggesting that timer t is less than 64*T1 (timer F, that's when the transaction terminates and subsequently the subscription), then you are suggesting support for overlapping NOTIFYs.

Christian:
If the notifier get no 200 for his last NOTIFY, either the NOTIFY or the 200 was lost. Therefor the receiver possibly can not benefit from a partial notification. If the receiver gets a new upgrade and reply a 200, the notifier knows, that the receiver is in sync again. Timer t should be selected high enough, that overlapping NOTIFYs are nearly excluded.
Is it necessary, that packet loss (timer F) will automatically lead to a termination of the subscription? This could lead to additional and perhaps not needed messages (new subscription).

/Hisham

---

From: Schmidt Christian <[email-masked]>
Date: Mon, 3 May 2004 12:55:44 +0200

Christian:
Disallowing overlapping partial NOTIFYs combined with versioning solve the problem.
Disallowing overlapping partial NOTIFYs without versioning would not solve the problem.
The version attribute, you need anyway to avoid mistakes in case of reordered full NOTIFYs.

Christian:
Is it possible, to avoid this unnecessary termination of the subscription (caused by the loss of a single packet) by an additional NOTIFY? This would increase efficiency.

/Hisham

---

From: Schmidt Christian <[email-masked]>
Date: Mon, 3 May 2004 12:55:44 +0200

Christian:

Christian:

/Hisham

---

From: Schmidt Christian <[email-masked]>
Date: Mon, 3 May 2004 11:47:03 +0200

Hi Hisham,

best regards
Chrisitan

Christian:

Christian:

/Hisham

---

From: [email-masked]
Date: Mon, 3 May 2004 13:40:14 +0300

Hi,

Related to this issue it occurred to me that winfo
(draft-ietf-simple-winfo-package-05) may also suffer from this. As far
as I can tell "version" and "state" handling is quite similar (in winfo
version is scoped to the subscription) in both cases (winfo and partial
notify) and winfo also doesn't prohibit sending new NOTIFYs if there
exists a pending NOTIFY.  

Thoughts?
- Mikko

> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of ext [email-masked]
> Sent: Friday, April 30, 2004 9:27 AM
> To: [email-masked]; [email-masked]
> Subject: RE: [Simple] WGLC: partial notification
> 
> 
> > > Aside from that I'd like for you to think through this again from 
> > > viewpoints besides active attack (use a transient 
> malfunction of the 
> > > application (above the layer that would screw up basic SIP)), I'm 
> > > ready to let this go as long as we have _a_ solid solution to 
> > > whether or not we allow overlapping ->partial<- NOTIFYs at all in 
> > > this case.
> > 
> > > 3261 and even presence-10 left sending full-state 
> presence NOTIFYs 
> > > open. We wouldn't be changing that. If an application for some 
> > > reason decided it needed to send a new full-state notify while a 
> > > partial-state notify was pending, it could. So any of the 
> arguments 
> > > for allowing it from the 3261/presence-10 are still 
> satisfied. Can 
> > > you see any use case where allowing a server to send overlapping 
> > > partial NOTIFYs is a good idea? If not, disallowing it seems a 
> > > powerful simplification.
> > >
> > 
> > I agree.
> > 
> > 	Paul
> > 
> > 
>

---

From: [email-masked]
Date: Mon, 3 May 2004 13:40:14 +0300

Hi,

Thoughts?
- Mikko

---

From: [email-masked]
Date: Mon, 3 May 2004 15:07:10 +0300

Actually, the text is described in draft-ietf-simple-winfo-format-04.txt:

"version: This attribute allows the recipient of watcherinfo
             documents to properly order them. Versions start at 0, and
             increment by one for each new document sent to a
             subscriber. Versions are scoped within a watcherinfo
             subscription. Versions MUST be representable using a 32 bit
             integer. However, versions do not wrap."

and

"The
   version number MUST be initialized with the value of the "version"
   attribute from the "watcherinfo" element in the first document
   received. Each time a new document is received, the value of the
   local version number, and the "version" attribute in the new
   document, are compared. If the value in the new document is one
   higher than the local version number, the local version number is
   increased by one, and the document is processed. If the value in the
   document is more than one higher than the local version number, the
   local version number is set to the value in the new document, the
   document is processed, and the watcherinfo subscriber SHOULD generate
   a refresh request to trigger a full state notification. If the value
   in the document is less than the local version, the document is
   discarded without processing."

If the problem exists for partial notification, then it also exists for winfo, and for any event package that defines partial state. The text quoted above to winfo is much similar to what I suggested for the use of version.

/Hisham

> From: [email-masked] [mailto:[email-masked]]On Behalf Of
> ext [email-masked]
> Sent: 03.May.2004 13:40
> To: Khartabil Hisham (Nokia-TP-MSW/Helsinki); [email-masked];
> [email-masked]
> Cc: [email-masked]

---

From: [email-masked]
Date: Mon, 3 May 2004 14:54:47 +0300

> Sent: 03.May.2004 13:56
> These scenarios are no different than what we have been 
> discussing. Version solves those problem. We have tracked a 
> little back and started questioning the need for overlapping 
> NOTIFYs. Why does disallowing overlapping partial NOTIFYs not 
> solve the problem (which is what you were suggesting)?
> 
> Christian:

This is what I was asking you to demonstrate with flows.

> case of reordered full NOTIFYs.

How can the NOTIFYs be reordered when the suggestion is that the notifier not send one before the previous one completes?

> If sender of a NOTIFY (notifier) does not get a 200 for it 
> and Timer F fires, it terminates the subscription. What is 
> the point of sending a full NOTIFY if the subscription will 
> termiante anyway?
> 
> Christian:
> Is it possible, to avoid this unnecessary termination of the 
> subscription (caused by the loss of a single packet) by an 
> additional NOTIFY? This would increase efficiency.

No. This behaviour is in RFC 3265.

/Hisham

---

From: [email-masked]
Date: Mon, 3 May 2004 15:07:10 +0300

and

"The

/Hisham

---

From: Schmidt Christian <[email-masked]>
Date: Mon, 3 May 2004 15:11:05 +0200

Hi Hisham,

thank you for the clarification (especially the hint to RFC3265, section 3.2.2). 

- Disallowing overlapping partial and allowing overlapping full NOTIFYs combined with versioning solve the problem.

- Disallowing overlapping partial allowing overlapping full NOTIFYs without versioning would not solve the problem.

>This is what I was asking you to demonstrate with flows.

Example:
----> SUBSCRIBE
<---- 200
   -- NOTIFY1 (full)
<---- NOTIFY2 (full) 
----> 200 (NOTIFY2)
<--
----> 200 (NOTIFY1)
Assume reordering of NOTIFY1 and NOTIFY2. Without version number, the user could not discover reordering.
The user would assume the contents of NOTIFY1 as actual information, but this would be wrong.

- Disallowing any overlapping NOTIFY (both partial and full) without versioning would solve the problem.

Regards,
Christian

-----Ursprüngliche Nachricht-----
Von: [email-masked] [mailto:[email-masked]] 
Gesendet: Montag, 3. Mai 2004 13:55
An: [email-masked]; [email-masked]; [email-masked]
Cc: [email-masked]; [email-masked]
Betreff: RE: [Simple] WGLC: partial notification

/Hisham

---

From: Schmidt Christian <[email-masked]>
Date: Mon, 3 May 2004 15:11:05 +0200

Hi Hisham,

Example:
----> SUBSCRIBE
<---- 200
   -- NOTIFY1 (full)
<---- NOTIFY2 (full) 
----> 200 (NOTIFY2)
<--
----> 200 (NOTIFY1)

Regards,
Christian

-----Ursprüngliche Nachricht-----
Von: [email-masked] [mailto:[email-masked]] 
Gesendet: Montag, 3. Mai 2004 13:55
An: [email-masked]; [email-masked]; [email-masked]
Cc: [email-masked]; [email-masked]
Betreff: RE: [Simple] WGLC: partial notification

/Hisham