Subject: Re: [sip-overload] draft-gurbani-soc-overload-control-01 in the IETF archives

From: "DOLLY, MARTIN C (ATTLABS)" <[email-masked]>
Date: Fri, 16 Jul 2010 13:26:11 -0400

IETF should not get into service specific exceptions 
Martin C. Dolly 
Sent to you by AT&T... America's Fastest Mobile Broadband Network. Rethink Possible. 
+1.609.903.3360

________________________________

From: [email-masked] <[email-masked]> 
To: Paul Kyzivat <[email-masked]> 
Cc: [email-masked] <[email-masked]> 
Sent: Fri Jul 16 13:19:00 2010
Subject: Re: [sip-overload] draft-gurbani-soc-overload-control-01 in the IETF archives 

Rather than my paraphrasing it -  best to go to section 8 of RFC4412 for a discussion of the relative ordering of multiple namespaces. 

Janet

Paul Kyzivat <[email-masked]> wrote on 07/16/2010 12:50:11 PM:

> [image removed] 
> 
> Re: [sip-overload] draft-gurbani-soc-overload-control-01 in the IETF archives 
> 
> Paul Kyzivat 
> 
> to: 
> 
> Janet P Gunn 
> 
> 07/16/2010 12:50 PM 
> 
> Cc: 
> 
> "Vijay K. Gurbani", sip-overload 
> 
> Thanks for the explanation Janet.
> A related question:
> 
> IIRC, (and its highly likely I don't) there is likely no defined 
> ordering between values from two different namespaces.
> 
> If that is so, what are the implications for deciding which of two 
> messages to reject?
> 
>    Thanks,
>    Paul
> 
> Janet P Gunn wrote:
> > 
> > 
> > 
> > 
> > "Vijay K. Gurbani" <[email-masked]> wrote on 07/16/2010 12:32:27 AM:
> > 
> >  > Re: [sip-overload] draft-gurbani-soc-overload-control-01 in the IETF 
> > archives
> >  > Vijay K. Gurbani
> >  > to:
> >  > Janet P Gunn
> >  > 07/16/2010 12:30 AM
> >  > Cc:
> >  > sip-overload
> >  >
> >  > On 07/15/2010 01:14 PM, Janet P Gunn wrote:
> >  > > WEELL- that is a step in the right direction, but it is a lot more
> >  > > complicated than that.
> >  >
> >  > Janet: Thank you for this information; it is very helpful.
> >  > Handling R-P header is turning out to be more complicated
> >  > than I originally thought.  Please see inline for more
> >  > comments.
> >  >
> >  > > First of all, it is not the presence of ANY RPH that grants exemption
> >  > > from overload controls. It is the combination of a PARTICULARNAMESPACE
> >  > > and value, in conjunction with a "local policy" (local to that domain,
> >  > > or local to that device) to exempt such messages (all or some) from
> >  > > overload controls.
> >  >
> >  > Paul K. brought this up as well, and I think it is important: what
> >  > if the upstream node allowed a message with R-P and namespace based
> >  > on *it's* notion of importance, but the downstream (overloaded) server
> >  > does not share the same notion of exempting messages with the namespace
> >  > that was important to the upstream node?  Then all the work has been
> >  > done for naught.
> >  >
> >  > > Just as a for-instance, there are expected to be some networks in which
> >  > > EVERY SIP message (or at least every INVITE) will have RPH. What will
> >  > > vary will be (possibly) the Namespace and (definitely) the priority
> >  > > value. Obviously, in THAT network, it wouldn't make sense to exempt
> >  > > every SIP message with RPH from load control, you would be 
> > exempting ALL
> >  > > of them. It MIGHT make sense to exempt specific Namespace-Priority 
> > Value
> >  > > combinations.
> >  >
> >  > How does the upstream node know which namespace-priority combination is
> >  > held sacrosanct by the downstream server?
> >  >
> >  > Any thoughts on this?
> >  >
> > 
> > Any time you leave things to "local policy" you leave open the 
> > possibility of stupid, ineffective, not-well-thought-out, or even 
> > downright malicious local policy.  And even a seemingly well-thought-out 
> > local policy can have unintended consequences.
> > 
> > But in the "real world", I think it is safe to assume that the Service 
> > Provider has an incentive (financial, operational, political, public 
> > relations...) to use RPH in an effective way.  
> > 
> > If both upstream and downstream nodes are controlled by the same service 
> > provider, it would be ineffective to have
> > -the upstream node ignore namespace Z, and  exempt namespace A,
> > and have
> > -the downstream node exempt namespace Z and ignore namespace A.  
> > It COULD happen (especially if someone fat fingered the configuration), 
> > but it shouldn't.
> > 
> > 
> > In general, the Service Provider will make sure that the upstream and 
> > downstream nodes are exempting the same namespace (or the same 
> > namespace-value combination.
> > 
> > In reality, what probably WILL sometimes happen (for a variety of 
> > reasons) is
> > - the upstream node ignores namespace A (or RPH) entirely and the 
> > downstream node exempts namespace A from overload controls
> > - the upstream node exempts namespace A from overload controls and the 
> > downstream node ignores namespace A (or RPH) entirely
> > 
> > This could because the functionality is in the process of being rolled 
> > out, or because that vendor never developed the functionality, or 
> > because the Service Provider believes that the network is engineered in 
> > such a way that it is not needed at that node.
> > 
> > In those cases it is unfortunate, but just one of those things we have 
> > to live with.  It is probably better than having both nodes ignore it.
> > 
> > The more interesting case is where
> > 
> > Network A give priority to RPH namespace A, and ignores namespace B
> > 
> > Network B give priority to RPH namespace B, and ignores namespace A
> > 
> > Yes, then, near the interface, you could have some complications with 
> > the upstream node exempting messages the downstream node is going to 
> > dump, and vice versa.  But, like so many things, this would be addressed 
> > by the business relationships between the Service Providers running 
> > Network A and Network B.
> > 
> > Janet
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > ------------------------------------------------------------------------
> > 
> > _______________________________________________
> > sip-overload mailing list
> > [email-masked]
> > https://www.ietf.org/mailman/listinfo/sip-overload <https://www.ietf.org/mailman/listinfo/sip-overload>