Subject: Re: [Insipid] draft-ietf-insipid-session-id-14: comments and questions

From: Brett Tate <[email-masked]>
Date: Tue, 5 Jan 2016 12:51:39 -0500

Hi Paul,

Thanks for the response and welcome to the discussion.  Reply is inline.

> I propose a simpler solution that should address your
> concerns and make it easy for implementers to understand
> what should be done in these scenarios. This would
> require a slight modification to the draft as it stands
> today. I am therefore seeking your and the working group’s
> approval to move forward with this change. If we can all
> agree on this in concept, I will put together some
> concrete text for inclusion in the draft.

To get more feedback, you might need to raise the topic in a new thread.

> In a nutshell, I propose that we make a minor change to
> the text to explicitly call out the conditions under
> which a UUID should be stored by endpoints and
> intermediaries. I propose that an endpoint or intermediary
> only store an updated remote UUID under the following
> conditions:
>
> When receiving a request (other than ACK) that is accepted
> (results in a 1XX or 2XX response), the received UUID must
> be retained. If the request results in any other kind of
> response, it should not be retained. This can, of course,
> lead to conditions where a request is received, a
> provisional response is sent (and therefore the UUID is
> retained) and then for whatever reason, an error
> (4XX/5XX/6XX) or redirect (3XX) response is sent. In such
> a case, we will never “roll back” the Session ID.

Concerning the mentioned "1xx", you might want to exclude 100 since 100
isn't end-to-end (even if using proxies instead of B2BUAs).  For instance if
100 is only sent between two of the intermediaries, a resulting 500 response
doesn't mean that everyone agrees that the uuid actually changed.  However,
I guess that the same could be said for all non-reliable 1xx since a 18x
sent by endpoint could be dropped (or received after 500).

You might want to distinguish between a ACK-for-2xx versus ACK-for-non-2xx.
Some within the SIP working groups prefer to allow ACK-for-2xx to update
things.  For instance, see draft-ietf-insipid-session-id-16 section 9.7; the
3pcc sends the updated uuid within the ACK.

The proposal currently appears to violate (or alter) RFC 3261 section 8.2:
"If it is rejected, all state changes MUST NOT be performed".  Similarly it
also appears to impact the following RFC 6141 section 3.3 SHOULD: "If any of
the changes requested in a re-INVITE or in any transaction within it have
already been executed, the UAS SHOULD return a 2xx response".

You might want to exclude CANCEL and its 2xx response from the algorithm
(although decision might be influenced by decision concerning 100 response).
CANCEL and related 2xx response are not end-to-end (even if using proxies
instead of B2BUAs).

> The only additional rule for stateful intermediaries is
> that if they accept a request and then forward that request
> to another destination (therefore there was no error found
> with the message), this will also trigger the intermediary
> to update the retained UUID.

The proposal means that not all of the devices will necessarily agree if a
uuid changed during failure situation.

Concerning "therefore there was no error found" statement, be aware that
forwarding a request does not necessarily mean that no error was found (i.e.
device can be lenient) or that the request won't eventually be rejected
(with 400 or other failure response).

> The remote UUID in all responses must match the UUID
> received in the request if the SIP stack is able to process
> the Session-ID header. This applies even if the UUID is not
> going to be retained. If a re-INVITE {C,B} contains an
> error but the Session-ID is successfully extracted from the
> re-INVITE, the 4XX response should contain {B,C} (assuming
> the receiving endpoint is still using B as the local UUID.
> Otherwise B should be replaced with the correct Local UUID).
>
> To deal with issues where a response with a Session ID
> different than what is being retained is sent in an error
> response and the ACK for that response contains the new
> Session ID which we chose not to retain because it was as
> a result of an error, the document will state that a
> Session ID received in an ACK must never update the
> retained value. This should never be an issue because the
> Session ID in the ACK should always match that of the
> matching request, so if the endpoint receiving the request
> updated the Session ID on the request, it does not need to
> do so again for the ACK.

Concerning "Session ID in the ACK should always match that of the matching
request", it isn't always true.  For instance, see
draft-ietf-insipid-session-id-16 section 9.7; the 3pcc sends the updated
uuid within the ACK.

You might want to distinguish between a ACK-for-2xx versus ACK-for-non-2xx.
Some within the SIP working groups prefer to allow ACK-for-2xx to update
things.

> Endpoints and intermediaries always update their Remote
> Session ID based on any responses received regardless of
> the type of response (provided the response is
> syntactically valid and can be processed, of course).

Sending a non-reliable response (1xx-6xx) is not necessarily the best way to
update something because of race conditions and similar ambiguities.
However, the proposal is basically the same as the draft.

> There will always be feature interactions that result in
> temporarily mismatched Session IDs when intermediaries are
> involved, but I don’t think the above proposal makes this
> any worse of a problem in real-world applications.

I'm currently not sure if the proposal is better or worse than draft version
16.

>From the rejecting device perspective, the proposal appears to be better.
The proposal currently appears to leave partial changes up to rejecting
device (i.e. intermediaries allowed change but rejecting device did not)
without any indication to modifier to know if change was successful at the
remote endpoint.  This is about the same as changing some of the MUST to
SHOULD (or MAY) within the current draft which would allow the rejecting
device to make the decision concerning which is better for the situation.

> Please see my responses inline to address your concerns….

I'll respond separately if I have any comments different from those within
this reply.

Thanks,
Brett

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 5 Jan 2016 14:51:10 -0500

This discussion is reinforcing my belief that this mechanism is a mess - 
that the chance is slim to none of getting consistent results in all the 
connected devices.

	Thanks,
	Paul

On 1/5/16 12:51 PM, Brett Tate wrote:
> _______________________________________________
> insipid mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/insipid
>

---

From: "Paul Giralt (pgiralt)" <[email-masked]>
Date: Tue, 5 Jan 2016 22:17:56 +0000

Brett,

Thanks for the reply. See inline.

> sent by endpoint could be dropped (or received after 500).

I actually intended to mention excluding 100 Trying for this very reason. Thanks for highlighting my omission.

> 3pcc sends the updated uuid within the ACK.

Good call out. The only reason I mentioned ignoring all ACK was to make it simpler, but this is clearly a situation where it makes sense to update, so we would have to distinguish between ACK-for-2xx versus ACK-for-non-2xx.

> already been executed, the UAS SHOULD return a 2xx response”.

You could argue that the intermediary is not the one actually rejecting the request bur merely relaying the rejection. The proposal says that the device that is actually doing the rejection of the request is not storing the UUID. For troubleshooting purposes, which is the desired objective of the Session-ID, it makes sense to do as I proposed.

> CANCEL and related 2xx response are not end-to-end (even if using proxies

Is there any situation where including CANCEL could cause a problem? With 100 Trying my concern was that you may end up overwriting a UUID with a Null.

> (with 400 or other failure response).

Yes, I totally understand that the request might be eventually rejected by some other device down the line, but as an intermediary, it seems like this is the best we can do.

> Some within the SIP working groups prefer to allow ACK-for-2xx to update

Same comment as earlier. I think this makes sense to allow ACK-for-2xx to update.

> However, the proposal is basically the same as the draft.

IMHO it’s better than nothing. We are doing this to aid in troubleshooting, so we make due with the information we have.

> device to make the decision concerning which is better for the situation.

Changing MUSTs to SHOULDs would certainly address many of these issues as well, but leave us with the issues you pointed out with RFC 3261 section 8.2.

Thanks,
-Paul

---

From: "Paul Giralt (pgiralt)" <[email-masked]>
Date: Tue, 5 Jan 2016 22:22:17 +0000

I don’t think it’s all doom and gloom. I think in the majority of cases the Session-ID will be consistent end-to-end. It is these corner case error conditions that lead to ambiguity as to the right thing to do which is why I’d prefer expected behavior be documented as clearly as possible, even if it may knowingly result in a situation where all devices don’t necessarily agree on the Session-ID for some period of time in the call. I think there will still be enough information in the message exchange that any post-processing tools being used to diagnose a problem will have enough information to correlate calls even in such scenarios.

-Paul

> On Jan 5, 2016, at 2:51 PM, Paul Kyzivat <[email-masked]> wrote:
> 
> This discussion is reinforcing my belief that this mechanism is a mess - that the chance is slim to none of getting consistent results in all the connected devices.
>

---

From: Brett Tate <[email-masked]>
Date: Wed, 6 Jan 2016 16:01:24 -0500

Hi,

Thanks for the response; reply is inline.

> > The proposal currently appears to violate (or alter)
> > RFC 3261 section 8.2: "If it is rejected, all state
> > changes MUST NOT be performed".  Similarly it also
> > appears to impact the following RFC 6141 section 3.3
> > SHOULD: "If any of the changes requested in a re-INVITE
> > or in any transaction within it have already been
> > executed, the UAS SHOULD return a 2xx response”.
>
> You could argue that the intermediary is not the one
> actually rejecting the request bur merely relaying the
> rejection. The proposal says that the device that is
> actually doing the rejection of the request is not storing
> the UUID.  For troubleshooting purposes, which is the
> desired objective of the Session-ID, it makes sense to
> do as I proposed.

The argument is weak.  You are basically saying that an intermediary should
remember the changed uuid even though the re-INVITE to connect a different
session failed.

The proposal appears to cause intermediaries (e.g. B2BUAs) to violate RFC
3261 section 8.2.  Similarly it also appears to impact the following RFC
6141 section 3.3 SHOULD: "If any of the changes requested in a re-INVITE or
in any transaction within it have already been executed, the UAS SHOULD
return a 2xx response”.

> > You might want to exclude CANCEL and its 2xx response
> > from the algorithm (although decision might be
> > influenced by decision concerning 100 response).
> > CANCEL and related 2xx response are not end-to-end (even
> > if using proxies instead of B2BUAs).
>
> Is there any situation where including CANCEL could cause
> a problem?

It depends upon what you mean by problem.  It can cause more inconsistencies
because of race conditions and not being end-to-end.  I'm not sure how
vendors typically handle CANCEL in relation to RFC 3261 section 8.2's "all
state changes MUST NOT be performed" if the CANCEL causes a 487 for
re-INVITE; however based upon RFC 6141, it looks like the CANCEL changes (if
anyone actually allows them) should be undone when sending the 487 response
similar to what it mentions concerning UPDATE.  Similarly depending upon how
long the transaction being cancelled is remembered, the CANCEL might be
received after final response is sent and still result in 200 response for
CANCEL.

> >> The only additional rule for stateful intermediaries
> >> is that if they accept a request and then forward that
> >> request to another destination (therefore there was no
> >> error found with the message), this will also trigger
> >> the intermediary to update the retained UUID.
> >
> > The proposal means that not all of the devices will
> > necessarily agree if a uuid changed during failure
> > situation.
> >
> > Concerning "therefore there was no error found" statement,
> > be aware that forwarding a request does not necessarily mean
> > that no error was found (i.e. device can be lenient) or that
> > the request won't eventually be rejected (with 400 or other
> > failure response).
>
> Yes, I totally understand that the request might be eventually
> rejected by some other device down the line, but as an
> intermediary, it seems like this is the best we can do.

No comment since currently unsure if the proposal is better than the draft
or other potential mechanisms.

> > I'm currently not sure if the proposal is better or worse
> > than draft version 16.
> >
> > From the rejecting device perspective, the proposal appears
> > to be better.  The proposal currently appears to leave partial
> > changes up to rejecting device (i.e. intermediaries allowed
> > change but rejecting device did not) without any indication
> > to modifier to know if change was successful at the remote
> > endpoint.  This is about the same as changing some of the MUST
> > to SHOULD (or MAY) within the current draft which would allow
> > the rejecting device to make the decision concerning which is
> > better for the situation.
> >
>
> Changing MUSTs to SHOULDs would certainly address many of these
> issues as well, but leave us with the issues you pointed out
> with RFC 3261 section 8.2.

Yes; however the proposal also violates RFC 3261 section 8.2 since not
always rolling back (on the intermediaries) or after 101-199 (on the
rejecter).  And not allowing the first rejecter to potentially also violate
it within the specific situation mandates inconsistency concerning the uuid
values.