Hello Sal,
Please see my comments inline.
-Michael.
On Mar 11, 2009, at 3:54 AM, Salvatore Loreto wrote:
Hi Michale,
sorry to be late answering this mail.
see my comments in line.
Sal
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),
I want to verify the reasoning behind these paragraphs.
[Sal] here the last paragraph
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 is reset only after the
previous transaction has completed.
Is the point that throttle/force/average not break the
retransmission mechanism
[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. 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.
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
