Subject: Re: [Sipping] Diagnostics again -- really

From: [email-masked]
Date: Mon, 4 Nov 2002 11:40:32 -0500

Hi

It is my opinion that there is something much more fundamental going on
with diagnostics in this sort of system than is addressed in this document.
In brief, how would anyone know  that there has been an error. Each section
of the network describes its own routing logic and other sections build
there routing intentions relaying on their understanding of this. So Alice
calls Bob who forwards to Carol. Alice knows about Bob who knows about
Carol but Alice does not know about Carol. Alice calls Bob but is
continually is forwarded to Carol's voicemail. Is this an error, it all
depends.

I really do not see how diagnostics as described in the draft can function
in an end-to-end distributed control network. It would seem to me that some
sort of credit assignment system in which each layer of the 'onion-like'
connection would know the semantics of what it is requiring from the inner
portions of the connection would be required. Instead of diagnosis an
operator would like to know which portion of its or anther's network is
responsible. As the draft points out diagnostics from inner portions of an
operator's network would be shared with outsiders only in very very rare
circumstances.

I don't find the mechanism described in the draft to be in any way
effective in  real world networks

Thanks

Tom Gray

Jiri Kuthan <[email-masked]>@ietf.org on 11/03/2002
07:47:07 AM

Sent by:  [email-masked]

To:   [email-masked]
cc:
Subject:  [Sipping] Diagnostics again -- really

I'm wondering there has been no echo on draft-kuthan-sipping-diag-00.txt
on the mailing list. I do not think we can afford ignoring diagnostics --
whoever tried to deploy SIP will surely confirm that.

I'd really like to see WG's feedback on this piece of work, I will drop
it otherwise.

Thanks,

-Jiri

>Date: Thu, 24 Oct 2002 13:08:00 +0200
>To: [email-masked]
>From: Jiri Kuthan <[email-masked]>
>Subject: [Sipping] Diagnostics I-D: draft-kuthan-sipping-diag-00.txt
>Sender: [email-masked]
>
>I just submitted a new, tiny I-D with a proposal to add
>more diagnostic info in SIP to facilitate troubleshooting.
>I think it is one of issues which deserves more attention
>than it has received so far -- it is important to operation.
>I will appreciate WG's comments and any other help to advance
>this piece of work before the upcoming meeting.
>
>Thanks,
>
>-Jiri
>
>ps -- until is is in the IETF repository, the memo is available
>at http://www.iptel.org/~jiri/etc/draft-kuthan-sipping-diag-00.txt
>Abstract follows:
>
>   Session Initiation Protocol (SIP) provides only limited space for
>   communicating diagnostic information when errors occur. To facilitate
>   troubleshooting, automated error detection, and reporting we propose
>   to create new protocol extensions. The extensions will be used for
>   richer reporting on request processing status. Particularly, we
>   suggest that User Agent Servers (UAS) include additional information
>   about error reasons in negative replies, and proxy servers indicate
>   in relayed requests the routing logic they used.
>
>--
>Jiri Kuthan            http://iptel.org/~jiri/
>
>_______________________________________________
>Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
>This list is for NEW development of the application of SIP
>Use [email-masked] for questions on current sip
>Use [email-masked] for new developments of core SIP

_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use [email-masked] for questions on current sip
Use [email-masked] for new developments of core SIP

_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use [email-masked] for questions on current sip
Use [email-masked] for new developments of core SIP

---

From: Jiri Kuthan <[email-masked]>
Date: Tue, 05 Nov 2002 21:44:38 +0100

At 05:40 PM 11/4/2002, [email-masked] wrote:

>In brief, how would anyone know  that there has been an error. 

In brief, by seeing a negative reply. (That's already a part of SIP.)
I'm aiming at something else, though.

You might have noticed I didn't propose building an error assertation system.
I'm proposing protocol extensions, which gain troubleshooters and perhaps
some "error assertation systems" additional knowledge. How well this is 
utilized depends on troubleshooters or implementations of automated
monitoring systems.

[...]

>responsible. 

Can you be more specific and technical? I'm frankly confused by this
discussion about onions. Thank you.

>As the draft points out diagnostics from inner portions of an

The I-D does not definitely mention it this way. On the contrary, it
recommends "rich" messages with additional troubleshooting information.
You would be perhaps surprised how much additional information IETF
protocols carry and how useful they are. Just look at all the header
fields of this message: List-Subscribe:, X-Sender:, X-BeenThere:,
etc. Useful stuff.

>effective in  real world networks

I'm glad I can share with you our real-world operational experience
from iptel.org, our public SIP site. It worked and it helped. The
primary limitation is we can move to automated systems only using
proprietary extensions, not good in long run.

In summary, it seems to me that you are seeking solutions for some
other problems than those stated in my I-D.

-Jiri

---

From: Henry Sinnreich <[email-masked]>
Date: Tue, 05 Nov 2002 16:52:26 -0600

>diagnostics from inner portions of an 
>operator's network would be shared with outsiders only in very very 
>rare circumstances.

I believe this may be more true for conventional carriers and less for
ISPs, since routing advertisements, DNS and other information is
exchanged more freely on the Internet between service providers, though
we should get down here to the specifics.

Thanks, Henry

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] 
> On Behalf Of Jiri Kuthan
> Sent: Tuesday, November 05, 2002 2:45 PM
> To: [email-masked]; Jiri Kuthan; [email-masked]; 
> [email-masked]
> Cc: [email-masked]
> Subject: Re: [Sipping] Diagnostics again -- really
> 
> 
> >with diagnostics in this sort of system than is addressed in this 
> >document. In brief, how would anyone know  that there has been an 
> >error.
> 
> In brief, by seeing a negative reply. (That's already a part 
> of SIP.) I'm aiming at something else, though.
> 
> You might have noticed I didn't propose building an error 
> assertation system. I'm proposing protocol extensions, which 
> gain troubleshooters and perhaps some "error assertation 
> systems" additional knowledge. How well this is 
> utilized depends on troubleshooters or implementations of 
> automated monitoring systems.
> 
> [...]
> 
> >I really do not see how diagnostics as described in the draft can 
> >function in an end-to-end distributed control network. It 
> would seem to 
> >me that some sort of credit assignment system in which each layer of 
> >the 'onion-like' connection would know the semantics of what it is 
> >requiring from the inner portions of the connection would be 
> required. 
> >Instead of diagnosis an operator would like to know which portion of 
> >its or anther's network is responsible.
> 
> Can you be more specific and technical? I'm frankly confused 
> by this discussion about onions. Thank you.
> 
> >operator's network would be shared with outsiders only in very very 
> >rare circumstances.
> 
> The I-D does not definitely mention it this way. On the 
> contrary, it recommends "rich" messages with additional 
> troubleshooting information. You would be perhaps surprised 
> how much additional information IETF protocols carry and how 
> useful they are. Just look at all the header fields of this 
> message: List-Subscribe:, X-Sender:, X-BeenThere:, etc. Useful stuff.
> 
> I'm glad I can share with you our real-world operational 
> experience from iptel.org, our public SIP site. It worked and 
> it helped. The primary limitation is we can move to automated 
> systems only using proprietary extensions, not good in long run.
> 
> In summary, it seems to me that you are seeking solutions for 
> some other problems than those stated in my I-D.
> 
> -Jiri
> 
> Use [email-masked] for questions on current 
> sip Use [email-masked] for new developments of core SIP
>