Subject: RE: [Speermint] Secure RTP

From: "Michael Hammer \(mhammer\)" <[email-masked]>
Date: Thu, 3 Aug 2006 15:12:53 -0400

The focus of Speermint should be centered around whether one can
discover the policies of a potential peer and whether those policies can
systematically describe the requirements on multiple levels that will
need to be supported to have a successful communication with that peer.

It is not about specifying X, Y, Z, or <name your favorite MUST here>

Is is about whether the policy can be stated so one knows that X, Y, ...
is required to peer.

I suspect that each federation will select different MUSTs for each
category of choices we come up with.

Mike

> -----Original Message-----
> From: Hadriel Kaplan [mailto:[email-masked]] 
> Sent: Tuesday, August 01, 2006 4:09 PM
> To: 'Brian Rosen'
> Cc: [email-masked]
> Subject: RE: [Speermint] Secure RTP
> 
> But there are currently 11(?) proposed SRTP key exchange 
> mechanisms, some using SDP, some not - none of which 
> interoperate.  So "interoperability" is impacted there, and 
> part of it is a signaling issue.  In that sense it may well 
> be reasonable for a speermint BCP to pick one preferred 
> mechanism, but I'm sure that will be yet another rat-hole.  
> And I recommend we stay out of those when we can.  :) 
> (besides, the RTPSEC-BOF group is assigned that Herculean task)
> 
> -hadriel
> 
> 
> > -----Original Message-----
> > From: Brian Rosen [mailto:[email-masked]]
> > Sent: Tuesday, August 01, 2006 3:33 PM
> > To: 'Andrew Newton'
> > Cc: 'Khan, Sohel Q [CTO]'; [email-masked]
> > Subject: RE: [Speermint] Secure RTP
> > 
> > Sure, but does the peering touch the media?  I claim it doesn't, at 
> > least normally.  "Getting it right" means that when the signaling 
> > happens, the resulting SDP will work.  That part (the SDP part) 
> > matters to us, because we have to make sure that when that 
> SDP gets to 
> > the other side, it will result in something that works.  
> The peering 
> > system doesn't have to even look at the SDP, it just has to 
> have rules 
> > that make interoperability work.
> > 
> > The peering system has to, for example, make sure that an address 
> > given in the SDP on one side is actually reachable on the 
> other side.  
> > Doing that doesn't involve any work, it's just rules the federation 
> > agrees to that makes that be true. So, we might need to 
> specify no NAT 
> > or conversely, MUST support ICE.  That all speaks to what the peers 
> > have to have between their endpoints and their peers.  It doesn't 
> > imply the media packets traverse the peering fabric.
> > 
> > Of course, in theory, the peering system doesn't even have to touch 
> > the signaling, but we don't have to go there.
> > 
> > Brian
> > 
> > > -----Original Message-----
> > > From: Andrew Newton [mailto:[email-masked]]
> > > Sent: Tuesday, August 01, 2006 3:07 PM
> > > To: Brian Rosen
> > > Cc: 'Khan, Sohel Q [CTO]'; [email-masked]
> > > Subject: Re: [Speermint] Secure RTP
> > >
> > > Brian Rosen wrote:
> > > > I think that we are looking at case 1, and not at case 
> 2.  I don't
> > think
> > > we
> > > > care about the media.
> > >
> > > Interesting.  I don't know about you, but I get paid for 
> getting the
> > media
> > > right.  Perfect signaling is useless without media.
> > >
> > > -andy
> > 
> > 
> > _______________________________________________
> > Speermint mailing list
> > [email-masked]
> > https://www1.ietf.org/mailman/listinfo/speermint
> 
> 
> _______________________________________________
> 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: "Hadriel Kaplan" <[email-masked]>
Date: Thu, 3 Aug 2006 20:40:45 -0400

So you're saying they MUST implement such a policy exchange mechanism??  ;)

To me the srtp and codec "policy" exchange is already there: SDP.

We will probably need MUSTs for some things, because we need 2
speermint-supporting peers to interop.  If two speermint federations can
pick their own MUSTs for basic issues, then they may not interop.  They can
discover each other's policies all day long, but if there's no match we've
screwed up.  I don't put codecs into that basic issues list, because that's
different and dependent per UA.  It could be "normalized", but that's not
easy to get consensus on.

-hadriel

> From: Michael Hammer (mhammer) [mailto:[email-masked]]
> Sent: Thursday, August 03, 2006 3:13 PM
> To: Hadriel Kaplan; Brian Rosen
> Cc: [email-masked]

---

From: "Stastny Richard" <[email-masked]>
Date: Fri, 4 Aug 2006 10:19:54 +0200

IMO the main goal of SPEERMINT is to achieve potential interoperability
between SPEERMINT compliant peers (all of them) - first on L5

This implies two steps:

1. policy
which means at least that the originating SP is able to
find out if the terminating SP is willing to ACCEPT the communication
either direct or via a "transit" SP

We should never forget that the terminating SP has a monopoly
regarding terminating calls. A calling user may choose which
originating SP to use, but for a given AoR ONE and only ONE terminating
network is available.

The "default" option to reach a terminating network via the PSTN is only
available for a subset of communications (voice) and only for a limited
period of time (as long as the PSTN exists)

2. minimum requirements

A peer offering a public communication service may be forced
by regulators to accept all incoming calls provided the originator
and/or an intervening transit SP complies to a minimum set of
requirements. It is the main task of SPEERMINT to define these
requirements.

Again: if the originator does not comply to these requirements, and
end-user
may choose another one. This is not the case for the terminating SP.

Note1: this does not imply that the end-user must accept the call, he
may 
still reject it.

Note2: this does also not imply that the end-user equipment is
compatible

But Note1 and 2 can be handled with normal protocol negotiations.

Richard Stastny

> Sent: Friday, August 04, 2006 2:41 AM
> To: 'Michael Hammer (mhammer)'; 'Brian Rosen'
> Cc: [email-masked]
> So you're saying they MUST implement such a policy exchange
mechanism??
> ;)
> pick their own MUSTs for basic issues, then they may not interop.
They
> can

---

From: "Brian Rosen" <[email-masked]>
Date: Fri, 4 Aug 2006 08:47:19 -0400

I think you have to be careful with the "p" word.

I don't see the purpose in standardizing mechanisms for peers within a
peering federation to discover policies that apply to each other.  That is
provisioning, and there is usually not a lot of value in standardizing
provisioning.  It's not dynamic (in fact, it's usually specified by
contract).

What there is value in is in defining what mechanisms exist to provision.
So, for example, if one of the things peering means is that the rate of
calls is limited in some way, then we probably have to standardize the
definition of limiting, but not the way to determine what the limit is.  In
that way, the vendor who builds the proxy for Peer A will be able to build
in it the ability to meet the policy for Peer B.  This is not a protocol
issue, but it is what you would expect to find in a BCP.

Similarly, it's not clear to me that a federation will necessarily define
all of the potential policy mechanisms, or what their values are limited to.
It clearly WILL do that for some variables, and again, we don't need
automatic provisioning mechanisms to discover these.  Even within a
federation, I think it will be common that bilateral arrangements making
further policy limitations will exist. 

Brian

---

From: "Patrick Melampy" <[email-masked]>
Date: Fri, 4 Aug 2006 09:59:13 -0400

Brian,

I agree with you. However some aspects are protocol worthy. Path
determination -- or said another way -- the next hop network to use to reach
a destination domain, must be partially provisioned, and partially
discovered. The discovery aspects are the dynamic aspects. This would
include things like:
	1.) Proxy Availability
	2.) Reachable Domains
	3.) Congested Domains

In #1 -- proxy availability -- its very similar to how SS7 is used to set
the service states on each and every DS0. SS7 is the protocol family, and
ISUP messages are sent to bring circuits in and out of service. The actual
phone numbers to send down the circuit are provisioned in SS7. In our case
to have a well managed service, we need an equivalent to "circuit service
state", which might be embodied as a call arrival rate, maximum sessions
permitted, and maximum bandwidth to use.

In #2 -- reachable domains -- Unlike the PSTN which uses the NPA-NXX routing
models which are hierarchical and well understood, IP domains are amorphous
and have very unpredictable intersection points. This is why BGP was
invented for routing IP packets. The same is true for SIP based sessions. If
there is to be peering, there will need to be a domain advertisement
protocol that goes network to network. Thus a protocol is required here.

In #3 -- congestion -- is dynamic and not provisionable. It is directly
related to #2, and the congestion detection and prevention mechanisms must
follow in reverse the paths established in #2.

So I think we do have some protocol work here. I also think we need to leave
to the individual networks, any and all decisions on how to run their
networks, choose next networks, etc. 

-----Original Message-----
From: Brian Rosen [mailto:[email-masked]] 
Sent: Friday, August 04, 2006 8:47 AM
To: 'Michael Hammer (mhammer)'; 'Hadriel Kaplan'
Cc: [email-masked]
Subject: RE: [Speermint] Secure RTP

Brian

---

From: "Brian Rosen" <[email-masked]>
Date: Fri, 4 Aug 2006 10:20:11 -0400

I don't think any of this is something we are chartered to do.  I don't
think it's needed, at least for a long time, possibly forever.  

We have lots of experience building "farms" of servers that handle HTTP
load, and I don't see any reason we shouldn't use all of those techniques to
deal with SIP load.  I certainly don't see reasons to make the originator
aware of congestion issues at the terminating domain, beyond the contractual
limits that may be in place.

I don't see any reason why peers should be aware of element failures.  We
clearly understand how to have a set of boxes that appear to be one domain
name that are always available.

I don't agree we need anything like a BGP for SIP any time I can foresee.
The underlying network handles all the issues I am aware of.  Given the name
of a domain (or subdomain), normal SIP routing is quite sufficient I think.
We attempted this for a really simple subset of the problem (gateway
selection, see TRIP), and we found it was not needed (or at least the
complexity it introduced was not worth the value it provided).

Brian

> From: Patrick Melampy [mailto:[email-masked]]
> Sent: Friday, August 04, 2006 9:59 AM
> To: 'Brian Rosen'; 'Michael Hammer (mhammer)'; 'Hadriel Kaplan'
> Cc: [email-masked]

---

From: "Geoff Devine" <[email-masked]>
Date: Fri, 4 Aug 2006 11:00:35 -0400

I'm with Patrick on this one.  The requirements for a carrier-class
telephone network are quite different from the requirements for a web
server.  A web server doesn't have the moral and ethical obligation to
ensure that the network is stable to complete 911 calls.  If the network
floods a soft switch or media gateway controller with peering traffic
with no notion of congestion control, flow control, or fault management,
you could kill somebody.  In the real world, resources are finite, not
infinite and the network architecture has to take that into account.

Geoff

-----Original Message-----
From: Brian Rosen [mailto:[email-masked]] 
Sent: Friday, August 04, 2006 10:20 AM
To: 'Patrick Melampy'; 'Michael Hammer (mhammer)'; 'Hadriel Kaplan'
Cc: [email-masked]
Subject: RE: [Speermint] Secure RTP

We have lots of experience building "farms" of servers that handle HTTP
load, and I don't see any reason we shouldn't use all of those
techniques to
deal with SIP load.  I certainly don't see reasons to make the
originator
aware of congestion issues at the terminating domain, beyond the
contractual
limits that may be in place.

I don't see any reason why peers should be aware of element failures.
We
clearly understand how to have a set of boxes that appear to be one
domain
name that are always available.

I don't agree we need anything like a BGP for SIP any time I can
foresee.
The underlying network handles all the issues I am aware of.  Given the
name
of a domain (or subdomain), normal SIP routing is quite sufficient I
think.
We attempted this for a really simple subset of the problem (gateway
selection, see TRIP), and we found it was not needed (or at least the
complexity it introduced was not worth the value it provided).

Brian

> invented for routing IP packets. The same is true for SIP based
sessions.
> If
> definition of limiting, but not the way to determine what the limit
is.
> In
> all of the potential policy mechanisms, or what their values are
limited
> to.

---

From: "Patrick Melampy" <[email-masked]>
Date: Fri, 4 Aug 2006 11:03:18 -0400

>From the charter...

>Note that the term "peering" is used here to refer to
>the interconnection between application layer entities such as
>SIP servers, as opposed to interconnection at the IP network
>layer. 

So "peering" is about interconnection between SIP servers. It seems to me
the types of issues we are discussing...
1.) Proxy Availability
2.) Path Discovery (which adjacent proxy can reach downstream domains)
3.) Congestion Control (which addresses are congested)
Really are in scope.

I am not suggesting TRIP at all. We do however, need to establish adjacency
(peer) at the SIP Proxy Layer (as our charter says). This will include a
trusted connection to a next-hop network. That next-hop network (and its TLS
connections) will have real or business based limitations on the signaling
rates they can support. Its far more likely that the limitations will be
business defined -- possibly on a dynamic basis.

They will also support reaching only some domains, not all. Thus rather than
hunt and peck, we need to determine a way to learn what domains are
reachable. 

Finally, the most pressing issue facing SIP in my opinion is the ability to
manage congestion.

-----Original Message-----
From: Brian Rosen [mailto:[email-masked]] 
Sent: Friday, August 04, 2006 10:20 AM
To: 'Patrick Melampy'; 'Michael Hammer (mhammer)'; 'Hadriel Kaplan'
Cc: [email-masked]
Subject: RE: [Speermint] Secure RTP

Brian

---

From: "Brian Rosen" <[email-masked]>
Date: Fri, 4 Aug 2006 11:27:07 -0400

There is no evidence that you can't do this with the mechanisms we have, and
some that we can.  I believe in a contractual, static, limit on traffic
between peers.  I don't think we need anything else.

Brian

> From: Geoff Devine [mailto:[email-masked]]
> Sent: Friday, August 04, 2006 11:01 AM
> To: Brian Rosen; Patrick Melampy; Michael Hammer (mhammer); Hadriel Kaplan
> Cc: [email-masked]

---

From: "Geoff Devine" <[email-masked]>
Date: Fri, 4 Aug 2006 11:35:15 -0400

Telephone networks don't and can't work that way.  They have overload
conditions and you absolutely must have a mechanism for dealing with
them.  In the legacy network, you can take SS#7 CICs out of service.
You can implement call gapping and call metering.  We need equivalent
mechanisms and can likely do far better than best common practices in
the legacy network.

Geoff

-----Original Message-----
From: Brian Rosen [mailto:[email-masked]] 
Sent: Friday, August 04, 2006 11:27 AM
To: Geoff Devine; 'Patrick Melampy'; 'Michael Hammer (mhammer)';
'Hadriel Kaplan'
Cc: [email-masked]

There is no evidence that you can't do this with the mechanisms we have,
and
some that we can.  I believe in a contractual, static, limit on traffic
between peers.  I don't think we need anything else.

Brian

> > determination -- or said another way -- the next hop network to use
to
> > reach
> > In #1 -- proxy availability -- its very similar to how SS7 is used
to
> set
> > the service states on each and every DS0. SS7 is the protocol
family,
> and
> > phone numbers to send down the circuit are provisioned in SS7. In
our
> case
> > related to #2, and the congestion detection and prevention
mechanisms
> must
> > So I think we do have some protocol work here. I also think we need
to
> > leave
> > > discover the policies of a potential peer and whether those
policies
> > > Is is about whether the policy can be stated so one knows that X,
Y,
> ...
> > > > > Sure, but does the peering touch the media?  I claim it
doesn't,
> at

---

From: "Brian Rosen" <[email-masked]>
Date: Fri, 4 Aug 2006 12:01:01 -0400

This isn't a telephone network.

We typically DON'T have overload conditions on well engineered networks.  We
presently have some mighty fine self limiting issues with media, but if we
had proper QoS on the media, that would be, I think, very sufficient
congestion control.  I've never seen a well engineered SIP based network
where the signaling issues were a big problem.  It's almost all in the
media.

I know all about "Americal Idol" night.  The numbers just aren't scary any
more.  

Do the math.  A million BHCA is 278 calls per second.  How many million do
you want?  Rack up the servers (best make them stateless, but that's not a
problem).

Sure, you need a load balancer.  Sure, you need a failover strategy with a
good database.  

Now, every system has limits.  We have an answer for those: busy.

More importantly, we actually can use some telephone engineering to predict
the traffic at the peering point.  We can engineer systems pretty
straightforwardly to handle that traffic.  We DO need some congestion
control mechanisms, because the peering mechanisms we have do have finite
capacity.  However, I don't see much need for telephone style call gapping
and only trivial metering.

Today, we can build peering systems where the actual peering happens at
multiple places around the globe, where there is no effective limits on
signaling bandwith (or for that matter, media bandwith) to and from the
peering points.  We can have SIP proxies that perform the actual peering
function (take a call, do a dip to determine where it's going, use available
DNS and other mechanisms to spread load) that are similarly spread out and
redundant enough that we get the kind of reliability we expect.  And we can
engineer them to take load up to a static limit reliably.

What can't we do?

Brian

> Sent: Friday, August 04, 2006 11:35 AM

---

From: "Patrick Melampy" <[email-masked]>
Date: Fri, 4 Aug 2006 12:39:09 -0400

Continuing on your train of thought --- 

1.) We need load balancers

I agree. How should you propose we balance the load?
	1.) By TLS SESSION ESTABLISHMENT?
	2.) By Round Robin Call Request
      3.) By source/destination proxy pairs?

If your proposing using a standard ARROWPOINT or F5 load balancer? We have
seen these techniques used successfully, and the good ones (like the F5)
actually understand and maintain proxy state. Lets explore some more on what
we would want in an ideal load balancer....

1.) We would want to balance load based on proxy responsiveness
2.) We might want to balance load based on a fairness mechanisms (why not)
based on incoming request addresses
3.) We might further want to fine tune the balancer to accommodate some
larger customers (not exactly fair).

What configurations would the load balancer need? Would the originators of
the requests need to understand the programmed limits of the load balancer?

NOW--- and MOST IMPORANTLY--- unlike in a HTTP load balancing application,
where there is only one load balancing location (at the server farm) --
think about balancing load at other locations in the middle of the network.
Assume here there are HTTP requests that MUST be proxied or processed by
your network infrastructure. How would one balance the load here? What would
the data requirements be? In this case, the from/to/source/TLS socket
connections are being multi-plexed at the proxy. So where do I put the load
balancer? How do I configure it? What are the data models that could support
such a multi-loadbalancer architecture?

I urge you to continue developing your load balancer concept....

-----Original Message-----
From: Brian Rosen [mailto:[email-masked]] 
Sent: Friday, August 04, 2006 12:01 PM
To: 'Geoff Devine'; 'Patrick Melampy'; 'Michael Hammer (mhammer)'; 'Hadriel
Kaplan'
Cc: [email-masked]

What can't we do?

Brian

---

From: "Brian Rosen" <[email-masked]>
Date: Fri, 4 Aug 2006 13:46:36 -0400

<I changed the Subject, we have severely hijacked the thread on Secure RTP>

I fail to see why any of this is a standardization issue: I don't see why
one end cares what the other end uses to load balance.

I don't see any kind of load balance mechanism that requires that the other
end do something related to it other than normal SIP operations.  I
certainly don't think it would be advisable to introduce such an interface.

I don't think this has much to do with location.  Most commercial load
balancers more or less assume everything is collocated, but they don't have
to be, and there are simple ways to distribute to multiple instances of load
balancing, which might indeed be the source of the call related, but again,
not something that needs standardization.

Let's take an example:

Suppose that a peering system has peering connections at 3 IXPs in San Jose,
NY and Miami.  PeerA happens to have facilities at, or "near" (in an L3
sense) the NY and Miami IXPs and PeerB happens to have facilities at, or
"near" NY and San Jose.  So, the peering exchange might indeed want to try
to send traffic between PeerA and PeerB that originate in their NY
facilities to the other's proxy in New York.  However, if NY went down,
peering at either Miami or San Jose would be fine, since the underlying
network would make that one, or at most 2 router hops away.  If there were
only two major peering facilities for PeerA, you would clearly engineer each
to be able to take the entire load.

If you make it more complicated, where each facility is not able to take the
entire load on a failure, you may need some other load balancing operation
on top of the server farm approach that lets one farm refuse traffic, which
would cause the originator to try another IP address.  You can do that with
DNS, you can do that with the peering database, and there are other
mechanisms, none of which need any new work in SPEERMINT or SIP.  I don't
even think we need to enumerate them; it's all something one end does
itself.

Brian

> Sent: Friday, August 04, 2006 12:39 PM
> To: 'Brian Rosen'; 'Geoff Devine'; 'Michael Hammer (mhammer)'; 'Hadriel
> Kaplan'
> Cc: [email-masked]

---

From: "Reinaldo Penno" <[email-masked]>
Date: Fri, 4 Aug 2006 14:13:58 -0400

Hello Brian,

Are you assuming some kind of public peering or third party run peering
point?

Let me give you a simpler barebones example to hear your thoughts...

PA1           PB1
     \      /
PA2  -- LB -- PB2
     /      \
PA3           PB3

PAx reads Proxy x of peer A. Similar for PBy.

Now PeerB does not really care how the signaling calls get distributed
_to_ peer's A proxy from peer's A end users. It only cares how the calls
get distributed to _its_ proxies from peer's A proxies, right?

That's why I put the load balancer between them from a logical
perspective. 

Would this load balancer be able to probe peer's B proxy dynamic "state"
(alive, dead, too many calls, too much bandwidth, etc)? Is that your
proposal?

Thanks,

Reinaldo

> Sent: Friday, August 04, 2006 10:47 AM
> To: 'Patrick Melampy'; 'Geoff Devine'; 'Michael Hammer (mhammer)';
> 'Hadriel Kaplan'
> Cc: [email-masked]
> Subject: RE: [Speermint] Congestion and Load Balancing was Re: Secure
RTP
> to be, and there are simple ways to distribute to multiple instances
of
> load
> only two major peering facilities for PeerA, you would clearly
engineer
> each
> If you make it more complicated, where each facility is not able to
take
> the
> > If your proposing using a standard ARROWPOINT or F5 load balancer?
We
> have
> > actually understand and maintain proxy state. Lets explore some more
on
> > what
> > 2.) We might want to balance load based on a fairness mechanisms
(why
> not)
> > What configurations would the load balancer need? Would the
originators
> of
> > your network infrastructure. How would one balance the load here?
What
> > would
> > connections are being multi-plexed at the proxy. So where do I put
the
> > load
> > We typically DON'T have overload conditions on well engineered
networks.
> > We
> > presently have some mighty fine self limiting issues with media, but
if
> > I know all about "Americal Idol" night.  The numbers just aren't
scary
> any
> > more.
> >
> > Do the math.  A million BHCA is 278 calls per second.  How many
million
> do
> > you want?  Rack up the servers (best make them stateless, but that's
not
> a
> > problem).
> >
> > Sure, you need a load balancer.  Sure, you need a failover strategy
with
> a
> > DNS and other mechanisms to spread load) that are similarly spread
out
> and
> > redundant enough that we get the kind of reliability we expect.  And
we
> > > To: Brian Rosen; Patrick Melampy; Michael Hammer (mhammer);
Hadriel
> > Kaplan
> > > > To: Brian Rosen; Patrick Melampy; Michael Hammer (mhammer);
Hadriel
> > > Kaplan
> > > > telephone network are quite different from the requirements for
a
> web
> > > > server.  A web server doesn't have the moral and ethical
obligation
> > > > you could kill somebody.  In the real world, resources are
finite,
> not
> > > > I don't think any of this is something we are chartered to do.
I
> > > don't
> > > > We have lots of experience building "farms" of servers that
handle
> > > HTTP
> > > > The underlying network handles all the issues I am aware of.
Given
> > > the
> > > > selection, see TRIP), and we found it was not needed (or at
least
> the
> > > > > determination -- or said another way -- the next hop network
to
> use
> > > > > discovered. The discovery aspects are the dynamic aspects.
This
> > > would
> > > > > ISUP messages are sent to bring circuits in and out of
service.
> The
> > > > actual
> > > > > to have a well managed service, we need an equivalent to
"circuit
> > > > service
> > > > > state", which might be embodied as a call arrival rate,
maximum
> > > > sessions
> > > > > In #2 -- reachable domains -- Unlike the PSTN which uses the
NPA-
> NXX
> > > > > routing
> > > > > models which are hierarchical and well understood, IP domains
are
> > > > > amorphous
> > > > > and have very unpredictable intersection points. This is why
BGP
> was
> > > > > protocol that goes network to network. Thus a protocol is
required
> > > > here.
> > > > > to the individual networks, any and all decisions on how to
run
> > > their
> > > > > I don't see the purpose in standardizing mechanisms for peers
> within
> > > a
> > > > > peering federation to discover policies that apply to each
other.
> > > > That is
> > > > > provisioning.  It's not dynamic (in fact, it's usually
specified
> by
> > > > > So, for example, if one of the things peering means is that
the
> rate
> > > > of
> > > > > calls is limited in some way, then we probably have to
standardize
> > > the
> > > > > that way, the vendor who builds the proxy for Peer A will be
able
> to
> > > > build
> > > > > in it the ability to meet the policy for Peer B.  This is not
a
> > > > protocol
> > > > > Similarly, it's not clear to me that a federation will
necessarily
> > > > define
> > > > > It clearly WILL do that for some variables, and again, we
don't
> need
> > > > > automatic provisioning mechanisms to discover these.  Even
within
> a
> > > > > federation, I think it will be common that bilateral
arrangements
> > > > making
> > > > > > systematically describe the requirements on multiple levels
that
> > > > will
> > > > > > need to be supported to have a successful communication with
> that
> > > > peer.
> > > > > >
> > > > > > It is not about specifying X, Y, Z, or <name your favorite
MUST
> > > > here>
> > > > > >
> > > > > > Is is about whether the policy can be stated so one knows
that
> X,
> > > Y,
> > > > ...
> > > > > > is required to peer.
> > > > > >
> > > > > > I suspect that each federation will select different MUSTs
for
> > > each

---

From: "Brian Rosen" <[email-masked]>
Date: Fri, 4 Aug 2006 14:27:59 -0400

In my opinion, the Load Balancer belongs to Proxy B, and it can do anything
it likes.  PAx sends to LB, and is not aware, and doesn't care, which PBy
gets the call.  SIP handles this well.

Of course LB is a single point of failure.

Brian

> From: Reinaldo Penno [mailto:[email-masked]]
> Sent: Friday, August 04, 2006 2:14 PM
> To: Brian Rosen; Patrick Melampy; Geoff Devine; Michael Hammer (mhammer);
> Hadriel Kaplan
> Cc: [email-masked]
> Subject: RE: [Speermint] Congestion and Load Balancing was Re: Secure RTP
> 
> Hello Brian,
>

---

From: "Patrick Melampy" <[email-masked]>
Date: Sat, 5 Aug 2006 16:42:03 -0400

Assuming that Domain B was determined to be the next domain (through a yet
unknown means), I partially agree. I think in practice, both the A proxy and
B proxy would require load balancers. The load leaving A might be easily
sent to a single very high capacity load balancer that B owns. This load
balancer would likely be stateless, and as such unable to really manage the
relationship parameters (# of calls, amount of bandwidth, call rate). Most
of the scalable load balancers today are at best TCP stateful with some L5
cookie mashing to keep TCP socket requests going to the same place. This of
course will not work for SIP unless we open a new Socket for every call. For
discussion purposes, lets suppose that systems of this type can process a
very large amount of traffic -- lets say in excess of 10,000 calls per
second.

If B's load balancer was transaction stateful, then B could balance the
traffic by transactions. Also note that if B terminated and reoriginated TCP
sockets for security association reasons, then B would be required to be
transaction stateful at a minimum to remember where messages need to be
sent. Problem with B's loadbalancer being transaction stateful, is that it
runs significantly slower. I would bet that it would be at least 1/20 of the
performance of the totally stateless model -- lets say 500 calls per second
(1000 Transactions per second, 3500 Sip Messages per second...)

One problem we have now with B's load balancer, is that B can't really know
or control how many real calls are coming from A. For example, A could be
sending lots of transactions that are failing. Conversely, A could be
sending a very slow rate of transactions that keep sessions up for hours at
a time. Obviously, there is still a lack of controls for enforcing the
relationship between B and A. --- Whats missing?

B may require that the load balancer be session stateful. This could be any
range of possible solutions, including a record route proxy that is
transaction stateful all the way through a B2BUA like the edge of an IMS
network. Now B could keep track of total sessions established coming from A.

Probably, A has the same issue that B has ... How many calls coming from a
variety of proxies is actually traversing into B's load balancer. I would
suggest that A might need a "concentrator" (the opposite of a load
balancer). The concentrator might manage the relationship with B, and
provide statefull management of the traffic destined for B.

Why is all this required? Well frankly, much of the traffic will have
"media" based bandwidth limitations. One could consider a central PDF
function to manage the relationship. Either way, the load balancer has the
same issues.

What if B can't process the communication request? Where does A send it? Is
there an alternative? How can A determine if there is another network (say
C) that can process the communication? How would A share information with
all of its source proxies...that B is constrained, full, or unavailable?

I'm guessing we have a bit of modeling to do. If SIP were more like HTTP
where the TCP session and the HTTP session were directly connected -- with
COOKIES binding the physical sessions into logical application sessions,
then we could more readily use your suggestions. Last I looked, SIP
transactions and dialogues are pretty nasty to recognize, and add
retransmissions, cancels, and other nasty things that make load balancing
difficult if not impossible with out being a full SIP participant.

If a load balancer is a full SIP participant, and the load balancer is
balancing traffic based on established sessions -- you pretty much have a
device that wont scale big enough to have one-size fits all....now you have
the problem that I suggested. How does A find B's "load balancers" -- which
I stated as "how does A find B's proxies, and their attributes.

-----Original Message-----
From: Brian Rosen [mailto:[email-masked]] 
Sent: Friday, August 04, 2006 2:28 PM
To: 'Reinaldo Penno'; 'Patrick Melampy'; 'Geoff Devine'; 'Michael Hammer
(mhammer)'; 'Hadriel Kaplan'
Cc: [email-masked]
Subject: RE: [Speermint] Congestion and Load Balancing was Re: Secure RTP

Brian

---

From: "Pfautz, Penn L, GBLAM" <[email-masked]>
Date: Mon, 7 Aug 2006 11:04:04 -0400

Just one thing to be careful about in the American Idol situation - the
call attempts don't get spread nicely across the busy hour. Media
stimulated calling means getting all the load at once. The 1M calls
looks more like 16K/s if you assume a minute is the time interval
 
-----Original Message-----
From: Brian Rosen [mailto:[email-masked]] 
Sent: Friday, August 04, 2006 12:01 PM
To: 'Geoff Devine'; 'Patrick Melampy'; 'Michael Hammer (mhammer)';
'Hadriel Kaplan'
Cc: [email-masked]

We typically DON'T have overload conditions on well engineered networks.
We
presently have some mighty fine self limiting issues with media, but if
we
had proper QoS on the media, that would be, I think, very sufficient
congestion control.  I've never seen a well engineered SIP based network
where the signaling issues were a big problem.  It's almost all in the
media.

I know all about "Americal Idol" night.  The numbers just aren't scary
any
more.  

Do the math.  A million BHCA is 278 calls per second.  How many million
do
you want?  Rack up the servers (best make them stateless, but that's not
a
problem).

Sure, you need a load balancer.  Sure, you need a failover strategy with
a
good database.  

More importantly, we actually can use some telephone engineering to
predict
the traffic at the peering point.  We can engineer systems pretty
straightforwardly to handle that traffic.  We DO need some congestion
control mechanisms, because the peering mechanisms we have do have
finite
capacity.  However, I don't see much need for telephone style call
gapping
and only trivial metering.

Today, we can build peering systems where the actual peering happens at
multiple places around the globe, where there is no effective limits on
signaling bandwith (or for that matter, media bandwith) to and from the
peering points.  We can have SIP proxies that perform the actual peering
function (take a call, do a dip to determine where it's going, use
available
DNS and other mechanisms to spread load) that are similarly spread out
and
redundant enough that we get the kind of reliability we expect.  And we
can
engineer them to take load up to a static limit reliably.

What can't we do?

Brian

> > > ISUP messages are sent to bring circuits in and out of service.
The
> > > In #2 -- reachable domains -- Unlike the PSTN which uses the
NPA-NXX
within
> > > So, for example, if one of the things peering means is that the
rate
> > > that way, the vendor who builds the proxy for Peer A will be able
to
that

---

From: "Brian Rosen" <[email-masked]>
Date: Tue, 8 Aug 2006 12:59:49 -0400

I think the A proxy has a "load balancer", but it's a byproduct of how it
assigns registrants to outgoing proxy servers. 

There are a couple of ways to load balance SIP.  One of the nicest is a
redirect proxy.  Another is a transaction aware, but not transaction
stateful LB (might have to be session aware, depending on what the leaf
proxy did).  SIP effectively does have "cookies"; they are the tags.

The LB doesn't have to keep state, because the transaction ID is visible in
every message.  Of course if the leaf proxies are stateless, so is the LB.

Now, I agree that you can't have ONE load balancer.  You have to replicate
it, but I suspect that the mechanism that distributes calls to the
replicated LB is pretty simple.  You do have to model the failure cases and
make sure the entire load is shouldered by, and distributed to, the
remaining replicas.

Brian

> Sent: Saturday, August 05, 2006 4:42 PM
> To: 'Brian Rosen'
> Cc: [email-masked]
> Subject: RE: [Speermint] Congestion and Load Balancing
> 
> > > > 'Hadriel

---

From: Klaus Darilion <[email-masked]>
Date: Wed, 09 Aug 2006 13:59:14 +0200

Some more practical LB issues.

If the LB is used for load balancing only, there is no need to be 
transaction stateful - it depends on the distribution logic of the LB. 
If there is a random component within the LB-logic, you need a 
transaction statefull LB to ensure proper handling of retransmissions. 
But if the LB-logic is based on some part of the message (e.g. callid, 
R-URI), then the LB will route retransmissions always to the same proxy.

In-dialog requests will be routed by SIP's loose routing logic, thus the 
LB is not needed for in-dialog requests.

Of course if you imply that a LB also has to do topology hiding and 
counting the number of active calls than you need a session-stateful 
element.

regards
klaus

---

From: "Patrick Melampy" <[email-masked]>
Date: Wed, 9 Aug 2006 11:00:51 -0400

Klaus --- What the carrier needs is four basic requirements (the receiving
or B carrier):

1.) To be able to receive calls
2.) To be able to count the simultaneous calls
3.) To be able to count the kilobytes of bandwidth the media is consuming
4.) To be able to settle accounts in some way

Optional requirements include:
5.) To be able to control the rate each customer sends calls
6.) To be able to manage congestion on certain domains

A stateless load balancer can't provide these.

I believe that semi-stateless load-balancers are required. All of the
technology you and Brian speak to works. However, none of that technology
helps solve the above problems. The above problems will ultimately call for
distributed session state with distributed admission control. I also believe
that the load balancers will be semi-stateful (slightly slower than a
redirect, but more reliable from B's point of view) and will not scale to
the point where only one is required. I would suggest that locating these
semi-stateful proxies and their attributes (distributed admission control
parameters) will be important topics for this group.

-----Original Message-----
From: Klaus Darilion [mailto:[email-masked]] 
Sent: Wednesday, August 09, 2006 7:59 AM
To: Brian Rosen
Cc: 'Patrick Melampy'; [email-masked]
Subject: Re: [Speermint] Congestion and Load Balancing

regards
klaus

---

From: "Brian Rosen" <[email-masked]>
Date: Wed, 9 Aug 2006 11:13:12 -0400

I think anything the B carrier needs from your first 5 items, it can get
from its equipment, and doesn't need any work here.  I think you imply that
the originating carrier (A) actually can limit simultaneous calls, the rate
of calls, and the bandwidth of those calls to a contractual limit.  There
may be some SPEERMINT work to make at least the definitions consistent if
not some mechanisms.

Where we part company is 6.  I am happy to have B do anything it wants to
manage congestion on certain domains, but I don't think that is any work for
SPEERMINT, because I don't think A does anything to help that.  I don't see
a need for mechanisms to distribute load from A to B in any but trivial ways
(for each URI, you can limit calls, rate of calls and bandwidth).

Brian

> Sent: Wednesday, August 09, 2006 11:01 AM
> To: 'Klaus Darilion'; 'Brian Rosen'
> Cc: [email-masked]
> >> unknown means), I partially agree. I think in practice, both the A
> proxy
> >> and
> >> cookie mashing to keep TCP socket requests going to the same place.
> This
> >> of
> >> course will not work for SIP unless we open a new Socket for every
> call.
> >> For
> >> traffic by transactions. Also note that if B terminated and
> reoriginated
> >> TCP
> >> runs significantly slower. I would bet that it would be at least 1/20
> of
> >> the
> >> sending a very slow rate of transactions that keep sessions up for
> hours
> >> at
> >> network. Now B could keep track of total sessions established coming
> from
> >> A.
> >>
> >> Probably, A has the same issue that B has ... How many calls coming
> from
> a
> >> What if B can't process the communication request? Where does A send
> it?
> >> Is
> >>>> <I changed the Subject, we have severely hijacked the thread on
> Secure
> >>>> RTP>
> >>>>
> >>>> balancers more or less assume everything is collocated, but they
> don't
> >>>> have
> >>>> Suppose that a peering system has peering connections at 3 IXPs in
> San
> >>>> Jose,
> >>>> "near" NY and San Jose.  So, the peering exchange might indeed want
> to
> >>> try
> >>>> would cause the originator to try another IP address.  You can do
> that
> >>>> with

---

From: Klaus Darilion <[email-masked]>
Date: Wed, 09 Aug 2006 17:47:35 +0200

> 2.) To be able to count the simultaneous calls

= dialog-statefull proxy

> 3.) To be able to count the kilobytes of bandwidth the media is consuming

= calls x bandwidth per call.

> 6.) To be able to manage congestion on certain domains

Manage congestions have 2 results: either tell A that there is no way to
route this call in network B, or reroute the call to an idle node. 
Rerouting can happen in network B or in network A (SIP redirect 3xx)
> A stateless load balancer can't provide these.

IMO a load balancer is a load balancer, and beeing statefull at SIP 
layser is different to knowing the state (load) on the SIP proxies and 
media gateways inside your network. A LB can be SIP stateless, but still 
knows the status of the SIP nodes in the network and may distribute the 
calls accordingly to the SIP nodes (ok, here a transaction stateful LB 
would be good, but a session statefull LB is not required)

> parameters) will be important topics for this group.

IMO this is inside of network B, thus out of scope for SPEERMINT.

regards
klaus

---

From: "Patrick Melampy" <[email-masked]>
Date: Wed, 9 Aug 2006 13:29:39 -0400

Network A needs to know things about Network B (dynamic things). This is
what spearmint is about. A needs to know where B's proxies are, and how to
use them. A will have many possible ways of reaching downstream domains. A
needs to be able to efficiently route traffic. This requires information
about B's capabilities (speeds, rates, volumes).

Its all very simple. Either A has to provision everything based on B's
information, or we need to develop a protocol for exchanging this
information.

The advantage of a protocol, is that the information can be dynamic, and the
same protocol can be used for congestion control

You pooh-pooh congestion control. Service Provider Peering will never work
if it doesn't have congestion control. You can take that to the bank.

--- Patrick
-----Original Message-----
From: Klaus Darilion [mailto:[email-masked]] 
Sent: Wednesday, August 09, 2006 11:48 AM
To: Patrick Melampy
Cc: 'Brian Rosen'; [email-masked]
Subject: Re: [Speermint] Congestion and Load Balancing

= dialog-statefull proxy

regards
klaus

from
RTP

---

From: "Uzelac, Adam" <[email-masked]>
Date: Wed, 9 Aug 2006 15:49:13 -0400

One issue here is this -  how dependant is Network B on Network A doing
the right thing, or anything, with the information that Network B
provides?  I can tell all my peers that I will only accept 100 sessions
at a time, or I only support CODEC X - but that doesn't ensure more than
100 sessions will be attempted, or other CODECs are attempted.  For a
fact, I am pumping tons of 503s today because folks are exceeding what I
told them they should send.  And the CODECs that are being offered lists
is comedy to observe.  An exchange of information between Network A and
Network B can only potentially mitigate the risk of violating what
Network B wants.  

-AU

PS - The "You can take to the bank" comment makes me think of bad Steven
Seagal movies from the 80s.

-----Original Message-----
From: Patrick Melampy [mailto:[email-masked]] 
Sent: Wednesday, August 09, 2006 1:30 PM
To: 'Klaus Darilion'
Cc: [email-masked]
Subject: RE: [Speermint] Congestion and Load Balancing

Network A needs to know things about Network B (dynamic things). This is
what spearmint is about. A needs to know where B's proxies are, and how
to use them. A will have many possible ways of reaching downstream
domains. A needs to be able to efficiently route traffic. This requires
information about B's capabilities (speeds, rates, volumes).

The advantage of a protocol, is that the information can be dynamic, and
the same protocol can be used for congestion control

You pooh-pooh congestion control. Service Provider Peering will never
work if it doesn't have congestion control. You can take that to the
bank.

--- Patrick
-----Original Message-----
From: Klaus Darilion [mailto:[email-masked]]
Sent: Wednesday, August 09, 2006 11:48 AM
To: Patrick Melampy
Cc: 'Brian Rosen'; [email-masked]
Subject: Re: [Speermint] Congestion and Load Balancing

Patrick Melampy wrote:
> Klaus --- What the carrier needs is four basic requirements (the 
> receiving or B carrier):
> 

= dialog-statefull proxy

> technology you and Brian speak to works. However, none of that 
> technology helps solve the above problems. The above problems will 
> ultimately call
for
> redirect, but more reliable from B's point of view) and will not scale

> to the point where only one is required. I would suggest that locating

> these semi-stateful proxies and their attributes (distributed 
> admission control

regards
klaus

> In-dialog requests will be routed by SIP's loose routing logic, thus 
> the LB is not needed for in-dialog requests.
> 
>> I think the A proxy has a "load balancer", but it's a byproduct of 
>> how it assigns registrants to outgoing proxy servers.
>>
>> There are a couple of ways to load balance SIP.  One of the nicest is

>> a redirect proxy.  Another is a transaction aware, but not 
>> transaction stateful LB (might have to be session aware, depending on

>> what the leaf proxy did).  SIP effectively does have "cookies"; they
are the tags.
>>
>> The LB doesn't have to keep state, because the transaction ID is 
>> visible
> in
>> every message.  Of course if the leaf proxies are stateless, so is 
>> the
LB.
>> replicated LB is pretty simple.  You do have to model the failure 
>> cases
> and
>>> Assuming that Domain B was determined to be the next domain (through

> yet
>>> proxy and B proxy would require load balancers. The load leaving A 
>>> might be easily sent to a single very high capacity load balancer 
>>> that B owns. This load balancer would likely be stateless, and as 
>>> such unable to really manage the relationship parameters (# of 
>>> calls, amount of bandwidth, call rate).
> Most
>>> of the scalable load balancers today are at best TCP stateful with 
>>> some
> L5
>>> This of course will not work for SIP unless we open a new Socket for

>>> every call.
>>> For
>>> discussion purposes, lets suppose that systems of this type can 
>>> process
a
>>> very large amount of traffic -- lets say in excess of 10,000 calls 
>>> per second.
>>>
>>> If B's load balancer was transaction stateful, then B could balance 
>>> the traffic by transactions. Also note that if B terminated and 
>>> reoriginated TCP sockets for security association reasons, then B 
>>> would be required to be transaction stateful at a minimum to 
>>> remember where messages need to be sent. Problem with B's 
>>> loadbalancer being transaction stateful, is that
> it
>>> runs significantly slower. I would bet that it would be at least 
>>> 1/20 of the performance of the totally stateless model -- lets say 
>>> 500 calls per second (1000 Transactions per second, 3500 Sip 
>>> Messages per second...)
>>>
>>> One problem we have now with B's load balancer, is that B can't 
>>> really know or control how many real calls are coming from A. For 
>>> example, A could
be
>>> sending lots of transactions that are failing. Conversely, A could 
>>> be sending a very slow rate of transactions that keep sessions up 
>>> for hours at a time. Obviously, there is still a lack of controls 
>>> for enforcing the relationship between B and A. --- Whats missing?
>>>
>>> B may require that the load balancer be session stateful. This could

>>> be any range of possible solutions, including a record route proxy 
>>> that is transaction stateful all the way through a B2BUA like the 
>>> edge of an IMS network. Now B could keep track of total sessions 
>>> established coming
from
>>> balancer). The concentrator might manage the relationship with B, 
>>> and provide statefull management of the traffic destined for B.
>>>
>>> Why is all this required? Well frankly, much of the traffic will 
>>> have "media" based bandwidth limitations. One could consider a 
>>> central PDF function to manage the relationship. Either way, the 
>>> load balancer has
> the
>>> same issues.
>>>
it?
>>> Is
>>> there an alternative? How can A determine if there is another 
>>> network
> (say
>>> I'm guessing we have a bit of modeling to do. If SIP were more like 
>>> HTTP where the TCP session and the HTTP session were directly 
>>> connected --
> with
>>> COOKIES binding the physical sessions into logical application 
>>> sessions, then we could more readily use your suggestions. Last I 
>>> looked, SIP transactions and dialogues are pretty nasty to 
>>> recognize, and add retransmissions, cancels, and other nasty things 
>>> that make load
balancing
>>> If a load balancer is a full SIP participant, and the load balancer 
>>> is balancing traffic based on established sessions -- you pretty 
>>> much have
a
>>> device that wont scale big enough to have one-size fits all....now 
>>> you have the problem that I suggested. How does A find B's "load 
>>> balancers" -- which I stated as "how does A find B's proxies, and 
>>> their attributes.
>>>
>>>
>>>
>>> To: 'Reinaldo Penno'; 'Patrick Melampy'; 'Geoff Devine'; 'Michael 
>>> Hammer (mhammer)'; 'Hadriel Kaplan'
>>> Cc: [email-masked]
RTP
>>>
>>> In my opinion, the Load Balancer belongs to Proxy B, and it can do 
>>> anything it likes.  PAx sends to LB, and is not aware, and doesn't 
>>> care, which
PBy
>>>> Are you assuming some kind of public peering or third party run 
>>>> peering point?
>>>>
>>>> Now PeerB does not really care how the signaling calls get 
>>>> distributed _to_ peer's A proxy from peer's A end users. It only 
>>>> cares how the
calls
>>>> (alive, dead, too many calls, too much bandwidth, etc)? Is that 
>>>> your proposal?
>>>>
>>>> Thanks,
>>>>
>>>> Reinaldo
>>>>

>>>>> I fail to see why any of this is a standardization issue: I don't 
>>>>> see
>>>> why
>>>>> I don't see any kind of load balance mechanism that requires that 
>>>>> the other end do something related to it other than normal SIP 
>>>>> operations.  I certainly don't think it would be advisable to 
>>>>> introduce such an interface.
>>>>>
>>>>> I don't think this has much to do with location.  Most commercial 
>>>>> load balancers more or less assume everything is collocated, but 
>>>>> they don't have to be, and there are simple ways to distribute to 
>>>>> multiple instances
>>>> of
>>>>> load
>>>>> balancing, which might indeed be the source of the call related, 
>>>>> but again, not something that needs standardization.
>>>>>
>>>>> Let's take an example:
>>>>>

>>>>> San Jose, NY and Miami.  PeerA happens to have facilities at, or 
>>>>> "near" (in an
>>>> L3
>>>>> sense) the NY and Miami IXPs and PeerB happens to have facilities 
>>>>> at,
>>>> or
>>>>> "near" NY and San Jose.  So, the peering exchange might indeed 
>>>>> want to
>>>> try

>>>>> network would make that one, or at most 2 router hops away.  If 
>>>>> there
>>>> were
>>>>> on top of the server farm approach that lets one farm refuse 
>>>>> traffic, which would cause the originator to try another IP 
>>>>> address.  You can do that with DNS, you can do that with the 
>>>>> peering database, and there are other mechanisms, none of which 
>>>>> need any new work in SPEERMINT or SIP.  I
>>>> don't
>>>>> even think we need to enumerate them; it's all something one end 
>>>>> does itself.
>>>>>
>>>>> Brian
>>>>>
>>>>>
>>>>>
>>>>>> seen these techniques used successfully, and the good ones (like 
>>>>>> the
>>>> F5)
>>>>>> 3.) We might further want to fine tune the balancer to 
>>>>>> accommodate
>>>> some
>>>>>> the requests need to understand the programmed limits of the load

>>>>>> balancer?
>>>>>> where there is only one load balancing location (at the server 
>>>>>> farm)
>>>> --
>>>>>> balancer? How do I configure it? What are the data models that 
>>>>>> could support such a multi-loadbalancer architecture?
>>>>>>
>>>>>> To: 'Geoff Devine'; 'Patrick Melampy'; 'Michael Hammer 
>>>>>> had proper QoS on the media, that would be, I think, very 
>>>>>> sufficient congestion control.  I've never seen a well engineered

>>>>>> SIP based
>>>> network
>>>>>> where the signaling issues were a big problem.  It's almost all 
>>>>>> in
>>>> the
>>>>>> media.
>>>>>>
>>>>>> More importantly, we actually can use some telephone engineering 
>>>>>> to predict the traffic at the peering point.  We can engineer 
>>>>>> systems pretty straightforwardly to handle that traffic.  We DO 
>>>>>> need some
>>>> congestion
>>>>>> Today, we can build peering systems where the actual peering 
>>>>>> happens
>>>> at
>>>>>> multiple places around the globe, where there is no effective 
>>>>>> limits
>>>> on
>>>>>> signaling bandwith (or for that matter, media bandwith) to and 
>>>>>> from
>>>> the
>>>>>> function (take a call, do a dip to determine where it's going, 
>>>>>> use available DNS and other mechanisms to spread load) that are 
>>>>>> similarly spread
>>>> out
>>>>> and
>>>>>>> mechanisms and can likely do far better than best common 
>>>>>>> practices
>>>> in
>>>>>>> the legacy network.
>>>>>>>
>>>>>>> Geoff
>>>>>>>

>>>>>>> There is no evidence that you can't do this with the mechanisms 
>>>>>>> we
>>>>> have,
>>>>>>> and
>>>>>>>> ensure that the network is stable to complete 911 calls.  If 
>>>>>>>> the
>>>>>>> network
>>>>>>>> techniques to deal with SIP load.  I certainly don't see 
>>>>>>>> reasons to make the originator aware of congestion issues at 
>>>>>>>> the terminating domain, beyond the contractual limits that may 
>>>>>>>> be in place.
>>>>>>>>

---

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

I don't think there is anything particularly dynamic about what A knows
about B, because it will be subject to contract.  I do not think we know
enough to design congestion control mechanisms that work across the peering
boundary.  I am not aware of experimental work that would point towards what
kinds of mechanisms are appropriate, and in the absence of some working
examples, I fail to see why we should even consider it.  We can limit calls
per unit of time, and bandwidth, on a list of proxies and I think that's it.

The design of congestion control protocols is fraught with failures on
things that ought to have worked.  The congestion control mechanisms we see
in the PSTN are wholly unsuitable for the Internet.  What we will need for
the Internet has yet to be investigated.  I encourage such investigation.
I'd be very interested in reports describing new mechanisms and how well
they work, both on simulated and real traffic.

But unless you can point to something that appears to work, it's out of
bounds for this group, in my opinion.

Brian

> receiving
> technology
> >>> balancer would likely be stateless, and as such unable to really
> manage
> >>> the
> >>> sent. Problem with B's loadbalancer being transaction stateful, is
> that
> > it
> sessions,
> >>> balancing traffic based on established sessions -- you pretty much
> have
> a
> >>> anything
> peering
> distributed
> >>>>> other
> traffic,
> >>>>> which
> does
> could
> >>>>>> support
> sufficient

---

From: "Klaus Darilion" <[email-masked]>
Date: Thu, 10 Aug 2006 02:11:23 +0200 (CEST)

> about B's capabilities (speeds, rates, volumes).

Aren't that policy issues, which are part of an interconnect agreement?

I do not think that such dynamics update will work. E.g. a simple
scenario. Provider T peers with A and B. T can handle 100 concurrent
calls. Thus it announces to both ( A and B) that 100 calls are available.
Once B makes a call, it announces to both that now only 99 calls are
available and so on. You will generate much more traffic with dynamic
updates than with SIP signalling.

We should keep things simple, and we should not build PSTN over IP, and we
should not over engineer things.

> same protocol can be used for congestion control

There are other scenarios besides mutual peering. There may be
federations, and maybe some providers will have open URIs. In such
scenarios, where you do not know each possible peer in advance, in advance
provisioning is not possible.

> if it doesn't have congestion control. You can take that to the bank.

Maybe we should first specify what congestion control exactly requires
(and btw: how is congestion control done in the PSTN?). I'm sure lots of
this requirements canbe fulfilled with pure SIP, which will ease things.

regards
klaus

---

From: "Patrick Melampy" <[email-masked]>
Date: Wed, 9 Aug 2006 22:28:32 -0400

Maybe its simple when its two networks to understand why dynamic protocols
aren't required. Lets consider the following -- and try to imagine just how
complicated a real life situation would be.

3 carriers A, B, and C each having hosted enterprise SIP domains labeled e1,
e2 ... en.

Consider this topology...

A<--------->B<------------->C
|           |               |
+--e1       +--e3           +--e3
|           |               |
+--e2       +--e4           +--e6
|           |               |
+--en       +--en           +--en

In the above network, there are en sip domains hosted by carriers A, B, and
C. Question for you......

1.) How will C discover that B offers trusted SIPS proxy routing services to
domains e1, and e2 hosted by carrier A?

2.) How will A notify B and C that its hosting a new enterprise domain en?

3.) What if e6 moves from carrier C to carrier A?

4.) e3 is available through both carrier B and carrier C. Which is better?

I know that if there were no transit or peering carriers, these problems
would be solved by ENUM and DNS and standard internet routing. But this
working group is tasked with studying the vary problems that occur when we
add session peering to establish trusted interconnects to build large
networks that are manageable and predictable.

-----Original Message-----
From: Brian Rosen [mailto:[email-masked]] 
Sent: Wednesday, August 09, 2006 4:50 PM
To: 'Patrick Melampy'; 'Klaus Darilion'
Cc: [email-masked]
Subject: RE: [Speermint] Congestion and Load Balancing

Brian

---

From: "Klaus Darilion" <[email-masked]>
Date: Thu, 10 Aug 2006 08:03:14 +0200 (CEST)

Hi!

These topics are not related to congestion control, but yes, these
problems are currently addressed as well in the SPEERMINT group. You can
solve this by using SRV/NAPTR records to announce the ingress point and
transit peerings.

regards
klaus

On Thu, August 10, 2006 4:28, Patrick Melampy said:
>> work
>> > helps solve the above problems. The above problems will ultimately
>> call
>> for
>> how
>> >>> relationship parameters (# of calls, amount of bandwidth, call
>> rate).
>> > Most
>> per
>> >>> sockets for security association reasons, then B would be required
>> to
>> be
>> 1/20
>> really
>> >>> know
>> >>> or control how many real calls are coming from A. For example, A
>> could
>> be
>> >>> function to manage the relationship. Either way, the load balancer
>> has
>> > the
>> >>> same issues.
>> >>>
>> >>> where the TCP session and the HTTP session were directly connected
>> --
>> > with
>> is
>> you
>> >>> the problem that I suggested. How does A find B's "load balancers"
>> --
>> >>> which
>> >>> it likes.  PAx sends to LB, and is not aware, and doesn't care,
>> which
>> PBy
>> your
>> but
>> >>>>> again,
>> >>>>> NY and Miami.  PeerA happens to have facilities at, or "near" (in
>> an
>> >>>> L3
>> want
>> >>>>> mechanisms, none of which need any new work in SPEERMINT or SIP.
>> I
>> >>>> don't
>> >>>>>> think about balancing load at other locations in the middle of
>> the
>> >>>>>> network.
>> (mhammer)';

---

From: "Brian Rosen" <[email-masked]>
Date: Thu, 10 Aug 2006 09:14:57 -0400

To answer the question, I have to have you answer a question.

Is the "address" used to establish a session between any subscribers of A, B
and C restricted, at least for now, to a telephone number?

If the answer to that question is "yes", then my answer to your question is
ENUM and DNS and standard internet routing, plus some static routing table
for a peering federation that supports transit networks that maps carriers
not in the federation to transit networks that are.

You dip ENUM to determine the terminating carrier.  If that carrier is in
one of your federations, send the call direct.   If it's not, look it up in
the transit network table(s) and select from among the choice you find, or
route via the PSTN.  It's conceivable that you can combine these operations
if you don't treat ENUM as public, and strictly a 'real' DNS query.

I have no interest in making selection between multiple potential transit
networks anything but an internal matter for the originating carrier.
Specifically, I really think we are NOT going to try to reflect congestion
into such a selection.  I note that except for some strictly internal
operations, this does NOT happen on the PSTN.  Transit network selection is
almost always based on cost of termination.

If the answer is "no", then I suspect the answer is DNS and standard
Internet routing and there is no carrier.  I suspect the more complex (and
thus expensive) we make peering, the sooner the answer will be "no".

Brian

> Sent: Wednesday, August 09, 2006 10:29 PM
> To: 'Brian Rosen'; 'Klaus Darilion'
> Cc: [email-masked]
> > >>> where the TCP session and the HTTP session were directly connected -
> -
> > > with
> > >>> the problem that I suggested. How does A find B's "load balancers" -
> -
> > >>> which

---

From: Otmar Lendl <[email-masked]>
Date: Thu, 10 Aug 2006 21:56:48 +0200

> complicated a real life situation would be.

I like your scenario: these are exactly the question we have to answer
in Speermint. 

> networks that are manageable and predictable.

I don't think that ENUM will help us here. After all, it should not
matter whether numbers or URIs were dialed in the first place.  So we
only have the SIP URIs to work with in the Speermint space.

Our drafts add extensions to the SIP routing algorithm which provide 
solutions for the cases you describe.

The -02 versions should appear on the ietf pages soon, for a preview have
a look at http://www.enum.at/ietf/draft-lendl-speermint-federations-02.txt 
and http://www.enum.at/ietf/draft-lendl-domain-policy-ddds-02.txt.

We've incorporated results from the discussions in Montreal: 
The non-terminal NAPTRs in the Domain Policy DDDS are now defined to do
signaling referral as well as policy referral.

Please have a look.

/ol
-- 
< Otmar Lendl ([email-masked]) | nic.at Systems Engineer >

---

From: "Patrick Melampy" <[email-masked]>
Date: Thu, 10 Aug 2006 23:07:25 -0400

Klaus...

Can you explain how ENUM and NAPTR records can answer questions 1 through 4?
Please provide some details?

-----Original Message-----
From: Klaus Darilion [mailto:[email-masked]] 
Sent: Thursday, August 10, 2006 2:03 AM
To: Patrick Melampy
Cc: 'Brian Rosen'; [email-masked]
Subject: RE: [Speermint] Congestion and Load Balancing

Hi!

regards
klaus

---

From: "Stastny Richard" <[email-masked]>
Date: Fri, 11 Aug 2006 10:21:46 +0200

> Can you explain how ENUM and NAPTR records can answer questions 1
through
> 4?

First half of the answer:
ENUM does NOT solve any problems related to the routing of
SIP URIs

Richard Stastny

> Sent: Friday, August 11, 2006 5:07 AM
> To: 'Klaus Darilion'
> Cc: [email-masked]
> Can you explain how ENUM and NAPTR records can answer questions 1
through
> 4?
> > aren't required. Lets consider the following -- and try to imagine
just
> > 3 carriers A, B, and C each having hosted enterprise SIP domains
labeled
> > e1,
> > In the above network, there are en sip domains hosted by carriers A,
B,
> > 1.) How will C discover that B offers trusted SIPS proxy routing
> services
> > to
> > 2.) How will A notify B and C that its hosting a new enterprise
domain
> en?
> > working group is tasked with studying the vary problems that occur
when
> > boundary.  I am not aware of experimental work that would point
towards
> > examples, I fail to see why we should even consider it.  We can
limit
> > calls
> > per unit of time, and bandwidth, on a list of proxies and I think
that's
> > it.
> > things that ought to have worked.  The congestion control mechanisms
we
> > see
> > in the PSTN are wholly unsuitable for the Internet.  What we will
need
> >> Network A needs to know things about Network B (dynamic things).
This
> >> use them. A will have many possible ways of reaching downstream
> domains.
> >> A
> >> The advantage of a protocol, is that the information can be
dynamic,
> >> Manage congestions have 2 results: either tell A that there is no
way
> >> > distributed session state with distributed admission control. I
also
> >> believe
> >> > the point where only one is required. I would suggest that
locating
> >> these
> >> > transaction stateful - it depends on the distribution logic of
the
> >> >> There are a couple of ways to load balance SIP.  One of the
nicest
> >> >> stateful LB (might have to be session aware, depending on what
the
> >> leaf
> >> >>> B proxy would require load balancers. The load leaving A might
be
> >> easily
> >> >>> sent to a single very high capacity load balancer that B owns.
This
> >> >>> transaction stateful at a minimum to remember where messages
need
> >> >>> performance of the totally stateless model -- lets say 500
calls
> >> >>> second
> >> >>> a time. Obviously, there is still a lack of controls for
enforcing
> >> >>> transaction stateful all the way through a B2BUA like the edge
of
> >> IMS
> >> >>> variety of proxies is actually traversing into B's load
balancer. I
> >> >>> "media" based bandwidth limitations. One could consider a
central
> >> PDF
> >> >>> C) that can process the communication? How would A share
> information
> >> with
> >> >>>> _to_ peer's A proxy from peer's A end users. It only cares how
the
> >> >>>> Would this load balancer be able to probe peer's B proxy
dynamic
> >> "state"
> >> >>>>> Subject: RE: [Speermint] Congestion and Load Balancing was
Re:
> >> >>>>> end do something related to it other than normal SIP
operations.
> >> I
> >> >>>>> certainly don't think it would be advisable to introduce such
an
> >> >>>>> interface.
> >> >>>>> Suppose that a peering system has peering connections at 3
IXPs
> >> >>>>> to send traffic between PeerA and PeerB that originate in
their
> NY
> >> >>>>> facilities to the other's proxy in New York.  However, if NY
went
> >> >>>> down,
> >> >>>>> If you make it more complicated, where each facility is not
able
> >> to
> >> >>>> take
> >> >>>>> the
> >> >>>>> entire load on a failure, you may need some other load
balancing
> >> >>>> operation
> >> >>>>>> To: 'Brian Rosen'; 'Geoff Devine'; 'Michael Hammer
(mhammer)';
> >> >>>>>> actually understand and maintain proxy state. Lets explore
some
> >> more
> >> >>>>>> NOW--- and MOST IMPORANTLY--- unlike in a HTTP load
balancing
> >> >>>>> application,
> >> >>>>>> the data requirements be? In this case, the
from/to/source/TLS
> >> >>>> socket
> >> >>>>>> connections are being multi-plexed at the proxy. So where do
I
> >> put
> >> >>>>>> presently have some mighty fine self limiting issues with
media,
> >> >>>>>> congestion control.  I've never seen a well engineered SIP
based
> >> >>>>>> you want?  Rack up the servers (best make them stateless,
but
> >> that's
> >> >>>>>> control mechanisms, because the peering mechanisms we have
do
> >> have
> >> >>>>> finite
> >> >>>>>> capacity.  However, I don't see much need for telephone
style
> >> >>>>>> peering points.  We can have SIP proxies that perform the
actual
> >> >>>>>> redundant enough that we get the kind of reliability we
expect.
> >> And
> >> >>>>>>> Telephone networks don't and can't work that way.  They
have
> >> >>>> overload
> >> >>>>>>> conditions and you absolutely must have a mechanism for
dealing
> >> >>>>>>> some that we can.  I believe in a contractual, static,
limit on
> >> >>>>> traffic
> >> >>>>>>>> telephone network are quite different from the
requirements
> >> >>>>>>>> floods a soft switch or media gateway controller with
peering
> >> >>>>> traffic
> >> >>>>>>>> with no notion of congestion control, flow control, or
fault
> >> >>>>>>> management,
> >> >>>>>>>> infinite and the network architecture has to take that
into
> >> >>>> account.
> >> >>>>>>>> To: 'Patrick Melampy'; 'Michael Hammer (mhammer)';
'Hadriel
> >> >>>>>>>> aware of congestion issues at the terminating domain,
beyond
> >> >>>>>>>> I don't see any reason why peers should be aware of
element
> >> >>>>> failures.
> >> >>>>>>>> We
> >> >>>>>>>> clearly understand how to have a set of boxes that appear
to
> >> >>>> one
> >> >>>>>>>> I don't agree we need anything like a BGP for SIP any time
I
> >> >>>>>>>> We attempted this for a really simple subset of the
problem
> >> >>>> (gateway
> >> >>>>>>>>> I agree with you. However some aspects are protocol
worthy.
> >> >>>> Path
> >> >>>>>>>>> In #1 -- proxy availability -- its very similar to how
SS7 is
> >> >>>> used
> >> >>>>>>>>> phone numbers to send down the circuit are provisioned in
> SS7.
> >> >>>> In
> >> >>>>>>> our
> >> >>>>>>>> case
> >> >>>>>>>>> In #3 -- congestion -- is dynamic and not provisionable.
It
> >> >>>>>>>> directly
> >> >>>>>>>>> So I think we do have some protocol work here. I also
think
> >> >>>>>>>>> What there is value in is in defining what mechanisms
exist
> >> >>>>>>>> provision.
> >> >>>>>>>>> definition of limiting, but not the way to determine what
the
> >> >>>>> limit
> >> >>>>>>>>> all of the potential policy mechanisms, or what their
values
> >> >>>>>>>>>> The focus of Speermint should be centered around whether
one

---

From: Klaus Darilion <[email-masked]>
Date: Fri, 11 Aug 2006 08:17:47 +0200

> Please provide some details?

Hi Patrick

The details are in the drafts referred by Otmar. Non-terminal NAPTRs in 
the domainpolicy DNS records can be used to announce transit peers or to 
redirect all calls to the SIP provider hosting this domain.

regards
klaus