Subject: Re: [dispatch] I-DAction:draft-kaplan-dispatch-session-id-00.txt

From: "Dawes, Peter, VF-Group" <[email-masked]>
Date: Mon, 8 Feb 2010 16:58:21 +0100

Hi Laura,
What you describe below about debug-id is the correct understanding. I
am not convinced that using session-id for troubleshooting is practical
because it implies that everything has to be logged everywhere in the
network all the time so that you can, for example, look at any
signalling that happened two days ago. The debug-id is inserted as
required, and also policed at a couple of entities (first proxy,
registrar) to take the burden of deciding whether or not to log away
from the rest of the network. The debug-id is also based on 3GPP and OMA
requirements, as I mentioned, but these requirements are, I believe,
necessary to minimize burden on the network. 

Starting to read through the threads that consider the idea from Paul
Kyzivat:

> IMO use cases should be gathered and then bucketed into sets that can 

> be

> satisfied by a single mechanism, without assuming initially how many 

> buckets there will be.

the beginning of a list of use cases seems to be 3rd-party CC,
correlating multiple parallel dialogs, forked requests, requests that
pass through B2BUAs. I guess that if an unambiguous test can be
expressed for whether a particular session belongs to a set of related
sessions, then one header to hold the id that correlates them is enough,
even if populating it is difficult for some use cases. For example, I
imagine that the debug-id draft could be re-written to use session-id
(if session-id is chosen as the single "correlation id" header) to hold
the "correlation id" with an added header field parameter to indicate
the extra functionality for reducing the network burden of
troubleshooting. This would satisfy the troubleshooting and 3GPP/OMA
requirements without limiting the meaning of the "correlation id" to
troubleshooting. 

Like you, I would like to find some way forward with the e2e correlation
topic (Spencer is right. BOF, CLF whatever...we have to find some way to
come forward with the e2e correlation.). Also, our network guys consider
session-id to be useful, but I would also like to satisfy some OMA/3GPP
requirements that it does not cover.  

Best Regards,
Peter

Message: 3

Date: Fri, 5 Feb 2010 17:21:39 +0100

From: <[email-masked]>

Subject: Re: [dispatch]

I-DAction:draft-kaplan-dispatch-session-id-00.txt

To: <[email-masked]>, <[email-masked]>,

<[email-masked]>

Cc: [email-masked], [email-masked],

[email-masked], [email-masked]

Message-ID:

<[email-masked]>

Content-Type: text/plain; charset="iso-8859-1"

Hi Peter,

My understanding is that session-id and debug-id cover different sets of
requirements. 

Session-id is in every message. If people want to find out what happened
two days before, they can look at the old logs and the session-id is
there in every message to help them to correlate e2e. For the debug-id
to be there you have to know in advance that and which e2e traffic you
would like to have correlated. The debug-id is activated "on-demand" and
has no performance impact when it is not active, session-id is active
all the time. The advantage of the debug-id is that there is no
performance impact when debugging is not needed. Is my understanding
correct? 

I like the debug-id stuff, it's really smart and we looked at it. But
our troubleshooting and security guys want the session-id, for the
reason above. I assume every service provider has its own needs and
requirements. 

Spencer is right. BOF, CLF whatever...we have to find some way to come
forward with the e2e correlation. 

Thanks a lot

Laura

> -----Original Message-----

> From: Dawes, Peter, VF-Group [mailto:[email-masked]
<mailto:[email-masked]> ]

> Sent: Friday, February 05, 2010 4:00 PM

> To: [email-masked]

> Cc: Liess, Laura; [email-masked]; 

> [email-masked]; H?lsemann, Martin; Pinker, Gerold

> Subject: FW: I-DAction:draft-kaplan-dispatch-session-id-00.txt

> Hello,

> Gonzallo listed related work (Date: Thu, 14 Jan 2010 17:08:03

> +0200) as

> "1) We have Hadriel's draft, 2) We also have the following draft, 

> which eventually led to the disaggregated media work:

> http://www.watersprings.org/pub/id/draft-loreto-sipping-dialog
<http://www.watersprings.org/pub/id/draft-loreto-sipping-dialog> 

> -correlati

> on-01.txt 3) We also have the SIP-XMPP work, which may also need to 

> correlate sessions somehow."

> I would like to add

> http://tools.ietf.org/html/draft-dawes-sipping-debug-02
<http://tools.ietf.org/html/draft-dawes-sipping-debug-02>  to this 

> discussion of use cases for some form of correlation identifier. This 

> draft relates to debugging/troubleshooting to meet documented 

> requirements from 3GPP and OMA, and proposes a kind of correlation 

> identifier in a new header.

> Regards,

> Peter

> Message: 2

> Date: Fri, 22 Jan 2010 11:05:57 -0500

> From: Paul Kyzivat <[email-masked]>

> Subject: Re: [dispatch] FW:

> I-DAction:draft-kaplan-dispatch-session-id-00.txt

> To: [email-masked]

> Cc: [email-masked], [email-masked],

> [email-masked], [email-masked],

> [email-masked]

> Message-ID: <[email-masked]>

> Content-Type: text/plain; charset=ISO-8859-1; format=flowed

> [email-masked] wrote:

> > Paul,

> > Thank you for the examples. The scenarios can be really complex. I

> hope we can get these correlation identifiers, whatever their names, 

> to work correctly in all cases....

> > I am not sure I understood your message correctly. Do you say we

> should have two different identifiers because we use them for two 

> different things?

> I think there may be more than two distinct usages that will require 

> different ones.

> IMO use cases should be gathered and then bucketed into sets that can 

> be

> satisfied by a single mechanism, without assuming initially how many 

> buckets there will be.

> (But I'm still on record as not being convinced that a correlation id 

> is

> needed *at all* for the case when multiple sip UAs are participating 

> on behalf of a single user in a call.)

> > Thanks a lot

> > Laura

---

From: <[email-masked]>
Date: Tue, 9 Feb 2010 16:46:31 +0100

Hi Peter, 

I agree. We should put together a first draft describing the use cases and, I think, the requirements for each use case. We already have a lot of stuff in the existing drafts. 
However, Salvatore tried this about two years ago and it didn't work then. I think there were two reasons for this (just my personal opinion): 

2) People involved with the issue (Hadriel, Dale, myself) had other, more urgent things to do then. (I think you were not involved in the discussion then, but I am not sure.)

1) The draft included the disagregated media correlation, which is quite difficult to compare with the other stuff and this made things quite complicated. Two or three weeks ago we discussed again the issue session-id vs. disagregated media correlation and Salvatore and I came to the conclusion that they are different and we need different identifiers for them. I don't know if other people agreed to this view. 

I am not sure it is realistic and very usefull to try submitting a new draft about the use cases/requirements draft before Anaheim. I am now quite busy myself and I think other people have the same problem. I could offer to do main editor for the use cases draft, but after Anaheim. Or maybe we could begin with Sal's expired use cases draft. 

I would propose that before Anaheim people interested in the issue try to read the drafts existing on this issue. Depending on who will attend Anaheim, we could meet there and discuss first the existing drafts, overlapping requirements/use cases and the differences.

What do you think?  Do you intend to attend Anaheim? 

Laura  

> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Dawes, Peter, VF-Group
> Sent: Monday, February 08, 2010 4:58 PM
> To: [email-masked]
> Cc: Dawes, Peter, VF-Group; [email-masked]; 
> [email-masked]; Hülsemann, Martin; Pinker, Gerold
> Subject: Re: [dispatch] 
> _______________________________________________
> dispatch mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dispatch
>

---

From: <[email-masked]>
Date: Tue, 9 Feb 2010 16:51:03 +0100

Hi Peter, 

One more question. 

>For example, I

I is not realy clear to me how you intend to use the new parameter field. Could you give me more details?

Thanks a lot,
Laura