Subject: Re: [Sipping] Re: Cookies vs. State

From: [email-masked]
Date: Thu, 18 Apr 2002 19:42:22 EDT

In a message dated 4/18/02 1:28:15 PM Eastern Daylight Time, 
[email-masked] writes:

> >----------------------------------------------------- 
> >Comments on draft-willis-sip-cookies-00: 
> >
> >This draft provides a good base-line for definition of a SIP-cookie
> functionality, >derived from RFC 2109. 
> >
> >Some comments/observations: 
> >
> <Mike's original comments snipped>

> In HTTP, cookies are often "permanent".  Most of the abuse of cookies 
> comes from this use.  Of course you can discard HTTP cookies at any time.
> You may lose some "services" if you do.  Same with SIP cookies, but we
> specify that cookies ARE NOT saved across sessions, primarily to avoid
> the abuse that we have seen with HTTP cookies.
> 

Then an explicit statement needs to be added that cookies MUST be discarded 
at the end of a call.

> 
> Woah, you don't send ALL stored cookies, you send those associated with
> a particular call.  Message size can be a problem, in wireless networks,
> and when message size exceeds MTU size with UDP.  That is a consideration
> which the draft should note.
> 

Yes, I hope that you don't send all, but the draft didn't seem to say that. 
It indicated that all cookies recieved for a call must be kept and that every 
cookie stored for a call must be sent in every message. Since there could not 
be any cookies for any previous call, all stored cookies must be sent in 
every message.

If the point is to store "state" in the UA by this method, then it's obvious 
to me that the requirement is to store exactly one Cookie per call. (One 
could argue whether a multipoint call like three way calling is modeled as 
one call or two.)

> 
> 
> Several others have noted that it is much easier to support high 
> availability
> when state is stored in the endpoints rather than to have replication
> mechanisms and all sorts of other gunk required when state is maintained
> in the proxy server.  Some would say that while call-statefull proxies
> may be needed for some services, they are mostly undesirable, and
> SIP is designed for statefull UAs and stateless proxies.  Cookies
> continues that design philosophy.

High availability with everything stored in one place is certainly easier 
than storing the data in end devices and working out all the protocol and 
security issues to fetch it whenever feature processing needs to know it. 
Design technique for highly reliable systems, often based on redundant pairs 
with sharing of state information, has been around for decades.

And I continue to puzzle over why a call stateful, highly reliable proxy to 
control some service is considered to be "undesirable". And it's not 
sufficient to say "because that's not the way http did it".

Mike

---

From: "Dean Willis" <[email-masked]>
Date: Thu, 18 Apr 2002 20:48:58 -0500

Mike said:
-------------- 
Yes, I hope that you don't send all, but the draft didn't seem to say
that. It indicated that all cookies recieved for a call must be kept and
that every cookie stored for a call must be sent in every message. Since
there could not be any cookies for any previous call, all stored cookies
must be sent in every message. 

If the point is to store "state" in the UA by this method, then it's
obvious to me that the requirement is to store exactly one Cookie per
call. (One could argue whether a multipoint call like three way calling
is modeled as one call or two.) 
 -------------
 
1) One could envision a call passing through multiple service provider
proxies, with each service provider adding a cookie. 

2) If one serves excessively large cookies, one can expect to have one's
service shunned. Survival is not mandatory.

Mike said:
------------------ 
 High availability with everything stored in one place is certainly
easier than storing the data in end devices and working out all the
protocol and security issues to fetch it whenever feature processing
needs to know it. Design technique for highly reliable systems, often
based on redundant pairs with sharing of state information, has been
around for decades. 

And I continue to puzzle over why a call stateful, highly reliable proxy
to control some service is considered to be "undesirable". And it's not
sufficient to say "because that's not the way http did it".  
------------------ 

Works fine until someone shoves an airplane into your "one place". Of
course, one could geographically distribute matched pairs. Or quartets.
Then we're back to building wide-area state replication, which is hard.
 
But a system builder is free to use centralized redundancy. I do it all
the time. We sell lots of highly redundant state-shared proxyclusters,
primarily as firewall controllers. 
 
It's just not the perfect solution for all situations. What it doesn't
work well for in my experience is things like "Kansas just went off line
due to an MBOSI , so some of the users are being served out of Chicago
now, some from California, and some from Virginia, and some seem to have
rehomed off the orbital platform that just came into view". In the PSTN
world you're used to, since their circuits were cut, their calls
dropped, and they can restablish on a new circuit. In the Internet
model, it means their packets are briefly delayed while the router
network finds a new shortest path, and they're still talking, and
eventually, they're going to want to send a BYE or do somethine else
useful.
 
An MBOSI, if you're curious,  is a "Multiple Backhoe Operator Stupidity
Incident", and it happens with alarming frequency whenever backhoes and
fiber optics share space. It doesn't matter HOW much fiber redundancy
you put into a building, they'll find a way to cut all of it at the same
time. I once serviced a data center that we built straddling GTE and
SWBell property lines, with fully redundant provisioning from each
carrier, with entry points on opposite sides of the five million square
foot building. The first MBOSI occurred before we had the center fully
operational, less than a month after the fibers were lit. As I recall,
the operator realized he'd hit something, so he went around to the
opposite side of the buiilding looking for a safer place to dig. Voila.
Murphy was an optimist.

- -
Dean