Subject: RE: [Simple] WGLC: partial notification

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

> -----Original Message-----
> From: ext Schmidt Christian [mailto:[email-masked]]
> Sent: 03.May.2004 13:56
> 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,
> > 
> > please see my comments in the text,
> > 
> > best regards
> > Chrisitan
> > 
> > 
> > 
> > > Hi Hisham,
> > > 
> > > this proposal would not solve the problem with a missing 
> > > NOTIFY (full or partial). 
> > 
> > Can you demonstrate why with some flows?
> > 
> > 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)?
> 
> Christian:
> Disallowing overlapping partial NOTIFYs combined with 
> versioning solve the problem.
> Disallowing overlapping partial NOTIFYs without versioning 
> would not solve the problem.

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

> The version attribute, you need anyway to avoid mistakes in 
> 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?

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

> /Hisham
> > /Hisham

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

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 03 May 2004 10:27:51 -0400

>>additional NOTIFY? This would increase efficiency.

The normal retransmission mechanisms are still in effect. If the notify 
or its response is lost, the notifier will retransmit it. Its only after 
the retransmissions have been tried to no avail that the subscription is 
terminated. Or am I missing something?

	Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 03 May 2004 10:27:51 -0400

Paul