Subject: RE: [Sipping] RE: Queries and commentsondraft-hilt-sipping-overload-00.txt

From: "Michael Hammer \(mhammer\)" <[email-masked]>
Date: Thu, 4 Jan 2007 11:59:32 -0500

Henry,

This has nothing to do with router congestion and everything to do with
overload of end host node supporting VoIP application, which is more
akin to an unintentional DDOS.

And yes, one can always throw more hosts at the problem, but
over-provisioning may not always be the most cost-effective use of
resources.

Hope that restores your sanity. :)

Mike

> -----Original Message-----
> From: Henry Sinnreich [mailto:[email-masked]] 
> Sent: Wednesday, January 03, 2007 6:42 PM
> To: Volker Hilt; Tom-PT Taylor
> Cc: sipping; Michael Hammer (mhammer)
> Subject: RE: [Sipping] RE: Queries and 
> commentsondraft-hilt-sipping-overload-00.txt
> 
> Volker is 100% correct and I would only like to add that a 
> little more bandwidth (think of all the multimedia and 
> animated web commercials
> flowing) and modern processors are far cheaper and more 
> effective in avoiding overload in the first place.
> 
> Sanity check: VoIP traffic is so small, that it is hard to 
> detect on the net :-)
> 
> Thanks, Henry
> 
> -----Original Message-----
> From: Volker Hilt [mailto:[email-masked]]
> Sent: Wednesday, January 03, 2007 3:09 PM
> To: Tom-PT Taylor
> Cc: sipping; Michael Hammer (mhammer)
> Subject: Re: [Sipping] RE: Queries and
> commentsondraft-hilt-sipping-overload-00.txt
> 
> Tom-PT Taylor wrote:
> > One of the proposals going around TISPAN was for a separate 
> overload 
> > control protocol, for exactly the reason you point out: 
> that you may 
> > need to control for overload from multiple application protocols on
> the 
> > same box. Another argument, applying even to single-protocol boxes,
> was 
> > that this would be more effective than defining new overload 
> > capabilities in a multiplicity of protocols.
> > 
> A downside is that all SIP boxes need to implement the 
> protocol stack of
> 
> the stand-alone protocol for this to work well. Also, the 
> stand-alone protocol stack would have to have hooks into all 
> other protocols to actually facilitate the throttling (what 
> if it doesn't?). E.g. it would have to have a way to instruct 
> the SIP protocol stack on the upstream entity to reject a 
> certain fraction/rate of messages. During operation, the 
> protocol would have to exchange some kind of messages (maybe similar
> 
> to SUB/NOT) which again contribute to messaging traffic. A 
> mechanism directly built into SIP does not have these 
> problems and seems to be simpler and easier to deploy.
> 
> Volker
> 
> 
> 
> > Janet P Gunn wrote:
> >> Mike,
> >>
> >> Good point..
> >>
> >> Obviously everything is simplest if we are only dealing with one 
> >> protocol.
> >>
> >> If the box is serving multiple protocols, I would assume that 
> >> detecting/identifying overload applies to the machine, not the
> protocol
> >> (e.g , cpu usage, internal queue length, time in  queue).
> >>
> >> SIP can, of course, only address signalling the overload to other
> boxes
> >> that "talk" SIP.  Obviously, if that "other box" is 
> sending both SIP 
> >> messages and other-protocol-messages to the overloaded 
> box, it would
> be
> >> nice/ sensible if the "other box" throttled all messages (SIP or
> >> otherwise)
> >> to the overloaded box.  But I don't think SIP can specify that.
> >>
> >> If the overloaded box talks to some boxes that "talk" SIP, and some
> that
> >> don't, there is always the possibility that the SIP boxes will cut
> back,
> >> and the others won't, leaving the overloaded box STILL overloaded,
> but 
> >> with
> >> non-SIP work.  Obviously this wouldn't be a good idea.  I 
> don't think
> we
> >> can necessarily assume it away, but I don't think we can 
> "solve" it 
> >> with a SIP document.
> >>
> >> Janet
> >>
> >>
> >>
> >> "Michael Hammer \(mhammer\)" <[email-masked]> wrote on 
> 01/03/2007
> >> 10:42:35 AM:
> >>
> >>> Janet and others,
> >>>
> >>> Just out of curiosity, do you assume that SIP is the ONLY 
> protocol 
> >>> operating on a particular platform?
> >>>
> >>> If not, then do you assume that each protocol has its own oveload 
> >>> control mechanism and that each will independently determine when
> the
> >>> machine is overloaded?
> >>>
> >>> Mike
> >>>
> >>>
> >>>> -----Original Message-----
> >>>> From: Janet P Gunn [mailto:[email-masked]]
> >>>> Sent: Wednesday, January 03, 2007 8:53 AM
> >>>> To: Darshan Bildikar
> >>>> Cc: 'Volker Hilt'; 'sipping'
> >>>> Subject: Re: [Sipping] RE: Queries and commentson 
> >>>> draft-hilt-sipping-overload-00.txt
> >>>>
> >>>>
> >>>>
> >>>> I think it is important to focus on overload of the ability to 
> >>>> PROCESS SIP messages.  In particular, the focus should be on the 
> >>>> situation where, if the SIP messages keep coming, the box will 
> >>>> crash (usually preceded by unproductive thrashing).
> >>>>
> >>>> As such, the mechanism and messaging must be as "lightweight"
> >>>> as possible, in order to avoid making the machine 
> congestion worse.
> >>>>
> >>>> The other kinds of resource specific overload mechanisms you 
> >>>> discuss sound very useful.  But I don't think it is a 
> good idea to 
> >>>> try to overload them on THIS effort.
> >>>>
> >>>> Janet
> >>>>
> >>>>
> >>
> >>
> >> _______________________________________________
> >> 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, 4 Jan 2007 19:03:13 -0800

Mike,

> overload of end host node supporting VoIP application

Maybe we pull out our laptops (end host node) at the IETF meeting and
you can show me how a VoIP application can overload it. Unless you have
an antique PC with collectors' value :-)

The same applies to SIP phones. DDOS is a security issue.

> over-provisioning may not always be the most cost-effective use of

A comparison between the cost of over-provisioning and the cost of
complexity would indeed be very interesting for VoIP before plunging
into the SIP overload work.

> Hope that restores your sanity. :)

Not quite.

Maybe we have a misunderstanding and you refer to the endless collection
of SIP feature servers in VoIP networks, in which case I am in full
agreement. The correct alternative to this is to place the features in
the end host nodes (SIP UA) and use SIP as it is defined in RFC 3261: 
A discovery and rendezvous protocol (with as little state in the proxy
as possible).

Let the flames come...

Henry

-----Original Message-----
From: Michael Hammer (mhammer) [mailto:[email-masked]] 
Sent: Thursday, January 04, 2007 11:00 AM
To: Henry Sinnreich; Volker Hilt; Tom-PT Taylor
Cc: sipping
Subject: RE: [Sipping] RE: Queries and

Henry,

Mike

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 05 Jan 2007 09:46:56 -0500

Henry,

I agree with you that many features that are being provided in the 
network could be provided in the endpoints, and that doing so would 
eliminate some potential failure points. But there are some services 
that just don't work very well that way. For instance voicemail service 
for devices that aren't permanently connected to the network.

I suppose we could assume that every user should have his own voicemail 
server sitting in his home, permanently connected and powered. That may 
work for some people, but others may want to outsource that. In a way 
this is analogous to network based services for doing file system 
backups - every user could have their own, but its not an operational 
model that works for everyone.

Also, there is bound to be some centralization when the customer is a 
business. For instance a call center.

So I think there will remain important targets for DOS attacks.

	Paul

---

From: "Henry Sinnreich" <[email-masked]>
Date: Fri, 5 Jan 2007 15:21:21 -0800

Mike,

>But there are some services 

>for devices that aren't permanently connected to the network.

Actually, voice mail is an excellent example, since VM can be more
reliable provided in endpoints in a distributed P2P SIP network. See
section 5.1 here

http://portal.acm.org/citation.cfm?id=1065999 

The prototype for this system has been implemented and is reported
elsewhere in a tech report from Columbia University. 

Skype has voice mail as well, most likely not in data centers full of
servers for their 120 million users, but rather in their p2p network. 
BTW: Does anyone here have more info on this?

> business. For instance a call center.

This is another good example. A call center agent workstation can be
implemented as a peer in P2P as well.

This discussion is really not about VM and call centers, but about
services in the network (AKA the mutation of the IN) versus the "dumb
network" with the applications in the endpoints.

I can't help remembering what happened to the IN vs. the "dumb network",

but I guess this is not a topic for this list. 

Coming back to overload for SIP, P2P is the better approach, since it
seems to be scalable without any overload problems.

A break during the upcoming P2P SIP WG meeting (let's hope) is good
opportunity to discuss this, or maybe even on the list at
[email-masked] after the P2P SIP WG gets started.

Thanks, Henry

-----Original Message-----
From: Paul Kyzivat [mailto:[email-masked]] 
Sent: Friday, January 05, 2007 8:47 AM
To: Henry Sinnreich
Cc: Michael Hammer (mhammer); Volker Hilt; Tom-PT Taylor; sipping
Subject: Re: [Sipping] RE: Queries and

Henry,

	Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 08 Jan 2007 09:59:38 -0500

Henry,

I can't access the ACM article because I don't have an ACM online 
subscription.

I do understand that there have been proposals for P2P VM 
implementations, where some peer does the work for you. Frankly I just 
don't see how that can be robust, trustworthy, scale sufficiently, *and* 
not present DOS potentials.

I *do* think VM could, to some extent, be addressed using something 
comparable to the home answering machine - a user owned/operated VM 
server. For many that could be a good solution. But not for all. Some 
just won't have a suitable permanent network connection that can host 
such a server. Others won't want to be bothered with the management. 
Certainly in business deployments there has been a tendency to 
centralize such things.

Note that a VM server isn't necessarily a "network service" - it can be 
viewed as simply an alternative endpoint at an edge.

Nor is implementing VM in a P2P network necessarily a solution to DOS. 
The P2P network just becomes the DOS target. Bad guys trying to do 
damage will still try. The details of how that affects the targets may 
vary, but will still most likely be unpleasant and difficult to deal with.

	Paul

---

From: "Michael Slavitch" <[email-masked]>
Date: Mon, 8 Jan 2007 10:50:02 -0500

Paul wrote:

"Others won't want to be bothered with the management. Certainly in business
deployments there has been a tendency to centralize such things. Note that a
VM server isn't necessarily a "network service" - it can be viewed as simply
an alternative endpoint at an edge."

Centralization of administration, not centralization of service.  The
service can be anywhere as long as they operate under centralized control.
Centralization of administration and central servers are very different
animals.  Voice mail is but a message containing audio (and now in some
cases video or documents such as FAX).

Email servers are now trivial parts of  IT systems even for very small
businesses such as Microsoft Small Business Server and similar offerings
from IBM and RedHat.  Voice mail and unified communications are going that
way through automation.  Even in the client-server realm the amount of
effort needed to maintain a voice mail server is becoming low and getting
lower.

The DNS MX record is likely  the best implemented application-specific
extension of DNS and is well used for receipt redundancy in email systems,
which are a mish-mash of central servers (of the Yahoo/Gmail variety),
business systems that hide behind NAT tunnels,  some home systems and user
agents using IMAP or POP.

A little messy but the mail does get through with little central
co-ordination in the core as DNS MX records are not centralized as long as
the domain server is allowed to exist.  Centralized email in the core is a
recent arrival.  Most email until now was edge server based.

But what if the server is not needed because there are redundant user
agents?  There is no MX record equivalent for user agents in DNS and I doubt
there ever will be.  However there is such a thing in the land of P2P.

P2P messaging (voice, text, media),  technically identical to IM, eliminates
the need for servers except as archives and backups.

Redundancy becomes a 'so-what' in that circumstance.