Subject: [Sipping] Comments on draft-niemi-sipping-event-throttle-08.txt

From: Michael Froman <[email-masked]>
Date: Wed, 4 Mar 2009 10:00:10 -0600

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.

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.

---

From: Michael Froman <[email-masked]>
Date: Tue, 10 Mar 2009 10:57:38 -0500

Resending in case this got lost in the noise over the last week.

Begin forwarded message:

> From: Michael Froman <[email-masked]>
> Date: March 4, 2009 10:00:10 AM CST
> To: [email-masked]
> 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.
>
> 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.
>
> 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.
>

---

From: Robert Sparks <[email-masked]>
Date: Tue, 10 Mar 2009 11:52:06 -0500

one extra comment inline:

On Mar 10, 2009, at 10:57 AM, Michael Froman wrote:

>> 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.
>>
>> 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.
>>
>> 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 [email-masked] for questions on current sip
> Use [email-masked] for new developments of core SIP

---

From: Salvatore Loreto <[email-masked]>
Date: Wed, 11 Mar 2009 10:54:23 +0200

Hi Michale,

sorry to be late answering this mail.
see my comments in line.

Sal

Michael Froman wrote:
>> 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 
[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.

>> mechanism 
[Sal] that is exactly the point. Throttle/force/average do not break or 
modify in any way 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.
>>
>> 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?

---

From: Michael Froman <[email-masked]>
Date: Thu, 12 Mar 2009 09:24:28 -0500

Hello Sal,

Please see my comments inline.

-Michael.

On Mar 11, 2009, at 3:54 AM, Salvatore Loreto wrote:

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

---

From: Salvatore Loreto <[email-masked]>
Date: Fri, 13 Mar 2009 12:51:35 +0200

Hi,

see my comments in line

thanks
Sal

Michael Froman wrote:

<snip>
>>>> make it back to the notifier. Start with a force value of 2 
> 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 
[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.

---

From: Michael Froman <[email-masked]>
Date: Fri, 13 Mar 2009 10:08:06 -0500

Hello,

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

---

From: Salvatore Loreto <[email-masked]>
Date: Fri, 13 Mar 2009 18:01:00 +0200

in line

/sal
>>>>>> the transaction to complete before starting the 
>>>> and that is bad especially if you want use it to track the location 
>>>> of a UA,
>> 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.
> 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.

---

From: <[email-masked]>
Date: Thu, 26 Mar 2009 01:18:42 +0100

Hi,

Please see in-line with [KK]: 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of ext Salvatore Loreto
Sent: Friday, March 13, 2009 9:01 AM
To: Michael Froman
Cc: [email-masked]
Subject: Re: [Sipping] Comments on draft-niemi-sipping-event-throttle-08.txt

in line

/sal
>>>> of a UA, However making "throttle/force/average" timers independent 
>>>> (so to

[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 [email-masked] for questions on current sip Use [email-masked] for new developments of core SIP