Subject: Re: [Speermint] Congestion and Load Balancing

From: "Brian Rosen" <[email-masked]>
Date: Wed, 9 Aug 2006 20:28:24 -0400

I am aware of the congestion control (overload) work going on.  So far, I'm
suspicious of it, because I don't see any experimental or simulation studies
that show the effects of trying to control congestion in SIP.  We'll see how
it develops.

I'm very suspicious of what looks like very simple dynamic feedback control
on the peering point.  We've seen this kind of thing many times before.  The
Internet is very fast, and feedback loops tend to oscillate wildly really
easily.  You almost always need a dampener, and sometimes something more
exotic.  I'm pretty sure a straight dynamic "I'm full" mechanism will not be
stable.  I have no idea what kinds of filtering we need, and what kind of
"frequency response" we need, but I'm pretty sure we need some.  I don't
know if we want simple on/off ("bang-bang) control, or proportional control.
I don't even know if we understand how you measure congestion in these kinds
of systems.

Please dream up a mechanism and go try it.  Let us know how it does.  There
are some pretty useful simulation mechanisms for networks around, simulation
results rarely match real world results, but they are informative.  Better
if you could try it on real networks.

But please don't just propose a dynamic feedback type "loop control" without
a good set of definitions, an understanding of what and how you are
measuring, a viable control mechanism, a filter/dampener and some inkling of
how well it works on real or simulated traffic.

Brian

> -----Original Message-----
> From: Daryl Malas [mailto:[email-masked]]
> Sent: Wednesday, August 09, 2006 6:12 PM
> To: Brian Rosen
> Cc: 'Michael Hammer (mhammer)'; 'Patrick Melampy'; 'Klaus Darilion';
> [email-masked]
> Subject: RE: [Speermint] Congestion and Load Balancing
> 
> I apologize if I am restating or missing this, but I am going to jump
> in...so a shut up and go away is acceptable. ;-)
> 
> Just to throw in my two cents...I think there are two different issues
> to solve here.  First, dynamic congestion control in SIP.  Rosenberg,
> Hilt, and myself are working on this problem...but definitely appreciate
> input.  Second, policy based congestion control for peering.  I think
> this second aspect is the beast we are trying to tackle in this working
> group. This second aspect was going to be apart of the policy function
> in the peering architecture.  Now, how does it dynamically update the
> sender...I had initially recommended a subscribe mechanism where an
> expiry timer will essential force the peer to re-subscribe to gain new
> policy information...this could include updated congestion information
> for changing the destination signaling function...or may say...go
> away...I can't handle any more traffic.  Either way, this second method
> is in addition to the SIP congestion/overload method...yet specific for
> the peering environment.
> 
> What do you think?
> 
> --Daryl
> 
> On Wed, 2006-08-09 at 17:37 -0400, Brian Rosen wrote:
> > 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
> >
> > > -----Original Message-----
> > > From: Michael Hammer (mhammer) [mailto:[email-masked]]
> > > Sent: Wednesday, August 09, 2006 5:09 PM
> > > To: Brian Rosen; Patrick Melampy; Klaus Darilion
> > > Cc: [email-masked]
> > > Subject: RE: [Speermint] Congestion and Load Balancing
> > >
> > > So, we can't invent anything new unless it has already been invented?
> > >
> > > I don't think I agree that only manual methods of configuring peers is
> > > the only way to go.  I presume that VSPs in a federation may come and
> > > go, and that traffic between peers will come and go.  It seems like on
> > > some time scale slower than call setup and faster than a contract
> > > negotiation, there ought to be a way to adjust parameters of peers to
> > > reflect a balance between traffic offered and resources available.
> > >
> > > When contacted based on a DNS lookup, it doesn't seem that bad to tell
> a
> > > peer which has shown it is part of a federation which proxy (farm) to
> > > use and what parameters to stay within.
> > >
> > > Mike
> > >
> > >
> >
> >
> > _______________________________________________
> > Speermint mailing list
> > [email-masked]
> > https://www1.ietf.org/mailman/listinfo/speermint

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

---

From: "Brian Rosen" <[email-masked]>
Date: Mon, 14 Aug 2006 16:09:28 -0400

I agree that people confuse media congestion issues and signaling congestion
issues and really need to keep them straight.

I can't see how PSTN call gapping can be applied usefully, especially in any
non-trivial way, to SIP signaling.  Perhaps there is something fundamental
that I'm missing, but none of the techniques I know can usefully be applied.
Perhaps you could share some thoughts there.

Brian

> Sent: Monday, August 14, 2006 3:14 PM
> 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
> 
> 
> > 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]
> > 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
> >
> >

---

From: "Reinaldo Penno" <[email-masked]>
Date: Tue, 15 Aug 2006 10:24:23 -0400

>From RFC3198

"$ policy
      (P) "Policy" can be defined from two perspectives:
          -  A definite goal, course or method of action to guide and
             determine present and future decisions.  "Policies" are
             implemented or executed within a particular context (such
             as policies defined within a business unit).
          -  Policies as a set of rules to administer, manage, and
             control access to network resources [RFC3060].

Westerinen, et al.           Informational                      [Page 7]

RFC 3198        Terminology for Policy-Based Management    November 2001

          Note that these two views are not contradictory since
          individual rules may be defined in support of business goals.
          (See also "policy goal", "policy abstraction" and "policy
          rule".)"

> Sent: Tuesday, August 15, 2006 6:50 AM
> To: Reinaldo Penno; 'Michael Hammer (mhammer)'; 'Patrick Melampy';
'Klaus
> Darilion'
> I think you walk before you run.
> 
> We start with really simple mechanisms that have the desirable
> characteristic that they work for the actual problem at hand now, and
then
> as time evolves, the capacity issues and complexity issues will
expand,
> and
> the solutions need to expand.
> 
> It is not at all clear to me that we need to discover policy.  We may
need
> to discover state (like failure or congestion state), but I see policy
as
> relatively static.  As I said before, I'm not opposed to discovering
> policy
> as opposed to provisioning it, but I don't think it's at all dynamic.
It
> changes over periods of months, not milliseconds.
> 
> I don't think we are chartered to do anything approaching SIP BGP
> 
> Brian
> 
> > From: Reinaldo Penno [mailto:[email-masked]]
> > Sent: Tuesday, August 15, 2006 9:10 AM
> > To: Michael Hammer (mhammer); Brian Rosen; Patrick Melampy; Klaus
> Darilion
> > Cc: [email-masked]
> > 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

---

From: "Brian Rosen" <[email-masked]>
Date: Wed, 16 Aug 2006 09:35:31 -0400

-----Original Message-----
From: Brian Rosen [mailto:[email-masked]] 
Sent: Wednesday, August 16, 2006 9:14 AM
To: 'Reinaldo Penno'; 'Michael Hammer (mhammer)'; 'Patrick Melampy'; 'Klaus
Darilion'
Cc: [email-masked]'

Right at the moment, I think policy is so static it could be provisioned,
but I'm not against discovery.

I don't think we have any experience with "state" that could reasonably
defined in a BCP (and I think that is the basic document this group is
supposed to create).  Specifically, any kind of SIP change, which would
include an event notification package, is subject to the sip change process,
and thus needs a trip through SIPPING, and probably SIP.

I don't think we should go there now.  Maybe, after the current overload
work is completed in SIP, we can decide if that is sufficient, or needs some
applicability guidance, or extension for the peering case.

Brian

> Sent: Tuesday, August 15, 2006 10:14 AM
> To: Brian Rosen; Michael Hammer (mhammer); Patrick Melampy; Klaus Darilion
> Cc: [email-masked]
> Okay, let's get our nomenclature aligned.
> 
> Policy - changes in a period >> than state
> 
> State - attributes about the layer 5 peering that could potentially
> change from one call to the other.
> 
> Now, you agree we should discover state and policy (although policy is
> more static in nature). Although the timescales are different, should
> the same method be used for both or not?
> 
> Policy could potentially be discovered through configuration (triggered
> by contract), DNS, SIP, etc.
> 
> State on the other hand needs a mechanism that allows the update (by the
> "owner") and queries (by others) quite frequently.
> 
> Is this okay?
> 
> Regards,
> 
> Reinaldo
> 
>

---

From: "Brian Rosen" <[email-masked]>
Date: Wed, 16 Aug 2006 09:36:24 -0400

I believe you can limit the total bandwidth into the peering system by
contract, and you can limit the bandwidth between two peers by contract, and
that is enough, for now.

I don't think we have any problems building peering systems that can do
that, and work satisfactorily.

Yes I DO think that the media limit is the actual limit, but again, I think
that is a simple bandwidth calculation, and primarily a between-two-peers
number that could be governed by the peering system agreements or a
bilateral agreement.  I do think statistics plays a role (you
"overprovision"), but it always has in telephone engineering.  

The difference between VoIP and TDM is the 3 or 4 order of magnitude
difference in call capacity for a single signaling element, and the roughly
2-3 order of magnitude difference in engineered "media" capacity.

Where in a telephone system, you have a DS0 or two to a residence, you have
500K to a meg.  Where typically you have some number of OC-3s between a
central office and a tandem, you have a gig.  Where tandem networks are
typically 155 or at best 522, you have 10G.

I think it's not hard to make it possible to avoid blocking on anything
except the actual destination resource (which could be a gateway).  You can
obviously get to enough failures where that doesn't work, and I think BUSY
is a satisfactory response in that case.

I recognize the issue of cascading 503s to create more problems than they
solve.  That is the overload work going on.  Let it finish, and we'll use
it.

Brian

> Sent: Tuesday, August 15, 2006 11:30 AM
> Brain,
> Even within a federation, if you know there are hundreds of peers in
> that federation, do you limit each peer to 1/100 of the signaling BW
> available at your peering point, or do you monitor how many peers are
> loading you with call attempts at the moment and set envelope parameters
> accordingly?
> 
> What I was looking for was the ability to throttle back inputs *before*
> a signaling message, e.g. INVITE, is sent to the peering point, rather
> than reacting to an overload of INVITEs.  This mechanism should be a
> derivative that looks at acceleration rather than velocity.  An "out of
> band" mechanism such as a Subscription/Notify mechanism passing policy
> information informing a peer of the initial rules about permitted
> traffic rate or changes to those rules could be sufficient.  Call
> gapping effectively does the same thing by limiting the flow of
> signaling inputs for periods of time.
> 
> Your bit about engineering probabilities sounds like a euphemistic
> phrase for over-provisioning that shifts the bottleneck to being the
> media path.  I think there is a trade-off economically between
> over-provisioning and adding a little more complex controls.
> 
> Mike
> 
> 
> > Sent: Monday, August 14, 2006 5:43 PM
> > To: 'Patrick Melampy'; Michael Hammer (mhammer); 'Klaus Darilion'
> > Cc: [email-masked]
> > I think you need a different work group for a different problem.
> >
> > I think we have been consistently talking about federations,
> > and not adhoc
> > routing by individual bilateral peering relationships.  This
> > is not a BGP
> > network.
> >
> > I think that we will allow transit networks, but I expect them to be
> > simplistic and uncommon and if the federations themselves
> > don't arrange
> > transit among themseleves, one or two carriers will.  The
> > number of cases
> > where there are more than three hops between carriers will be
> > small, and
> > overoptimizing such cases, especially on first pass, is unwise.
> >
> > The probability of a transit carrier being a bottleneck is
> > just not worth
> > spending time on now.  It's just too easy to engineer the
> > probabilities low
> > enough that simple mechanisms suffice.
> >
> > I keep imagining you think it's hard to build transit
> > networks that support
> > 400% of the peak busy hour bandwidth between federations with 5 nines
> > reliability.  I don't see it that way.   Certainly, with respect to
> > signaling, that is just the kind of normal capacity we create now.
> >
> > Media could be a different problem, but we agree we aren't
> > talking about
> > media.
> >
> > Brian
> >
> >
> > > From: Patrick Melampy [mailto:[email-masked]]
> > > Sent: Monday, August 14, 2006 5:16 PM
> > > To: 'Michael Hammer (mhammer)'; 'Brian Rosen'; 'Klaus Darilion'
> > > Cc: [email-masked]
> > > Agreed -- lets just focus on signaling.
> > >
> > > I believe the congestion controls that are required need a
> > new name, as
> > > its
> > > confusing everybody but me. I believe the issue (and I do not have a
> > > solution) is introduced when you introduce peering. Thus
> > peering will
> > > create
> > > the need. Let me explain....
> > >
> > > Consider VoIP Domains A, B, C, D, E, F, G, and H
> > >
> > > Lets also assume that somehow they have exchanged
> > information such that a
> > > network of connectivity has been established. Let me draw it below
> > >
> > >
> > > A---D-----E---+
> > >     |         |
> > > B---C         H
> > >     |         |
> > >     F-----G---+
> > >
> > > The above adjacencies and business relationships are all
> > established. The
> > > list of adjacencies include:
> > >
> > > A-D
> > > D-E
> > > D-C
> > > B-C
> > > C-F
> > > F-G
> > > E-H
> > > G-H
> > >
> > > It is easy to understand that A can communicate with Domain
> > H through D
> > > via
> > > two paths...
> > >
> > > 1.) A-D-E-H
> > > 2.) A-D-C-F-G-H
> > >
> > > Domain D has to choose -- which path to take, 1 or 2.
> > >
> > > Obviously, the best path is out of scope for Speermint, and
> > is likely to
> > > be
> > > based on policy local to domain D. However, Path 1 and Path
> > 2 are not
> > > limitless, and may experience overload conditions not
> > detectable at A or
> > > H.
> > > For example, What if B had a large volume of traffic
> > destined for E or the
> > > path was diminished by equipment failures. A and H are not
> > be affected,
> > > but
> > > one of the intermediate domains on one of the paths is.
> > >
> > > So at the egress of D, Domain D must decide which next hop
> > to use. Where
> > > will D get information that traffic to E may effect
> > choosing a route to
> > > take?
> > >
> > > I believe that one could make really complex examples that
> > are indeed very
> > > likely.
> > >
> > > One could argue that service provider peering has forced
> > this problem on
> > > us,
> > > and if we dis-intermediate all of the domains that are not
> > terminal, the
> > > problem goes away.
> > >
> > > What we need is a way to report that Path 1 is either down
> > or diminished.
> > >
> > > I have no idea how to make this work just yet. But I think
> > we need to
> > > explore that fact that disintermediation creates this
> > problem, and thus
> > > this
> > > problem needs to be solved.
> > >
> > >

---

From: "Michael Hammer \(mhammer\)" <[email-masked]>
Date: Wed, 16 Aug 2006 16:48:08 -0400

Brian,

Last questions, then I think we need to just agree to disagree.

Is it possible to summarize all the bilateral static agreements of
allowed traffic to be terminated at one peer into an XML document?  And
if all those peers agree not to exceed the traffic envelope described in
that XML document, could you not agree that the receiving peer could be
assured that the bulk (99%) of statistical distribution of call arrivals
would be within engineered limits of the system?  (And those that do
exceed can be handled via INVITE rejections contemplated by SIPPING.)

BTW, I see this as more analogous to the CAC for ATM or MPLS paths
granted admission to the system, with committed and burst rates allowed,
where the cells are the INVITEs processed by the system.  More to the
point, the path reservation mechanism of RSVP, where BW per path may be
bumped up or down, is what you are saying is too hard to do.  Products
to do this exist.

Mike

> Sent: Wednesday, August 16, 2006 2:34 PM
> To: Michael Hammer (mhammer); [email-masked]
> In line
> > Sent: Wednesday, August 16, 2006 12:03 PM
> > To: Brian Rosen; [email-masked]
> > Inline.
> > > Sent: Wednesday, August 16, 2006 11:12 AM
> > > To: Michael Hammer (mhammer); [email-masked]
> > > I think peering is functionally a star: peers have some 
> collection 
> > > of elements facing the peering fabric and peering goes 
> from one edge 
> > > to the other.  The "fabric" may be nothing but an IP network.  It 
> > > may even be the Internet.  There may or may not be any active 
> > > element at the hub of the star.  If there is, it's a 
> proxy server.  
> > > If there isn't, it's just an IP switch or functional equivalent.
> > 
> > OK
> > 
> > > If the federation, by contract, limits the total number of calls 
> > > towards the fabric from any one peer, and either 
> federation contract 
> > > policy or bilateral contract policy limits traffic between two 
> > > specific peers, I think we can create non-blocking peering (or at 
> > > least non blocking to the point where the incidence of 
> blocking is 
> > > low enough that we can ignore it and busy the call).  I 
> think that 
> > > is sufficient.
> > 
> > So, every time there is a new peer we need to renegotiate 
> all contracts?
> No.  Some new bilaterals MAY be needed.  I can't imagine any 
> peer LOWERING any constraints on existing peering 
> arrangements to handle a new peer.  This is just like IP 
> peering in this regard.
> 
> > 
> > How do we can figure out how much traffic can be exchanged 
> between two 
> > peers statically?
> Are you asking how do peers determine what the actual value 
> should be in a bi-lateral agreement?  I think that is mostly 
> determined by what the expectation is between the peers of 
> what "normal" traffic would be, with some allowance for 
> abnormal.  I think it's accumulated experience, and I think 
> it's very unsophisticated.  It's more of a limit on the 
> extent abnormal traffic can be dealt with (for example, are 
> peering with the network that supports American Idol?)
> 
> > Then, next question is what factors would cause us to change that?
> Experience
> 
> > Then, is there any reason this can not be adjusted dynamically?
> Yes.  We don't know how to do that reliably yet, and we don't 
> really need to make it more complex -- simple mechanisms will work.
> 
> > 
> > I am not worried about the IP fabric between the peers as 
> that is an 
> > IP network congestion problem.  My issue is "congestion" at the 
> > receiving point.  Are we still addressing the same problem?
> Yes, although I think "receiving point" has two meanings:
> 1) The ingress point for the termination peer in the peering 
> system.  I think this can be made to be large enough that we 
> don't need anything at the origination side that responds in 
> anything but trivial ways.
> 
> 2) The actual termination point (or the proxy that directly 
> serves it) in the termination network.  This really is a busy 
> condition, and can be reflected back to the originating UA as busy.
> 
> > 
> > > The SIP overload work is dealing with the 503 issue.  I 
> don't have 
> > > anything to offer beyond that work, do you?
> > >
> > > I am extremely suspicious of simplistic congestion control 
> > > mechanisms that try to push congestion knowledge back 
> earlier in a 
> > > network.
> > 
> > Are you talking L3 or L5 network congestion here?
> L5, L3 CAN be dealt with using well understood mechanisms.
> 
> > 
> > I was thinking that we are talking about knowledge being 
> passed from 
> > one peer to one adjacent peer, that is, only one hop away.
> Yes, that is what I understood you to be worried about.  I 
> don't see that as a problem worth solving = we can build 
> those parts of the network beefy enough that the probability 
> of congestion is low enough to pretty much ignore.  Again, 
> I'll admit to the cascading 503, I think the SIP overload 
> work addresses that, and we can use what they come up with 
> for that problem.
> 
> 
> > 
> > > We have LOTS of experience that getting them right is not easy.  
> > > Look at the archives on "Explicit Congestion Notification" in TCP 
> > > for example.
> > 
> > Can you explain the analogy here?  Does ECN address 
> pair-wise traffic 
> > levels, or is it more concerned with cross-traffic in the fabric 
> > between the peers.  There are a lot of unkowables in TCP that don't 
> > exist in this case.  Also, the scale at which TCP needs to 
> operate is 
> > much larger.
> ECN addresses the effect of aggregate congestion on a 
> specific pairwise TCP connection.  I think that TCP is more 
> complex, because the number of messages per transaction in 
> SIP is so much fewer than the number of messages
> in a typical TCP session.   You typically don't limit how 
> many TCP sessions
> can be created in the middle of the network (you do at the endpoints).
> However, the point is that reflecting congestion state 
> backwards in the network, and effectively using that 
> information to control traffic presented to a specific point 
> in the network, regardless of the exact circumstances, has 
> proven, many times over, to be hard problem, not yielding to 
> simplistic solutions.  
> 
> > 
> > > Unless you can
> > > show me a big network successfully using SUB/NOT to push 
> congestion 
> > > state backwards, then I don't believe it will work.
> > 
> > This is an argument that SUB/NOT should not be used for 
> anything the 
> > first time.
> No, it's an argument that any attempt to define a congestion 
> control mechanism that reflects congestion state backwards is 
> hard.  It's not SUB/NOT that is the problem, it is backwards 
> flowing congestion advice.
> Strictly speaking, it's not the advice that is hard, it is 
> describing when to send it, and how to react to it that is hard.
> 
> 
> > 
> > > I guarantee it won't work if it's literally just a 
> notification to 
> > > stop: that is, there is no explicit text on how you 
> control the rate 
> > > of messages, and how you control the on/off nature of the 
> mechanism 
> > > so that it has dampening.
> > > Getting such text right, and behavior right at both ends, is hard.
> > >
> > > Brian
> > 
> > I am not saying that it might not be hard, I just don't buy 
> that as a 
> > reason for not trying.  Imagine if you had said that at the 
> advent of 
> > TCP (your words with a few substitutions):
> > 
> > "If the *network*, by contract, limits the total number of
> > *packets* towards the fabric from any one peer, and either
> > *network* contract policy or bilateral contract policy 
> limits traffic 
> > between two specific peers, I think we can create non-*congestion* 
> > peering (or at least non *congestion* to the point where 
> the incidence 
> > of *congestion* is low enough that we can ignore it and *reject the 
> > traffic*).  I think that is sufficient."
> > 
> > TCP would not have throttling mechanisms and offered 
> traffic would be 
> > statically limited.
> Of course.  Same can be said of BGP.  An ENORMOUS amount of 
> work has gone into developing the algorithms that are 
> involved in congestion control in those protocols.  They are 
> not at all simple, and we didn't arrive at them whole cloth.  
> I believe congestion control efforts in SIP will follow a 
> similar path, and they will involve a bunch of simulation 
> and/or real world testing.  When we have some, then it will 
> be time for protocol development.
> 
> And, I don't see the need yet.  Overengineer the peering 
> system for now, until we have a more efficient answer.  Even 
> then, it may not be worth deploying a more complex system.  A 
> lot of the Internet relies on the realization that more 
> bandwidth (and routing capacity) is cheaper than complex 
> mechanisms that limit the amount of capacity you need.  
> That's where we are right now; cheaper and easier to give you 
> more bandwidth that to define and implement working 
> congestion control mechanisms.
> 
> Brian
>

---

From: "Michael Hammer \(mhammer\)" <[email-masked]>
Date: Thu, 17 Aug 2006 10:00:37 -0400

Agreed.  I am looking for something as simple as possible.

Mike

> From: Tim Dwight [mailto:[email-masked]] 
> Sent: Thursday, August 17, 2006 9:46 AM
> To: Michael Hammer (mhammer); 'Brian Rosen'; [email-masked]
> Good to know I wasn't completely lost :)
> 
> I agree of course with respect to proactive overload 
> controls, and the inadequacy of session-level "source 
> quench".  But I also agree with Brian's point about 
> complexity... even seemingly simple controls can have 
> unforseen consequences.  That doesn't mean I prefer to do 
> nothing, but I think whatever we do needs to be 
> simple-but-provably-useful and well grounded in both theory 
> and practice.
> 
> tim
> 
> > Tim,
> > 
> > I think you do get what I am after.  My interest was solely 
> in the L5 
> > SIP traffic between domain egress and ingress points.  And I was 
> > looking for proactive versus reactive solutions, since one you get 
> > behind the power curve on this, one could find themselves 
> not able to 
> > reject requests fast enough to quench all the sources.
> > 
> > Mike
> > 
> > 
> > > From: Tim Dwight [mailto:[email-masked]]
> > > Sent: Wednesday, August 16, 2006 5:18 PM
> > > To: Michael Hammer (mhammer); 'Brian Rosen'; [email-masked]
> > > Mike,
> > > I take it that your concern is not to be with congestion *in the 
> > > fabric", but rather congestion in one peering partner's
> > network.  If I
> > > understand you correctly you are arguing that means ought 
> to exist 
> > > whereby the congested network can notify its peers to
> > reduce the load
> > > they are imposing on the congested network.
> > > 
> > > If that's not the gist please accept my apologies.  This 
> discussion 
> > > has been hard to follow.
> > > 
> > > If it is, I'd observe that:
> > > 
> > > 1. the problem seems realistic (congestion happens even in "well 
> > > engineered networks").
> > > 
> > > 2. solutions to this problem do exist in other domains, so not 
> > > addressing it would
> > >    seem a step backward
> > > 
> > > 3. ideally the semantics for communicating congestion 
> would support 
> > > both selective and general
> > >    overload controls.
> > > 
> > > 4. selective controls need to be based on externally-meaningful 
> > > information.
> > > Given that 
> > >    networks don't typically share topological information this 
> > > probably means basing
> > >    such controls on AoRs.  To be scalable we'd need these
> > to aggregate
> > > somehow (so that
> > >    network A could refer to "all AoRs associated with
> > congested device
> > > A.x"
> > > without listing
> > >    them).
> > > 
> > > tim
> > > 
> > 
>

---

From: "Khan, Sohel Q [CTO]" <[email-masked]>
Date: Thu, 17 Aug 2006 10:15:53 -0500

I agree with this.
We need a proactive but simple mechanism for L5 congestion/overload
control.

Sohel 

-----Original Message-----
From: Tim Dwight [mailto:[email-masked]] 
Sent: Thursday, August 17, 2006 8:46 AM
To: 'Michael Hammer (mhammer)'; 'Brian Rosen'; [email-masked]
Subject: RE: [Speermint] Congestion and Load Balancing

I agree of course with respect to proactive overload controls, and the
inadequacy of session-level "source quench".  But I also agree with
Brian's point about complexity... even seemingly simple controls can
have unforseen consequences.  That doesn't mean I prefer to do nothing,
but I think whatever we do needs to be simple-but-provably-useful and
well grounded in both theory and practice.

tim

> Tim,
> 
> I think you do get what I am after.  My interest was solely in the L5 
> behind the power curve on this, one could find themselves not able to 
> > understand you correctly you are arguing that means ought to exist 
> > If that's not the gist please accept my apologies.  This discussion 
> > has been hard to follow.
> > 
> > 3. ideally the semantics for communicating congestion would support