Subject: Re: [Speermint] Definition of "Peering"

From: "Stastny Richard" <[email-masked]>
Date: Thu, 30 Mar 2006 12:40:00 +0200

Hi Otmar,
 
your definition of SIP peering (or is it more a definition
of the scope of SPEERMINT?) seems to be at least a basis for discussion.
 
But it implies that it is valid only for (or SPEERMINT is 
dealing only with) additional L3 peerings - this will Keith make happy ;-)
 
I have only a problem with this:
 
>I don't think we should care whether the default interconnection
>mechanism is SIP according to RFC3261, the PSTN, SIP via
>a transit network, or simply no default interconnection at all.
 
As you point out in (have I now to say direct) L3 peering,
there is always a default connection.
 
In SPEERMINT this could only be RFC3261/3263, and
it cannot be the PSTN (Speermint is not
dealing with E.164 numbers)
 
And having no default is also not a good idea.
 
Richard

________________________________

Von: Otmar Lendl [mailto:[email-masked]]
Gesendet: Do 30.03.2006 11:12
An: Reinaldo Penno
Cc: [email-masked]
Betreff: [Speermint] Definition of "Peering"

On 2006/03/28 23:03, Reinaldo Penno <[email-masked]> wrote:
> Hello,
>
> I've been reading "reqs and terminology" and I would like to step back
> and ask some questions about some of the definitions.

Good idea. Here is my answer.

> Peering:
> ========
>
> In layer 3 peering two routers exchange their routing tables, reach a
> steady state, and after that data packets can flow between the two
> domains.

I think this definition is too broad: it applies to any BGP connection.

A Layer 3 peering is a shortcut connection established to avoid
sending the traffic via the default upstream networks. Such
a direct connection saves money (upstream is more expensive) and
improves the network performance.

L3 peering is not about reachability per se. For that, one
single interconnect to an upstream networks suffices.

I'll use the term "interconnection" below in a very generic sense,
and not in the one used in the PSTN world. I'm very much open
to alternative wordings.

So what about:

-----
SIP Peering is the establishement of an alternative communication
path between the SIP elements of two entities (service providers,
corporations, ...) to improve over the service offered by the
default interconnection. The improvements offered by this new path
can include (but are not limited to)
  * better QoS
  * cost benefits (e.g. if the default path is billed by minute)
  * additional features (e.g. wideband codecs or IM)
  * abuse handling.

The default interconnection between two parties is out of scope
for the Speermint WG.
-----

I don't think we should care whether the default interconnection
mechanism is SIP according to RFC3261, the PSTN, SIP via
a transit network, or simply no default interconnection at all.

All we need to focus on here in Speermint is to define
a framework which can be used to establish more direct and thus
better crosslinks between two SIP service providers.

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

_______________________________________________
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: "Michael Hammer \(mhammer\)" <[email-masked]>
Date: Thu, 30 Mar 2006 11:37:09 -0500

Otmar,

Your question is circular.

What you posited earlier was that given indirect option 1, define better
direct option 2.  While one can learn from experience with option 1, I
don't think it is a pre-requisite or dependency for defining option2.

Thus, defining where we have been (status quo) is not as important as
defining where we want to go.  In fact, spending less time looking
backwards might help make better progress moving forward.

Mike

> -----Original Message-----
> From: Otmar Lendl [mailto:[email-masked]] 
> Sent: Thursday, March 30, 2006 9:29 AM
> To: Michael Hammer (mhammer)
> Cc: Reinaldo Penno; [email-masked]
> Subject: Re: [Speermint] Definition of "Peering"
> 
> On 2006/03/30 15:03, "Michael Hammer (mhammer)" 
> <[email-masked]> wrote:
> > 
> > SIP Peering is the enablement of direct connection between SIP 
> > providers offering essential experience-enhancing services, without 
> > the need to resort to transit middlemen providing solely 
> route discovery.
> 
> Michael,
> 
> So in the absence of an established SIP Peering: can users of 
> SIP provider A call customers of SIP provider B?
> 
> If yes, how is that achieved?
> 
> -----------
> 
> I have the feeling that the members of this WG doesn't agree 
> on what the status quo is. No wonder that we have 
> difficulties to agree on what problem Speermint is supposed to solve.
> 
> /ol
> --

---

From: "Malas, Daryl" <[email-masked]>
Date: Thu, 30 Mar 2006 13:36:14 -0700

Comments inline...Thanks...

-----Original Message-----
From: Patrick Melampy [mailto:[email-masked]] 
Sent: Thursday, March 30, 2006 11:53 AM
To: 'Otmar Lendl'; 'Michael Hammer (mhammer)'
Cc: [email-masked]
Subject: RE: [Speermint] Definition of "Peering"

There is currently only one type of peering with one set of reciprocal
values that IP Network Owners have in the internet today. The real work
of
this group should be to provide a method to exchange packets where there
are
different reciprocal values based on a subset of the total packets
associated with a service (such as SIP signaled media). This must be
done in
such a way that no existing services or reciprocal relationships are
affected. Additionally, the prevalent protocols used for Layer 3
networking
will not be easily extended -- thus the assumption should be made that
an
architecture that assumes no major changes to BGP4 will be possible.

[Malas, Daryl] Unless I am misunderstanding your thought, I think
peering is higher than Layer 3.  Layer 3 is simply the transport for SIP
(Layer 5) peering.  The transport capability can differ greatly from
"shared public internet", IPVPN, private line, and many others.  This
group should focus at Layer 5 as described in the "Requirements and
Terminology" draft.  Leave transport and the priority/value of packets
up to interconnect designs and strategies.--

The requirements start at Layer 3 (IP Connectivity, and reachability)
and
extend to addressing and location of endpoints in adjacent networks and
paths to endpoints more than one network hop away. The billing and
business
models are just the icing on the cake.

[Malas, Daryl] I agree, billing and business models will be a negotiated
aspect of peering, and will differ greatly based on pre-arranged peering
agreements.  Common CDR information relative to SIP signaling will
remain consistent in peering for these aspects.--

Even in a world of e2e free internet-hippy style networking, the value
of
each packet will be different based on the service the packet is part
of.
This value will be a function of the layer 3 IP-IP interconnection. The
IETF's mission is to "make the internet better", and an internet that
offers
each managed network participant the ability to extract maximum value is
a
better internet.

No solution proposed by anybody will ever remove the best-efforts e2e
internet (Your safe Henry). Free services will always be available. The
reciprocal value of free services is just that -- exactly equal to the
reciprocal value or maximum routing efficiency. Thus the only time the
value
exchange of peering relations for specific services matches exactly best
efforts exchanges is when the service is a zero cost, best efforts
service.
In these cases, the network owner has no incentive to modify routing of
packets. Nor does the service provider have any incentive to deploy any
equipment other than the minimum requirements for best efforts.

[Malas, Daryl] The internet will remain as a transport mechanism for a
low cost peering relationship.  The value here is defined easily.
Peering can encompass an interconnection with the Internet maintaining
both private and public peering capabilities.  This reminds me of the 3
different categories of ENUM (Public, Private, and Carrier -- If I
remember correctly).  I think SPEERMINT should define different
categories of peering in a similar manner.--

Balkanized? Walled gardens? Net-Neutrality? How about a better, more
useful
internet that can enable differentiated services -- yet retains the
neutrality and openness as core values. 

-----Original Message-----
From: Otmar Lendl [mailto:[email-masked]] 
Sent: Thursday, March 30, 2006 9:29 AM
To: Michael Hammer (mhammer)
Cc: [email-masked]
Subject: Re: [Speermint] Definition of "Peering"

> SIP Peering is the enablement of direct connection between SIP
providers
> offering essential experience-enhancing services, without the need to
> resort to transit middlemen providing solely route discovery.

Michael,

So in the absence of an established SIP Peering: can users of SIP
provider A
call
customers of SIP provider B?

-----------

I have the feeling that the members of this WG doesn't agree on 
what the status quo is. No wonder that we have difficulties to 
agree on what problem Speermint is supposed to solve.

/ol

---

From: "Hadriel Kaplan" <[email-masked]>
Date: Thu, 30 Mar 2006 23:10:42 -0500

Hi Henry,
Comments inline...

> From: Henry Sinnreich [mailto:[email-masked]]
> Sent: Thursday, March 30, 2006 4:23 PM
>
> Users pay for Internet access service, which seems to be a booming
> business.

Well I can't speak for it being a booming business or not, but I think what
you said is exactly right about Internet access - and shows the confusion
caused by us using the same words but possibly meaning different things.  

It is absolutely true that people pay for "Internet Access", and Internet
access is what they should get for that payment.  If you want to install a
sip phone on your PC and make a point-to-point sip call to your friend -
that should be possible.  If you want to point your sip phone to the proxy
or registrar of your choosing, so long as the owner of the registrar/proxy
you choose agrees - then that should be possible.  As should best-effort
forwarding of any IP packets of any port numbers using any transport layer
of your choosing to anywhere routable/reachable in the Internet, so long as
the far-end IP-Address destination allows it... you get the idea.

The IETF is a completely inappropriate place to discuss NOT allowing that.
In my opinion, it MUST be the case that NO output of this WG describes
blocking such best-effort "Internet Access" traffic, or blocking the ability
to do that with your SIP UA. 

So when you say "end-to-end" or "e2e" - is that what you mean?  Being able
to create sip sessions either directly from your PC to your friend's PC?  As
well as through proxies of your choosing, so long as the proxies you chose
allow you to?  If so, I think we agree.

To some of us, the confusion comes about because the word "access" has a
special connotation for voip providers about customers joining and creating
sip sessions through a specific collection of sip proxies/registrars.  The
joining can be explicit through challenged registration means, or implicit
through static configuration, or whatever.  

The confusion is that from the operator's perspective, they should
absolutely have the right to only allow specific users to join their
collection of sip proxies/registrars/etc.  Just like a bank running a web
server has the right to only give their paying customers access to their
server.

The very concepts of SIP/HTTP challenge-response, or mutual-TLS, or any such
authentication mechanisms defined by IETF working groups tacitly implies to
me that the operator of the proxy/registrar has an IETF-sanctioned right to
reject unauthorized users from joining his collection of proxies/registrars.

Do we agree on that? 

-hadriel