Subject: RE: [Speermint] Congestion and Load Balancing

From: Tim Dwight <[email-masked]>
Date: Thu, 17 Aug 2006 08:45:41 -0500

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
> 
> 
> > -----Original Message-----
> > From: Tim Dwight [mailto:[email-masked]]
> > Sent: Wednesday, August 16, 2006 5:18 PM
> > To: Michael Hammer (mhammer); 'Brian Rosen'; [email-masked]
> > Subject: RE: [Speermint] Congestion and Load Balancing
> > 
> > Mike,
> > 
> > > 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?
> > 
> > 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
> > 
> 

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

---

From: "Michael Hammer \(mhammer\)" <[email-masked]>
Date: Thu, 17 Aug 2006 09:20:13 -0400

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

> 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.
> 
> 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 
> congested device A.x"

---

From: "Brian Rosen" <[email-masked]>
Date: Thu, 17 Aug 2006 10:36:56 -0400

The following is copied from our charter:
In addition, SPEERMINT considers and documents requirements
for the feedback of operational conditions (e.g., congestion control)
that enables the application of dynamic policy and recognizes
that various mechanisms for achieving this should be studied as
a potential part of any architecture. In future, as its initial
work completes and the requirements become known, SPEERMINT may seek
rechartering to consider various mechanism to support applying
Quality of Service and/or traffic engineering mechanisms in an
architecturally sound way in support of real-time Session
PEERing. A charter discussion would consider how to work with
with mechanisms developed by other working groups, selecting
and integrating those, but as stated, first the initial milestones
must be completed.

And

The most focused deliverables of SPEERMINT are best current practices
regarding exchange of real-time sessions among VoIP and other
real-time application service providers and, in particular, how
such calls are routed.

So, we can work on requirements, but not solutions right now.  That's where
I am; I understand there are some problems worth looking at.  I understand
there is some technology that has been applied to different problems that
may be applicable.  I know of some applicable work in a different work
group.

However, I don't think there is anything we can use in a BCP, and that's
what we're doing now.  I also think that mechanisms we CAN document in a BCP
are sufficient now.

Brian

> From: Michael Hammer (mhammer) [mailto:[email-masked]]
> Sent: Thursday, August 17, 2006 9:20 AM
> To: [email-masked]; Brian Rosen; [email-masked]