Dale Worley wrote:
> First, a reply, but after that, I've tried to think through these
> issues again:
>
> From: "Michael Procter" <[EMAIL PROTECTED]>
>
> I'm not convinced by this argument. This would imply that only certain
> NOTIFYs can shorten the duration (namely ones immediately following
> SUBSCRIBEs) but not others, which seems odd.
>
> I'm modeling things differently than you are. I expect NOTIFYs to
> always report the *notifier's* idea of when the subscription ends.
I think that is clearly true. Each side is talking in terms of *its*
timer, and its hoped that there isn't too much skew in the clock rates
or delay in the messages to mess things up.
But its not at all clear that the reductions in value reported by the
notifier are restricted to the passage of time. At least there is
nothing I can find that suggests that.
It appears to me that there is a discipline here: the watcher proposes a
value, and the notifier can reduce, but not increase the value. That is
true of the initial subscription and its response, and of the NOTIFYs as
well. Once the clock is first set, it counts down on both sides as
hopefully a consistent rate. Notifications would typically report the
current value of the clock, but seemingly can reduce it.
> When the notifier receives a SUBSCRIBE, it can increase the end-time
> as far as it likes, up to the time allowed by the SUBSCRIBE.
That is funny wording, but I agree with what I think you mean. I quibble
with the word "increase". The notifier can accept any value up to but
not greater than what was proposed in the subscribe. If it was a
resubscribe, then the proposed value may be greater, or less, than the
"current" counting value. If the proposed value was greater than the
current value, then the value the notifier chooses may also be greater
or less than the current value. If the proposed value is less than the
current value, then of course the new accepted value is limited by that.
> The exception is that the notifier is allowed to reduce the
> subscription time to zero, that is, to terminate the subscription, and
> immediately send a NOTIFY. (As well as a SUBSCRIBE that terminates
> the subscription.)
How is this an exception?
Lets use some numbers. Assume an initial SUBSCRIBE was sent with a value
of 1800s, and the response also contained 1800s. Lets assume the
notifier starts its clock running when it sends the 200 OK, and the
subscriber starts its clock say one second later when it receives the
200 OK.
The notifier immediately sends a NOTIFY with the same value of 1800. It
happens to arrive two seconds after the 200 OK. The subscriber has its
own current value of 1798, and a NOTIFY with 1800s. But the NOTIFY is
only supposed to reduce the value, not increase it. So the subscriber
doesn't update its clock - instead it leaves it as-is. (At the time it
is doing that the notifier's clock also reads 1798s.)
Some time later, say when the value of the clock is 1000s, the notifier
may send a notify. As I read it, the value in this notify can be
anything in the range 0-1000s. Presumably that only updates the current
time of the notifier if there is a 200 response to it. I don't know if
the clock is reset at the sending of the notify or the receipt of the
response. For now lets assume it leaves it at 1000s.
When its clock gets down to 200s, the subscriber decides to refresh. It
sends a resubscribe, again with a value of 1800. So for it, the current
value is 200s and the proposed value is 1800s.
One second later the notifier receives it. For it the current value is
199s, and the proposed value is 1800s. So what are the notifiers options
here for the value in the 200 OK?
- I think it can return any value between 0 and 1800.
- I *think* Dale believes it can return either a value between 199 and
1800, or zero.
Of those I prefer my answer because it is simpler, fewer special cases,
etc. And I can think of no benefits to the more complex answer.
So lets consider some alternative next steps:
- the notifier could reject the request. For instance, it could return
a 401 response. In that case, the proposed new time is irrelevant.
the current times remain in effect on both sides.
- the notifier could decide to terminate the subscription at that
time. To do so, it may set the expiration to zero in the 200 ok,
and send a final notify indicating the subscription is terminated.
(That won't have an expires value.)
- the notifier could decide to accept the proposed new value.
So it would set the value to 1800s in the response, and set its
current value the same. It would subsequently send a notify also
containing the current value. When the subscriber receives the 200 ok
it will note the value is consistent with what was proposed, and so
will set its current value to that as well. If it receives the notify
two seconds later (when the current value is again 1798) it will
find the value too large, and so should ignore it.
- the notifier could decide to accept the proposed new value.
So it sets the value to 1800s in the response, and sets its
current value to the same. It also sends a notify also containing
that current value. But for some reason the notify reaches the
subscriber before the response does. Here there is a question:
should the subscriber decide to accept the value in the notify
based on the proposed new value? Or should it ignore the value
based on it exceeding the current value? I think it probably
makes more sense to always evaluate the notify based on the
current value. So the notify will be ignored. When the subscriber
receives the 200 ok it will note the value is consistent with what
was proposed, and so will set its current value to that.
- the notifier could decide to accept the proposed new value.
So it sets the value to 1800s in the response and sets its
current value the same, and sends the response. When it prepares
the notify, it decides, on whim, to reduce the value to 900.
So it sends the notify with 900s and sets its current value
to that. When the subscriber receives the 200 ok it will note
the value is consistent with what was proposed, and so it will
set its current value to that as well. When it receives the
notify, it will find the new value of 900s to be consistent
with its current value, and so will update its current value
to that.
- the notifier could decide to accept the proposed new value.
So it sets the value to 1800s in the response and sets its
current value the same, and sends the response. When it prepares
the notify, it decides, on whim, to reduce the value to 900.
So it sends the notify with 900s and sets its current value
to that. For some reason the notify arrives first. The
subscriber notes that the new value exceeds the current
value, so it ignores it. When the 200 ok arrives, that is
found ok and accepted, so the current value is set to 1800s.
But the notifier's value is 900s. This is bad, because now
the subscription will expire before the subscriber is
motivated to refresh it.
When the subscriber receives the 200 ok it will note
the value is consistent with what was proposed, and so it will
set its current value to that as well. When it receives the
notify, it will find the new value of 900s to be consistent
with its current value, and so will update its current value
to that.
- the notifier could decide to accept the proposed new value.
So it sets the value to 1800s in the response, and sets its
current value to the same, and sends the response. It then
gets ready to send the notify, but discovers that the resource
being monitored has changed state so that the subscription should
be terminated. It sends a final notify with state set to terminated.
(Has no expires.) When the subscriber receives the 200 ok it will
set its curret value to that. When it receives the notify it
tears down the subscription.
- the notifier could be non-conforming, and decide to return a value
of 3600s. It would set its current value to that, and return it,
and send a notify with it. When the subscriber receives the response,
it will note that it exceeds the proposed value. There is no guidance
on what to do in this case. I think the best that can be done is to
use the proposed value of 1800s as the new current value. Then, when
the notify is received two seconds later, it will exceed the then
current value of 1798, so it too will be ignored. At that point the
notifier will have a value of 3598. Because the subscriber's value
is less than that of the notifier, it will be certain to refresh
before the value at the notifier expires.
- the notifier could decide it can't handle the resubscribe at this
time. It returns a 503 response. It doesn't update the current clock
value. When the subscriber receives the response, it forgets the
proposed value, leaves the current clock value alone and continues.
It will still see a need to refresh the subscription, and so may
retry at some later time.
- the notifier could decide to accept the proposed new value.
It sends the notify first, with that value in it. Then, as it
prepares to send the response, it decides there is a problem
that prevents continuing the subscription. It returns a 503
response. When the subscriber receives the notify it finds the
value exceeds the current value, so it ignores it. When it
subsequently receives the 503 it doesn't update the current
clock value and forgets the proposed value. It will still try
to refresh later. (Note that if the value in the notify had
been evaluated based on the proposed value, the clock would
now be messed up and the refresh would not occur in time.)
This seems to be a non-conforming case.
There may be other interesting cases, but I'm tired.
One important case doesn't fit into the above scenario. That is when an
initial subscribe is sent, and a notify is received before the response.
(This can be simply an ordering thing, or it can be because of forking
where there will be no response.) It seems to require some special handling.
Clearly there has to be a separate current value for every fork. And
clearly how many and which ones are required isn't known at the time the
initial request is sent. So, I think that each current value clock must
be established at the time the first message is received for a dialog,
whether that is the 200 ok or a notify. At that time, the current value
can be set to the proposed value, and then all the steps above applied.
That way the current value will be there to test against the value in
the notify.
>>From this point of view, NOTIFYs (other than termination NOTIFYs)
> never shorten the duration -- or rather, never report a shortening of
> the duration.
>
> Indeed, I think the crucial question is "Who is the authoritative
> keeper of the subscription duration?" I take it that it is the
> notifier. Others seem to assume that it is the subscriber.
IMO they are both keepers, and are attempting to synchronize.
What is key is that the subscriber is the only one that can propose, and
hence permit, an increase. But it is the only the notifier that can
accept an increase. OTOH, the notifier can declare a decrease at any time.
> I model
> that the subscriber is attempting to remotely manipulate the
> subscription duration, and receives occasional updates as to what the
> subscription duration *is*.
>
> My model does get us out of the quandary of how to resolve multiple
> updates of the subscription -- take the max of the values seen in
> NOTIFYs so far.
The problem with this is that it isn't robust in the face of a
non-conforming notifier. Without some kind of tempering, this allows the
notifier to extend the expiration time without permission of the subscriber.
> The only race condition is if a re-SUBSCRIBE is in
> flight at the same time a NOTIFY is received that terminates the
> subscription. But the subscriber then knows that the subscription is
> ended, as the notifier has sent word that it has ended, and a late
> re-SUBSCRIBE can never revive a terminated subscription.
>
> Secondly, in section 3.2.4, the behaviour of the recipient of the NOTIFY
> is defined, which includes:
>
> If the header also contains an "expires" parameter, the subscriber
> SHOULD take it as the authoritative subscription duration and adjust
> accordingly.
>
> There are no qualifiers about which NOTIFYs should be taken as
> authoritative, suggesting that all NOTIFYs are created equal in this
> respect, and should be treated as such by the subscriber.
>
> Finally, there is the difficulty in identifying when the duration has
> actually been shortened, rather than an apparent change due to clock
> drift.
>
> I think that on balance, we can only assume that the phrase 'shorten a
> subscription' means just that - to shorten it. No further
> qualifications seem to be implied or can safely be inferred.
>
> I've read through Michael's and Paul's messages, and I think I need to
> change my position. But that interacts with some issues that are
> obscuring the discussion as well.
>
> First, we need to keep our terminology straight. I think everyone
> agrees that the real keeper of the expiration time of the subscription
> is the notifier. The subscriber proposes new expiration times, and
> attempts to remain aware of what the current expiration time is. This
> point is just linguistic, but I think that in a few places people have
> been getting confused by not keeping these distinctions in mind.
> E.g., a NOTIFY can never "shorten a subscription time", it can only
> report a subscription time that has been shortened, and it can reduce
> the subscriber's idea of the subscription time.
>
> My position has been that the notifier can terminate the subscription
> at any time, and that it can extend the subscription upon processing a
> re-SUBSCRIBE, but cannot otherwise modify the subscription time, in
> particular, it can't shorten it without terminating it. Going back
> and reading 3.2.2, I think that RFC 3265 disagrees from me.
>
> But as people have pointed out, if the notifier can shorten a
> subscription, processing a NOTIFY that is close in time to the
> response to a re-SUBSCRIBE is ambiguous. (Whereas if a notifier
> cannot shorten a subscription, then processing is not ambiguous.)
>
> Hmmm, and there is the further problem of a re-SUBSCRIBE that requests
> less time than the current expiration time.
>
> The underlying problem is that the subscriber is receiving a series of
> notifications of a remote state (the subscription time), and the
> transport is not ordering the notifiactions (viz., the 2xx responses
> to SUBSCRIBEs vs. the NOTIFYs). Such situations always lead to race
> conditions unless the time-evolution of the state is arranged so that
> notifications can be unambiguously composed regardless of the order in
> which they are received.
>
> My proposal is to narrow RFC 3265 so that the composition rule is
> "take the max, but termination dominates all", which requires that the
> expiration time never be reduced. I admit that is not what RFC 3265
> says, but without a rule like that, eliminating the race condition
> cannot be done.
There is a lot above, but I don't quiet know what to say to it right
now. I think we are both trying to sort out an ambiguous case, and are
getting to different ways of doing so. What dale is proposing does, I
think, *work* but does require some small normative changes to 3265.
I think what I am proposing also *works*, but in a slightly different
way, without requiring any normative changes. There is one case
mentioned above where this leads to a bad result even though all
behavior is conforming. And it is a weird case.
I kind of like what Dale is proposing, but it does require the hassle of
a normative change.
Paul
_______________________________________________
Sip-implementors mailing list
[email protected]
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
