Re: Comments on draft-niemi-sipping-event-throttle-08.txt

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hello,

Please see my comments inline.

Thanks,
Michael.

On Mar 13, 2009, at 5:51 AM, Salvatore Loreto wrote:

<snip>
Hi,

see my comments in line

thanks
Sal


Michael Froman wrote:

<snip>
[Sal] that is exactly the point. Throttle/force/average do not break or modify in any way the retransmission mechanism.
[MJF] Perfect. I think your statement here is far more clear than the last sentence of the paragraph you quoted above. More on this below.


or that, for example, retransmissions modify the time between forced NOTIFYs by the time taken for the retransmissions to successfully complete the transaction? An example is the case when the NOTIFY gets to the subscriber quickly, but the 200OK is slow to make it back to the notifier. Start with a force value of 2 seconds. The subscriber thinks the transaction is over and is now expecting a forced NOTIFY 2 seconds from now. The notifier has not completed the transaction. The next NOTIFY from the notifier can happen anytime up to T1 + 2 sec.

I agree that throttle/force/average should not interfere with the normal retransmission mechanism. However, I don't agree that waiting for 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.




I would suggest the following text replace the last paragraph of 4.2.2 (and similar changes to 5.2.2 and 6.3.2):

Retransmissions of NOTIFY requests are not affected by the throttle,
i.e., the throttle only applies to the generation of new
transactions. In other words, the throttle does not in any way
break or modify the normal retransmission mechanism.

This allows the implementor to decide, possibly based on package considerations and network traffic, how to schedule the time of the next NOTIFY.




_______________________________________________
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

[Index of Archives]     [IETF Announce]     [IETF Discussion]     [Linux SCSI]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [XFree86]     [Big List of Linux Books]

  Powered by Linux