one extra comment inline:
On Mar 10, 2009, at 10:57 AM, Michael Froman wrote:
Resending in case this got lost in the noise over the last week.
Begin forwarded message:
From: Michael Froman <mfroman@xxxxxxxxxxxx>
Date: March 4, 2009 10:00:10 AM CST
To: sipping@xxxxxxxx
Subject: Comments on draft-niemi-sipping-event-throttle-08.txt
Hello all,
I have a question/concern about the closing paragraphs of 4.2.2,
5.2.2 and 6.3.2. Each of these paragraphs deals with
retransmissions of NOTIFY requests and resetting the throttle (or
force or average) based on the completion of the previous
transaction. Given that the notifier and the subscriber can have
different ideas of when the transaction ends (up to T1 I believe),
That "up to T1" is in the _best_ case where there's no retransmission
anyhow - in a lossy network, it could be closer to 64*T1.
I want to verify the reasoning behind these paragraphs.
Is the point that throttle/force/average not break the
retransmission mechanism 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).
Thanks,
Michael.
_______________________________________________
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
