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

["Paul Giralt (pgiralt)" <[e-mail]>]

Brett,

Thanks for the reply. See inline.

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


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


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


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.


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


> 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? With 100 Trying my concern was that you may end up overwriting a UUID with a Null.


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


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

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


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


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


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

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