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

From: [email-masked]
Date: Thu, 7 Nov 2002 10:29:09 -0500

I not am not trying to be obstreperous or otherwise miserable about this
but I see the following problems with this draft:

a) it relies on exclusively on errors detected in the routing by proxies,
this is not necessarily true or perhaps even commonly true. Given your
example of the component services, the routing may be quite correct
according to the down stream proxies but the device connected to is
inadequate to the task, unstable etc. This draft does not address this case
(which is likely, in my opinion, to be quite if not the most common) when
only the originating device can detect the error and can only do this by
non-protocol means

b) it does not take into account the necessary need for privacy among
providers. In fact it seems to ignore this need except for a mention of
some sort of cookie It recommends that the routing logic be revealed which
may (i.e likley will) be highly inadvisable see c) .

c) it does not take into account the nature of  the types of policies that
will be used for routing in proxies. These are likely to be highly
personalized and un-interpretable to upstream diagnosis.   In this the
privay issue is also important. Itmay be quite inadviasble for a provider
to provide this information to a customer (i.e. route this pest to my
secretrary always)

d) Who is going to interpret the suggested hints and how will it be done.
Before developing protocol extensions, this mechanism and its limitations
should be spelled out.  How can anyone tell what should be placed in the
protocol otherwise?

There may be special cases in which a mechanism such as described in the
draft would be highly suitable - protocol detected errors, single provider
network, static and well-known static policies... There may be enough
situations of this type to make the extensions in this draft highly
desirable. iI so, a suitable applicability statement could be attached to
the text to make these limitations known to potential users.

Thanks

Tom Gray

Henry Sinnreich <[email-masked]>@ietf.org on 11/06/2002 10:58:57
AM

Sent by:  [email-masked]

To:   [email-masked]
cc:   "'Jiri Kuthan'" <[email-masked]>, [email-masked],
      [email-masked], "'Jiri Kuthan'" <[email-masked]>
Subject:  RE: [Sipping] Diagnostics again -- really

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

_______________________________________________
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: Henry Sinnreich <[email-masked]>
Date: Thu, 07 Nov 2002 12:35:25 -0600

Tom,

> There may be special cases in which a mechanism such as 
> described in the draft would be highly suitable - protocol 
> detected errors, single provider network, static and 
> well-known static policies... There may be enough situations 
> of this type to make the extensions in this draft highly 
> desirable.

You have some good suggestions such as about the applicability
statement. We seem to agree this is useful in single provider networks.
As we know, one never quite foresees what an invention may be used
for... 

Thanks, Henry

> Sent: Thursday, November 07, 2002 9:29 AM
> To: Henry Sinnreich
> Cc: [email-masked]; 'Jiri Kuthan'; 
> [email-masked]; [email-masked]; 'Jiri Kuthan'
> I not am not trying to be obstreperous or otherwise miserable 
> about this but I see the following problems with this draft:
> 
> a) it relies on exclusively on errors detected in the routing 
> by proxies, this is not necessarily true or perhaps even 
> commonly true. Given your example of the component services, 
> the routing may be quite correct according to the down stream 
> proxies but the device connected to is inadequate to the 
> task, unstable etc. This draft does not address this case 
> (which is likely, in my opinion, to be quite if not the most 
> common) when only the originating device can detect the error 
> and can only do this by non-protocol means
> 
> b) it does not take into account the necessary need for 
> privacy among providers. In fact it seems to ignore this need 
> except for a mention of some sort of cookie It recommends 
> that the routing logic be revealed which may (i.e likley 
> will) be highly inadvisable see c) .
> 
> c) it does not take into account the nature of  the types of 
> policies that will be used for routing in proxies. These are 
> likely to be highly
> privay issue is also important. Itmay be quite inadviasble 
> for a provider to provide this information to a customer 
> (i.e. route this pest to my secretrary always)
> 
> d) Who is going to interpret the suggested hints and how will 
> it be done. Before developing protocol extensions, this 
> mechanism and its limitations should be spelled out.  How can 
> anyone tell what should be placed in the protocol otherwise?
> 
> There may be special cases in which a mechanism such as 
> described in the draft would be highly suitable - protocol 
> detected errors, single provider network, static and 
> well-known static policies... There may be enough situations 
> of this type to make the extensions in this draft highly 
> desirable. iI so, a suitable applicability statement could be 
> attached to the text to make these limitations known to 
> potential users.
> 
> Thanks
> 
> Tom Gray
> 
> 
> 
> 
> 
> Henry Sinnreich <[email-masked]>@ietf.org on 
> 11/06/2002 10:58:57 AM
> 
> 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
> > From: [email-masked] 
> [mailto:[email-masked]] On Behalf 
> > Of [email-masked]
> >    >Can you be more specific and technical? I'm frankly confused by 
> > this
> systems when 
> > the
> >    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
> >    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
> 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
> >    network as 'onion-like'. As in the original onion network no 
> > earlier
> >    proxy can determine where a later proxy will route the session. 
> > Each
> >    interaction (FI) of which there is a vast literature. 
> One primary 
> > cause
> >    confusion. The user attempts to use a service and 
> receives a result 
> > that
> relevance 
> > to
> draft  is 
> > to me
> representative Bob 
> > at
> >    another company. Bob finds Alice to be a pest and decides that 
> > despite
> personally, he 
> > will
> >    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
> Dave. Dave 
> > is
> Unconditional 
> > to
> >    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
> words, is Bob 
> > going
> >    to open up his network policies, set for his own benefit, to the 
> > perusal
> >    These are the issues as I see them. The internal routing polices 
> > and
> >    Would it be reasonable for a carrier to open its network to a 
> > competitor
> >    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
> 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
> assumptions 
> > at
> mail. She 
> > can
> >    send Bob that query. In turn Bob can determine how his policies 
> > progress
> >    down the chain and debugged at each level until the 
> faulty system 
> > is
> The real 
> > issue
> remedy the 
> > issue.
> What could 
> > she
> >    do with any information she gets except go to the policy owner 
> > anyway.
> >    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
> mechanisms. 
> > Is
> > 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
> >
>