Hi, Please see in-line with [KK]: -----Original Message----- From: sipping-bounces@xxxxxxxx [mailto:sipping-bounces@xxxxxxxx] On Behalf Of ext Salvatore Loreto Sent: Friday, March 13, 2009 9:01 AM To: Michael Froman Cc: sipping@xxxxxxxx Subject: Re: Comments on draft-niemi-sipping-event-throttle-08.txt in line /sal >>>>>> the transaction to complete before starting the >>>>>> throttle/force/average timer is going to give much benefit (or >>>>>> always predictable results). >>>> [Sal] While I agree that this behaviour (waiting for the >>>> transaction to complete) can not always give "predictable" results >>>> and that is bad especially if you want use it to track the location >>>> of a UA, However making "throttle/force/average" timers independent >>>> (so to >>>> say) from the the retransmission mechanism can lead to situation >>>> where the timer fires and then you should send out a new NOTIFY >>>> when there is still a retrasmission of a previous one. Any thought >>>> on how to solve this situation without break the retransmission >>>> mechanism? >>> [MJF] Sending out a new NOTIFY while there is still a retransmission >>> of a previous NOTIFY is definitely not an optimal solution, but it >>> does not break the retransmission mechanism. It might violate a >>> particular package's rules on overlapping NOTIFYs, but that would be >>> an implementer's obligation to handle correctly. >>> >>> My primary objection is that the text in the draft seems to specify >>> exactly one way to deal with when to schedule the next NOTIFY. >>> Waiting for the response to the NOTIFY before scheduling the time >>> for the next NOTIFY is an expensive operation with virtually no >>> benefit under normal operation. If the network is working well, the >>> NOTIFY/200OK happens effectively immediately and there is no real >>> value in waiting to start the throttle/force/average timing until >>> the transaction closes. The timer can start when the NOTIFY goes out. >> [Sal] right, but as usual in the ideal situation you do not have >> problems. I do think that your suggestion of starting the timer when >> the NOTIFY goes out, it a good idea and would improve the mechanism. >> However before to change the text I would like to investigate and >> discuss deeper the possible side effects. >> >>> If the network isn't working well, both sides are receiving and/or >>> sending messages they'd rather not deal with. Setting the timer >>> prior to the transaction completing doesn't make the situation >>> appreciably worse. Because the server cannot accurately determine >>> the client's view of when the transaction ends during network >>> misbehavior, this method is guaranteed to produce results confusing >>> to the user. >> [Sal] if the server sends out a new NOTIFY before the previous one is >> acknowledged could be worse in some situation, I am thinking of the >> cases where a NOTIFY contains a state deltas. In this scenario (that >> I think it will be the most common) if a NOTIFY is received out of >> order the the Subscriber has to re-subscribe to force a NOTIFY >> containing a complete state. > [MJF] Agreed. This is a decision the package implementor can make as > long as the draft doesn't specify the exact method for when to start > the timer for the next NOTIFY. In event packages that do not allow > overlapping NOTIFYs, the implementor would be free to devise a > mechanism for scheduling the next NOTIFY in a way that both satisfies > the event package rules and produces satisfactory > throttle/average/force behavior. Maybe this calls for adding a warning > that when creating the NOTIFY timer mechanism care should be taken to > remain consistent with the supported event package. [Sal] but in that case you should implement on the server a specific timer mechanism different for each event package. It would be better have a general mechanism that work independently from the specific event package, it would be also make the implementation easier. An alternative would be start the timer just after having send out a Notify, but then, even if the timer fires, wait for the completion of the transaction before create the new Notify and sending it out. [KK] I tend to agree with Michael. It may be difficult to come up with a general mechanism here. Depending on package rules and whether partial notifications are used or not there seem to be different priorities. For partial notifications it is probably more important that the sequence of notifications do not break than perfect throttle/average/force behavior, so it's better to wait with creating a new notification transaction before the previous one is closed. OTOH when overlapping, full state notifications are allowed by the package, there's no reason to delay the new notification even if the previous is still pending in order to satisfy the throttle/average/force parameters. I'd agree that the draft should not specify the exact method for when to start the throttle/force/average timer for the next NOTIFY. Cheers, Krisztian _______________________________________________ Sipping mailing list https://www.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@xxxxxxxxxxxxxxx for questions on current sip Use sip@xxxxxxxx for new developments of core SIP _______________________________________________ Sipping mailing list https://www.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@xxxxxxxxxxxxxxx for questions on current sip Use sip@xxxxxxxx for new developments of core SIP
