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

From: [email-masked]
Date: Wed, 6 Nov 2002 09:43:25 -0500

Jiri Kuthan obserrved

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

   An onion network is a type of network used in privacy systems when the
   identity of the sender must be protected from the receiver and any
   observer of the network. If A wants to send B a private email, it
   contacts a privacy service which sets up a route among a network of
   specialized routers. It supplies this route to A as a piece of source
   routing information in which each portion of the route is protected by a
   key specific to that specific router  A router upon receiving a message
   will decrypt the routing header with its key and receive the identify of
   the next router in the chain with the rest of the routing header
   encrypted with that next router's key. As one can see this is a set of
   encapsulated routing information, with last portions in turn encrypted
   by the keys of the successive routers. No router can know its place in
   the chain and no observer can gather information from the routing which
   protects the service against attacks like traffic analysis. So if there
   is a lot of traffic between A's repair facility and a major customer B,
   no competitor C can observe this and induce that A's new product has
   relaibili8ty problems.

   The layers of routing information of this service naturally suggests the
   metaphor of an onion, hence the common name Onion Network. There is an
   interesting literature on this and I apologize if the reference was
   obscure. I though this type of network was common knowledge.

   The analogy to a SIP network of a session being propagated though a
   network of proxies determined on the fly is why I described a SIP
   network as 'onion-like'. As in the original onion network no earlier
   proxy can determine where a later proxy will route the session. Each
   proxy uses its own types of polices to match the described caller
   preferences with the callee preferences at that proxy.

   This brings into issue the major technological problem of feature
   interaction (FI) of which there is a vast literature. One primary cause
   of undesired feature interactions is described as 'change of' or
   'disagreement on assumptions'. One manifestation of FI is user
   confusion. The user attempts to use a service and receives a result that
   puzzles him. An example should clarify this and show its relevance to
   the diagnostic issue in SIP. The issue described in the draft  is to me
   a manifestaion of intracting features and has to be addressed by FI
   techniques.

   Alice is a customer who wishes to call a sales representative Bob at
   another company. Bob finds Alice to be a pest and decides that despite
   Alice's declared caller preference to speak to him personally, he will
   set his callee preferences to do a Call Forward Selective on all of
   Alice's calls to his secretary Carole. Alice calls one day at noon when
   Carole is not there, Carole to cover her lunch time calls has programmed
   a Call Forward No Answer to her friend and fellow admin, Dave. Dave is
   away from his desk and has programmed a Call Forward Unconditional to
   his Voice Mail.

   Alice has no idea who Dave is. She calls Bob on an urgent, to her mind,
   issue and receives a voice mail greeting from a perfect stranger Dave.
   This is a classic FI caused by disagreement on assumptions and resulting
   in user concussion. It is a routing problem in SIP that is supposed to
   be diagnosed.

   Now Alice calls Bob and asks what is going on. Is Bob going to candidly
   say that he regards Alice as a pest and has set his proxy preferences to
   Call Forward Selective on all of her calls. In other words, is Bob going
   to open up his network policies, set for his own benefit, to the perusal
   of any caller and possible misinterpretation by a valued customer.

    If Bob has specialized polices to deal with a variety of customers, how
   is he going to describe these as meaningful hints to any arbitrary
   outside party.

   These are the issues as I see them. The internal routing polices and
   network performance will be very sensitive proprietary information.
   Would it be reasonable for a carrier to open its network to a competitor
   so that the competitor can do statistical studies on the performance and
   stability of that carrier's network? Will a company reveal its routing
   policies to its customers when these polices are part of what it uses to
   prioritize customer response? And even if this were to be done, how
   could specialized polices be described usefully.? Alice knows she is
   getting to Dave's voice mail to tell her that the decision was outgoing
   at Bob's proxy would be to state the obvious. To tell her about Carole
   whom she doesn't know would be useless.

   The only way I see to address this problem is for the assumptions at
   each stage to be explicitly stated. If Alice knows she is guaranteed
   access to Bib and is being routed to some strange voice mail. She can
   send Bob that query. In turn Bob can determine how his policies progress
   the call to its next destination. And prepare a suitable business
   sensitive reply to Alice.   The policies on preferences can be reported
   down the chain and debugged at each level until the faulty system is
   found. This is a standard credit assignment system and is the only
   reasonable diagnostic system I see for issues like this. The real issue
   is not to diagnose the problem but to find out who can remedy the issue.
   Alice has no control over Bob's or Carole's preferences. What could she
   do with any information she gets except go to the policy owner anyway.
   There may be better ones but I don't see them.

   This is what I meant by real world networks addressing the privacy and
   sensitivity of real world information. Carriers are not going to willing
   open their networks to the perusal of competitors. Users both within and
   without a company are not going to reveal their policy mechanisms. Is
   anyone going to tell their boss that they have him on Call Forward
   Selective. Job security would seem to dictate otherwise.

Thanks

Tom Gray

_______________________________________________
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: Henry Sinnreich <[email-masked]>
Date: Wed, 06 Nov 2002 09:58:57 -0600

Service provider networks have quite a number of SIP servers, media
servers, service controllers, gateways, phones, etc. and many services
imply quite complex call flows, please see the I-Ds on component
services and multiparty call control. For such networks the proposed
diagnostic tool is a true godsend IMHO, even if in inter-carrier
applications there may be some limitations.

This is literally a new technology, think the bottle is half full and
let's see reports on its value in the network, instead on speculating on
limitations, before even getting any deployment experience.

If there are better tools you may propose, please share them with the
list.

Thanks, Henry

Henry Sinnreich
WorldCom
400 International Parkway
Richardson, Texas 75081
USA

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] 
> On Behalf Of [email-masked]
> Sent: Wednesday, November 06, 2002 8:43 AM
> To: Jiri Kuthan
> Cc: [email-masked]; Jiri Kuthan; [email-masked]; 
> [email-masked]
> Subject: Re: [Sipping] Diagnostics again -- really
> 
> 
> 
> 
> 
> 
> 
> 
>    Jiri Kuthan obserrved
> 
> 
> Use [email-masked] for questions on current 
> sip Use [email-masked] for new developments of core SIP
>