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

From: "Dawes, Peter, VF-Group" <[email-masked]>
Date: Tue, 9 Feb 2010 17:15:44 +0100

Hi Laura,
As I understand it, the session-id header field is included in all
requests. I think it would be possible to define a header field
parameter for session-id, say "; debug", that is added to session-id by
a UA iff certain conditions are met. This is similar to including the
debug-id header field iff pre-supplied trigger conditions are matched in
the UA. The first proxy can then police sesssion-id header fields
containing this parameter (and let others go through unchecked), this
parameter can trigger logging in downsteam SIP entities and so on to
provide all functions of the debug draft. It might even be possible to
use Proxy-Require based on this new parameter to make sure that the
logging happens. 
I am not sure that I want to re-write my draft this way, but it could be
a way to separate correlation-id in general from a specific use case
(troubleshooting).

Best Regards,
Peter

Message: 5

Date: Tue, 9 Feb 2010 16:51:03 +0100

From: <[email-masked]>

Subject: Re: [dispatch]

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

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

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

[email-masked]

Message-ID:

<[email-masked]>

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

Hi Peter, 

One more question. 

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

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

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

> From: [email-masked]

> [mailto:[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]

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

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

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

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

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

> _______________________________________________

> dispatch mailing list

> [email-masked]

> https://www.ietf.org/mailman/listinfo/dispatch
<https://www.ietf.org/mailman/listinfo/dispatch> 

------------------------------

_______________________________________________

dispatch mailing list

[email-masked]

https://www.ietf.org/mailman/listinfo/dispatch
<https://www.ietf.org/mailman/listinfo/dispatch> 

End of dispatch Digest, Vol 11, Issue 21

****************************************

---

From: Salvatore Loreto <[email-masked]>
Date: Tue, 09 Feb 2010 19:27:51 +0200

Peter,

I think your proposal to use a header parameter like "debug"
is a reasonable solution.

However I would suggest to start from requirements and then arrive to 
the actual solution.

/Sal

On 02/09/2010 06:15 PM, Dawes, Peter, VF-Group wrote:
> From:<[email-masked]>
>
> Subject: Re: [dispatch]
>
> To:<[email-masked]>,<[email-masked]>
>
>> [mailto:[email-masked]<mailto:[email-masked]>  ]
>>      
>> From:<[email-masked]>
>>      
>    
>>      
>    
>> Subject: Re: [dispatch]
>>      
>    
>>      
>    
>> To:<[email-masked]>,<[email-masked]>,
>>      
>    
>>      
>    
>> <mailto:[email-masked]<mailto:[email-masked]>  >  ]
>>      
>    
>>      
>    
>>> From: Paul Kyzivat<[email-masked]>
>>>        
>    
>>      
>    
>>> Message-ID:<[email-masked]>
>>>        
>    
>>      
>

---

From: <[email-masked]>
Date: Wed, 10 Feb 2010 14:08:17 +0100

Hi Peter,

Thank you. This sounds great to me. 

Sal is right that we have to define the requirements and use cases first, but I think having a feeling of how the solution could look like helps a lot. 

Kind regards
Laura

> [mailto:[email-masked]] On Behalf Of Dawes, Peter, VF-Group
> Sent: Tuesday, February 09, 2010 5:16 PM
> To: Liess, Laura; [email-masked]
> Cc: [email-masked]; [email-masked]; 
> Hülsemann, Martin
> Subject: Re: [dispatch]