Subject: [sipcore] RFC4028 : Very basic question in 8.1

From: OKUMURA Shinji <[email-masked]>
Date: Thu, 9 Jul 2020 22:09:40 +0900

Hi,

This is very basic question.

Why must a proxy not increase SE-value?

1. UA sends INVITE(SE:100)
2. proxy rejects INVITE with 422(MSE:200)
3. UA sends INVITE again.(SE:200)
4. proxy forwards INVITE(SE:200)

+-----+             +-------+            +-----+
| UA1 |             | Proxy |            | UA2 |
+-----+             +-------+            +-----+
    |                    |                   |
    | INVITE(SE:100)     |                   |
    |------------------->|                   |
    |                    |                   |
    |       422(MSE:200) |                   |
    |<-------------------|                   |
    |                    |                   |
    | INVITE(SE:200)     |                   |
    |------------------->|                   |
    |                    |                   |
    |                    | INVITE(SE:200)    |
    |                    |------------------>|

If proxy may increase SE-value,
1. UA sends INVITE(SE:100)
2. proxy forwards INVITE(SE:200)

+-----+             +-------+            +-----+
| UA1 |             | Proxy |            | UA2 |
+-----+             +-------+            +-----+
    |                    |                   |
    | INVITE(SE:100)     |                   |
    |------------------->|                   |
    |                    |                   |
    |                    | INVITE(SE:200)    |
    |                    |------------------>|
    |                    |                   |

Needless to say, this sequence is much simpler.

Regards,
Shinji

---

From: Roman Shpount <[email-masked]>
Date: Thu, 9 Jul 2020 09:17:04 -0400

Shinji,

This is a negotiation where all parties (UAC, UAS and proxies on path) must
agree on the session timer value. Min-SE is the minimum allowed value. SE
is the maximum allowed value. If Proxy needs a higher SE interval, it needs
to renegotiate maximum allowed session timer value with all the parties
upstream. This is why it rejects the request with 422 and a higher Min-SE
value.

BTW, there is no guarantee that session timer negotiation will succeed. In
general case it is possible that session timer requirements for all the
proxies UAC and UAS cannot be satisfied at the same time.

Once again, may I ask, what is your motivation for proposing this change?
Are you seeing an issue with a deployment somewhere?
_____________
Roman Shpount

On Thu, Jul 9, 2020 at 9:10 AM OKUMURA Shinji <[email-masked]> wrote:

> _______________________________________________
> sipcore mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sipcore
>

---

From: OKUMURA Shinji <[email-masked]>
Date: Thu, 9 Jul 2020 23:42:24 +0900

Roman,

I haven't proposed a fix for this YET. This is a pure question at this point in time.

> SE is the maximum allowed value.

UAC can send again with a greater Session-Expires and Min-SE. The proxy CAN NOT reject the INVITE just because "Session Interval Too Large". Therefore SE isn't the maximum allowed value.

> If Proxy needs a higher SE interval, it needs to renegotiate maximum allowed session timer value with all the parties upstream.

If Proxy needs a higher SE interval, the proxy need only increase SE-value. This procedure definitely works. Because this is the very procedure for when the UAC does not support timer.
Again, proxies can't reject the INVITE just because the timer is too large.

> Once again, may I ask, what is your motivation for proposing this change?

My motivation is that bis become to be more clear and error-free.

> Are you seeing an issue with a deployment somewhere?

No, You seem to attach great importance to that point, but I don't understand the importance of that.
Do you argue that it is enough for each developer to address any issues on their own?

Regards,
Shinji

---

From: Roman Shpount <[email-masked]>
Date: Thu, 9 Jul 2020 11:15:58 -0400

On Thu, Jul 9, 2020 at 10:42 AM OKUMURA Shinji <[email-masked]>
wrote:

> UAC can send again with a greater Session-Expires and Min-SE. The proxy
> CAN NOT reject the INVITE just because "Session Interval Too Large".
> Therefore SE isn't the maximum allowed value

Why do you think it cannot? Proxy can reject a new INVITE for any reason it
sees fit.

> .> If Proxy needs a higher SE interval, it needs to renegotiate maximum
> allowed session timer value with all the parties upstream.
>
> If Proxy needs a higher SE interval, the proxy need only increase
> SE-value. This procedure definitely works. Because this is the very
> procedure for when the UAC does not support timer.

The higher SE interval value might be too high for proxies upstream. Your
procedure breaks it. Again, proxies can reject INVITE for any reason.

> My motivation is that bis become to be more clear and error-free.

I have zero interest in this. Session Timer (and most of SIP related
specifications) are effectively legacy specifications in maintenance mode.
You need to show serious reasons to introduce major changes at this point.

> Do you argue that it is enough for each developer to address any issues on

I am arguing that this is an old and widely deployed specification.  It
might not be clearly written but it is widely implemented which resulted in
some general consensus on how it is supposed to work. Making changes to it
is dangerous unless they are targeting specific issues.

There is something to be said about redoing the entire SIP specification to
be clearer and more logical, but this would be a different and much bigger
effort. Also, I do not see that enough people have interest in doing and,
what is much more important, implementing this new SIP specification. I
understand your desire in cleaning up the Session Timer specification, but
it would effectively render the resulting document irrelevant due to most
people refusing to implement changes which are too great.

Best Regards,
_____________
Roman Shpount

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 9 Jul 2020 11:36:45 -0400

On 7/9/20 9:17 AM, Roman Shpount wrote:
> Shinji,
> 
> This is a negotiation where all parties (UAC, UAS and proxies on path) 
> must agree on the session timer value. Min-SE is the minimum allowed 
> value. SE is the maximum allowed value. If Proxy needs a higher SE 
> interval, it needs to renegotiate maximum allowed session timer value 
> with all the parties upstream. This is why it rejects the request with 
> 422 and a higher Min-SE value.

What is the point of session timer?

It is to use traffic on the session to verify liveness of the session 
and of the parties on the path. This pertains to both UAs and proxies, 
but their needs differ in some respects:

1) proxies can't initiate traffic; they must depend on observing traffic 
generated by the UAs. So they have an interest in requesting that the 
UAs send traffic with some minimum frequency.

2) UAs can test liveness any time they want by sending a request, 
without need of session timers. But if both ends do this independently 
then there may be more traffic than necessary, and possibly glare. ST 
negotiations allow them to find a mutually agreeable keep-alive interval 
and refresher, minimizing overhead.

The negotiation process allows all the parties to express an opinion. It 
works by ratcheting up the minimum value and ratcheting down the maximum 
value to find a mutually agreeable value between. No party is allowed to 
increase the max or decrease the min.

The purpose of Min-SE is to limit the overhead caused by ST refreshes 
when there otherwise would be no traffic. (Aside from this there would 
be no need for Min-SE.) The benefit of ST falls mostly to the proxies, 
while the cost is typically heavier on the UAs. So the Min-SE is 
primarily for the purpose of protecting the UAs from excessive demands 
by proxies.

> BTW, there is no guarantee that session timer negotiation will succeed. 
> In general case it is possible that session timer requirements for all 
> the proxies UAC and UAS cannot be satisfied at the same time.

Yes.

If, at the end of the negotiation, Min-SE and SE are higher than one of 
the UAs desires, it is still free to send extra traffic to test liveness 
more often than the ST refreshes do.

If the Min-SE and SE are higher than one of the proxies desires, then it 
is pretty much out of luck. In some sense this is futile for it to 
complain because the timer refreshes are only part of the traffic. The 
UAs may send other traffic at a rate the proxy doesn't like, and there 
is little it can do about that. It can try the 422 route, but only if it 
would prefer no session over a session with more traffic.

	Thanks,
	Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 9 Jul 2020 11:48:16 -0400

On 7/9/20 11:15 AM, Roman Shpount wrote:

> might not be clearly written but it is widely implemented which resulted 
> in some general consensus on how it is supposed to work. Making changes 
> to it is dangerous unless they are targeting specific issues.

I have been fielding questions about this rfc for almost two decades. 
Based on that there is widespread misunderstanding of it.

I think it would be very helpful to at least add some overview 
discussion of what this mechanism is good for and what it is not good 
for. Something along the lines of what I put in my prior reply.

	Thanks,
	Paul

---

From: Roman Shpount <[email-masked]>
Date: Thu, 9 Jul 2020 12:15:08 -0400

> for. Something along the lines of what I put in my prior reply.

I would definitely agree to that. An informational, non-normative section
in the RFC overview can help a lot.

What I am trying to avoid is ending up with a non-obvious set of changes to
an existing specification which will act as a barrier to implementation.
Letting proxies increase SE would be an example of such change.
_____________
Roman Shpount

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 9 Jul 2020 13:11:33 -0400

On 7/9/20 12:15 PM, Roman Shpount wrote:
> On Thu, Jul 9, 2020 at 11:48 AM Paul Kyzivat <[email-masked] 
> <mailto:[email-masked]>> wrote:
> 
>      >     No, You seem to attach great importance to that point, but I
>     don't
>      >     understand the importance of that.
> I would definitely agree to that. An informational, non-normative 
> section in the RFC overview can help a lot.

That would satisfy me.

> What I am trying to avoid is ending up with a non-obvious set of changes 
> to an existing specification which will act as a barrier to 
> implementation. Letting proxies increase SE would be an example of such 
> change.

Upon rereading 4028 I was surprised to discover that proxies MAY 
increase SE to the extent necessary to conform with an increased Min-SE! 
I hadn't remembered that part. But AFAIK that is the only case where it 
is allowed.

	Thanks,
	Paul

---

From: OKUMURA Shinji <[email-masked]>
Date: Fri, 10 Jul 2020 23:56:28 +0900

Paul,

On 2020/07/10 0:48, Paul Kyzivat wrote:
> I have been fielding questions about this rfc for almost two decades. Based on that there is widespread misunderstanding of it.

I have also received an answer from you.
If we don't take this opportunity to correct the ambiguity in the text, the same question will continue for another two decades.

> I think it would be very helpful to at least add some overview discussion of what this mechanism is good for and what it is not good for. Something along the lines of what I put in my prior reply.

I agree.

Regards,
Shinji

---

From: OKUMURA Shinji <[email-masked]>
Date: Fri, 10 Jul 2020 23:56:46 +0900

On 2020/07/10 2:11, Paul Kyzivat wrote:
>> What I am trying to avoid is ending up with a non-obvious set of changes to an existing specification which will act as a barrier to implementation. Letting proxies increase SE would be an example of such change.
> 
> Upon rereading 4028 I was surprised to discover that proxies MAY increase SE to the extent necessary to conform with an increased Min-SE! I hadn't remembered that part. But AFAIK that is the only case where it is allowed.

In fact, proxy is conditionally allowed to increase SE directly without renegotiation. And RFC does not specify the procedure to reject if too large.
This is why I interpret the RFC does not attach importance to increase of SE.

And you said,
> If the Min-SE and SE are higher than one of the proxies desires, then it is pretty much out of luck. In some sense this is futile for it to complain because the timer refreshes are only part of the traffic.

So, I want to know why must a proxy not increase SE-value?
I think this is a very basic and important premise of RFC, but there is no specific explanation.
I say again, this is not a suggestion, but a question.

Regards,
Shinji

---

From: OKUMURA Shinji <[email-masked]>
Date: Fri, 10 Jul 2020 23:58:15 +0900

Hi,

> Why do you think it cannot? Proxy can reject a new INVITE for any reason it

Generally correct, if proxies don't care about UAC. I should have said:
"the proxy cannot usefully reject the request, as this would result in a call failure."

> You need to show serious reasons to introduce major changes at this point.

Unfortunately, it seems that your empathy has not been obtained.
But for me, confusable or wrong regulations are enough reasons for correction.

> some general consensus on how it is supposed to work.

If there is no documented procedure and each developer deals with the issue independently, how is interoperability guaranteed? What is "some general consensus on how it is supposed to work"?
Are you not interested in considering the mysterious procedure in this WG?

> Making changes to it is dangerous unless they are targeting specific issues.

ISTM you think most change is dangerous, but I don't think so.

> people refusing to implement changes which are too great.

My suggestions isn't as great as you think.

For example, assuming we modified the regulation so that the 2xx response has an MSE header,
even if one of UAC, UAS and proxy behaves according to the old regulations, no serious problems will occur. This is backward compatible.

Regards,
Shinji

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 10 Jul 2020 11:26:24 -0400

On 7/10/20 10:56 AM, OKUMURA Shinji wrote:
>>> What I am trying to avoid is ending up with a non-obvious set of 
>>> changes to an existing specification which will act as a barrier to 
>>> implementation. Letting proxies increase SE would be an example of 
>>> such change.
>>
>> increase SE to the extent necessary to conform with an increased 
>> Min-SE! I hadn't remembered that part. But AFAIK that is the only case 
>> where it is allowed.
> 
> In fact, proxy is conditionally allowed to increase SE directly without 
> renegotiation. And RFC does not specify the procedure to reject if too 
> large.

Where do you find this in 4028.

>> If the Min-SE and SE are higher than one of the proxies desires, then 
>> it is pretty much out of luck. In some sense this is futile for it to 
>> complain because the timer refreshes are only part of the traffic.
> 

If proxies along the path (and the UAS) could both increase and decrease 
the value of SE, then you don't have a negotiation. Rather, those 
further along the path have priority over the earlier ones.

By having both SE and Min-SE, with SE only being reduced and Min-SE only 
increased, everybody on the path has input into the final result.

	Thanks,
	Paul

---

From: OKUMURA Shinji <[email-masked]>
Date: Sat, 11 Jul 2020 13:11:00 +0900

Hi,

> Where do you find this in 4028.

P.13
    If the value of the Session-Expires header field is lower
    than the value of the Min-SE header field (possibly because the proxy
    increased the value of the Min-SE header field, as described below),
    the proxy MUST increase the value of the Session-Expires header field
    to make it equal to Min-SE header field value.

Of course, negotiation with downstream proxies and UAS will occur.

> If proxies along the path (and the UAS) could both increase and decrease the value of SE, then you don't have a negotiation. Rather, those further along the path have priority over the earlier ones.
> 
> By having both SE and Min-SE, with SE only being reduced and Min-SE only increased, everybody on the path has input into the final result.

I understand the basic policy, but when the UAC that received the 422 response retransmits the INVITE with a larger SE and MSE set, the proxy cannot reduce the SE. I think the result will be the same as if the proxy increased SE.

Regards,
Shinji

---

From: Paul Kyzivat <[email-masked]>
Date: Sat, 11 Jul 2020 16:15:01 -0400

On 7/11/20 12:11 AM, OKUMURA Shinji wrote:
>>>> Min-SE! I hadn't remembered that part. But AFAIK that is the only 
>>>> case where it is allowed.
>>>
>>> In fact, proxy is conditionally allowed to increase SE directly 
>>> without renegotiation. And RFC does not specify the procedure to 
>>> reject if too large.
>>

OK. But that only allows increasing up to the value of Min-SE. It 
doesn't otherwise allow increasing SE.

>>>> If the Min-SE and SE are higher than one of the proxies desires, 
>>>> then it is pretty much out of luck. In some sense this is futile for 
>>>> it to complain because the timer refreshes are only part of the 
>>>> traffic.
>>>
>> If proxies along the path (and the UAS) could both increase and 
>> decrease the value of SE, then you don't have a negotiation. Rather, 
>> those further along the path have priority over the earlier ones.
>>
>> By having both SE and Min-SE, with SE only being reduced and Min-SE 
>> only increased, everybody on the path has input into the final result.
> 
> I understand the basic policy, but when the UAC that received the 422 
> response retransmits the INVITE with a larger SE and MSE set, the proxy 
> cannot reduce the SE. I think the result will be the same as if the 
> proxy increased SE.

But this requires that the 422 be issued, and that the UAC be willing to 
retry with the values it contains. Until we get to this point everybody 
gets to have their vote counted.

The bottom line is that when there is a conflict, with some parties 
requiring that SE be larger and some requiring it to be smaller, the 
larger preference wins. This is effectively valuing efficiency of 
processing over cost of saving state longer, or if you prefer, valuing 
UAs over proxies.

But this tradeoff only occurs if there is no happy medium that all can 
live with.

	Thanks,
	Paul

---

From: Roman Shpount <[email-masked]>
Date: Sat, 11 Jul 2020 18:27:19 -0400

> doesn't otherwise allow increasing SE.

This is a very specific case where UAC does not support Session-Timer. In
other cases proxy should not increase Min-SE over the value of
Session-Timer and should fail the request with 422. It is not the reason to
drop session timer negotiation when both UA actually support this.

_____________
Roman Shpount