Subject: RE: [Speermint] Congestion and Load Balancing

From: "Reinaldo Penno" <[email-masked]>
Date: Tue, 15 Aug 2006 09:13:20 -0400

I think there is enough middle ground between nothing and a full fledge
SIP BGP.

You can start with simple enough mechanisms such with plain text file
configuration, DNS, SIP Subscribe/Notify all the way to some SIP BGP.

What we need to agree first is: Is there a problem to be tackled? Is
there a need for some kind of policy discovery (whatever that is at this
point)?

Regards,

Reinaldo

> -----Original Message-----
> From: Michael Hammer (mhammer) [mailto:[email-masked]]
> Sent: Monday, August 14, 2006 12:14 PM
> To: Brian Rosen; Patrick Melampy; Klaus Darilion
> Cc: [email-masked]
> Subject: RE: [Speermint] Congestion and Load Balancing
> 
> Brian,
> 
> It might be useful to keep the IP network traffic congestion control
and
> the signaling overloading the SIP Proxy control concepts separate.
Some
> of the later emails in this thread seemed to be headed down a media
> congestion path.
> 
> Also, when talking about things in the "stuff we pretty much know
works"
> category, are you excluding the experiences with call gapping from the
> PSTN?  I think there may be some pretty strong analogies that can be
> made.  And I am pretty sure that the control software in switches is
> running code.
> 
> Mike
> 
> 
> > -----Original Message-----
> > From: Brian Rosen [mailto:[email-masked]]
> > Sent: Wednesday, August 09, 2006 5:38 PM
> > To: Michael Hammer (mhammer); 'Patrick Melampy'; 'Klaus Darilion'
> > Cc: [email-masked]
> > Subject: RE: [Speermint] Congestion and Load Balancing
> >
> > Please don't get me started on the IETF's abandonment of its
> > belief in running code.
> >
> > While occasionally we actually just document something that
> > exists, we usually end up extending somewhat from something
> > we know works.  We have pretty bad experience inventing major
> > new functionality ESPECIALLY IN CONGESTION CONTROL, and
> > seeing it work.  It almost never does.
> >
> > So, sure, we can invent some new stuff, as long as it is some
> > likely-to-work extension of stuff we pretty much know works.
> >
> > Let me cite an example.  ICE is a pretty complex piece of
> > machinery, but it's built on a base of work we KNOW will
> > work.  ICE may have a bunch of text to tweak as we gain some
> > implementation experience, but we know it will work.
> >
> > I'm not aware of any work in this area we know works we can
> > build from.  Can you cite some?
> >
> > I'm not particularly opposed to having discovery mechanisms
> > for proxy domain names, call rates and bandwidth limits
> > rather than provisioning.  I'm skeptical they would be used,
> > but it's simple enough.  I am opposed to trying to say that
> > info varies from call to call, but something faster than a
> > contract negotiation does seem practical.
> >
> > That's a far cry from anything we would consider to be
> > dynamic congestion control.
> >
> > Brian
> >

_______________________________________________
Speermint mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/speermint

---

From: "Geoff Devine" <[email-masked]>
Date: Tue, 15 Aug 2006 14:47:18 -0400

I think this is indeed a problem that needs to be solved and I agree
with the middle ground approach.  In my opinion, the proper approach is
to define an XML-based event package to signal congestion attributes via
SUBSCRIBE/NOTIFY.  

These attributes would be:
* supported connection/call rate, perhaps in units of calls per second
* total number of connections/calls available
* current utilization

A peering point in the network could assert flow control by dynamically
sending a NOTIFY lowering the call/connection rate.  It could also
choose to dynamically shrink the "size of the pipe" by lowering the
total number of connections/calls available.  This is analogous to
busying out a CIC in the SS#7 ISUP world.

Bear in mind that my agenda is to solve the problem of using remote
media gateway resources in the federation.  These are finite resources
that you expect to run out at peak busy hour.  You don't want to run
your peering federation without congestion control since it makes the
network unstable by injecting end-to-end work at peak busy hour that
doesn't complete.  Your media gateway controllers won't be able to keep
up with the remote signaling traffic.  

There are a number of possible architectures and topologies that could
make use of this sort of mechanism.  Rather than argue over which
architecture or topology is best, I'd rather take the pragmatic approach
and create the interface to extract the information to implement
congestion control over SIP as the first step.

Geoff

-----Original Message-----
From: Reinaldo Penno [mailto:[email-masked]] 
Sent: Tuesday, August 15, 2006 9:13 AM
To: [email-masked]
Subject: RE: [Speermint] Congestion and Load Balancing

Regards,

Reinaldo

and
Some
works"