Subject: RE: [Speermint] Reachability

From: "Reinaldo Penno" <[email-masked]>
Date: Thu, 6 Apr 2006 03:54:58 -0400

I'm having a hard time understanding the complications...Sorry but I'm
going to ask basic questions again before we dwell in many (more)
discussions. It _seems_ to me we are overly complicating each topic. 

Are A and C paying B to carry _IP_ packets (which includes signaling and
media)? Can A send and receive packets from C? So, unless A and C want
something special done to their signaling traffic I wonder what B has to
do with it... Why would I pay B to be a proxy hop if I can send packets
directly? Are A and C concerned with security, or wondering how to peer
directly? Well, then peer directly over a TLS connection. 

Also, I do not understand "transit services" in this context. This is
not the PSTN. We are talking IP backbones, right?

I'm assuming A has DNS access and so has C. They can figure out by
themselves the "sip route" of the signaling services. There is nothing
SIP related that B can provide that A and C cannot figure out. The
endpoints are in A and C; B does not have control over the E.164
numbers, ENUM, SIP URIS, etc.
 
I can have a SIP TLS connection from my house over 5 different backbones
and peer with another proxy server in Japan. That's the fundamental of
Layer 5 peering, no? It is an overlay network over IP. Unless some
carrier/provider has some access list, I wonder what the problem is. 

Now, maybe I'm missing something, maybe we need to hash out this example
further. 

Regards,

Reinaldo

> -----Original Message-----
> From: Stastny Richard [mailto:[email-masked]]
> Sent: Thursday, April 06, 2006 12:05 AM
> To: Lee, Yiu; Hadriel Kaplan; [email-masked]
> Subject: RE: [Speermint] Reachability
> 
> Inline
> 
> > -----Original Message-----
> > From: Lee, Yiu [mailto:[email-masked]]
> > Sent: Thursday, April 06, 2006 1:22 AM
> > To: Hadriel Kaplan; Stastny Richard; [email-masked]
> > Subject: RE: [Speermint] Reachability
> >
> > This is an interesting thread especially for the scenario A-B-C
where
> B
> > is providing transit services. In near term , I don't see any
operator
> > will like to provide transit services since I don't smell money in
> this
> > area ;-) Also, if A doesn't peer C directly, we have our old friend
> PSTN
> > to do the work (at least working for the voice service).
> 
> No, you do NOT have the Good old PSTN to do the work in SPEERMIND
> SPEERMINT (peering, interreconnect; whatever) is not E.164 aware,
> so the PSTN is NOT an Option
> 
> > The
> > complication of providing transit services is to guarantee service
> > delivery. In theory, the SIP proxy in B doesn't need to record-route
> > itself so that it can leave the signaling path as soon as A & C
> > establish the session. Reality is B must stay in the signaling path
> > because A signed a peering agreement with B and B signed a peering
> > agreement with C, there is no agreement between A & C and the
> agreement
> > is not transitive. If A sends a mid-dialog request directly to C,
C's
> > policy may probably reject it. For the media flow, I also argue that
> > even if A & C have directly IP peering connectivity, A's media
traffic
> > should flow through B's IP network then to C's IP network.
> 
> You are implying L3 peering is atomatically with L5 peering,
> I thought we had this one
> 
> > The reason is
> > B signed QoS agreement with A & C, but A & C may not have any, so C
> > won't prioritize the media traffic coming directly from A's IP
peering
> > interface. If the link is congested, the service quality will
degrade.
> 
> Implying there is an unneccessary Qos agreement in the core. As the
> Scott
> Marcus paper points out, this is unnecessary in most cases and
> also not controllable. QoS, if at all, is only required in the access.
> 
> We should not waste our time with unimplementable issues.
> 
> >
> > I think peering is above policy. I assume that this WG will take the
> > lead to define and standardize the peering policy as well as the
> > protocol distributing the policy.
> >
> > Yiu
> >
> >
> > -----Original Message-----
> > From: Hadriel Kaplan [mailto:[email-masked]]
> > Sent: Sunday, April 02, 2006 9:48 PM
> > To: 'Stastny Richard'; [email-masked]
> > Subject: RE: [Speermint] Reachability
> >
> > Hi Richard, comments inline...
> >
> > > -----Original Message-----
> > > From: Stastny Richard [mailto:[email-masked]]
> > > Sent: Saturday, April 01, 2006 2:46 PM
> > > To: [email-masked]
> > > Subject: [Speermint] Reachability
> > >
> > > after reading the document from Scott Markus on NGN Interconnect I
> > > referenced for weekend reading in my last posting
> > >
> http://www.itu.int/osg/spu/ngn/documents/Papers/Marcus-060323-Fin-v2.1
> > > .pdf
> >
> > Indeed that was an interesting paper - thanks for the pointer! (not
> that
> > I agree with everything in it)
> >
> > > and second we always started naturally at provider A in direction
of
> > > call set-up and not at provider B
> >
> > Personally, I think the bigger "problem" is the provider C, the one
> > after B.
> > :)  C trying to be reachable by A through B.  But that's out of
scope
> I
> > guess.  It's too bad, because that's when BGP got interesting, for
> > example.
> >
> > > Provider B has now (currently only for Public User Identities in
the
> > > form of E.164 numbers) the OBLIGATION making this PUI reachable
for
> > > the public by interconnecting with the public network (in this
case
> at
> >
> > > least via the PSTN) [snipped] So IMHO we can assume that provider
B
> > > hosting a Public User Identity (a SIP URI) MUST make this PUI
> > > reachable in principle.
> >
> > I would think that would only be true if you define the AoR to be a
> > public identity in the public domain, and such regulation was to be
> > created for AoRs.  E.164 numbers are by definition such numbers, I
> > think.  But if, for example, I build a private enterprise network -
> > there's no way I'm obligated to do so just because I use the same
SIP
> > fields AoRs are used in.
> >
> > Having said that, I would think most providers _want_ to make them
> > reachable, because that increases their value.  But as the paper
> pointed
> > out, peering is difficult to manage beyond a few hundred peers, nor
do
> > IP or PSTN providers peer with everyone directly to achieve
universal
> > reachability.  That's why, for me, the more complex problem is the
> > peer(s) between.  But documenting A-B/B-A is a good start.
> >
> > > The NRA normally sets the limits to such an offer.
> >
> > The power of the national rifle association is staggering.  ;)
> >
> > -hadriel
> >
> >
> >
> > _______________________________________________
> > 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: Otmar Lendl <[email-masked]>
Date: Thu, 6 Apr 2006 10:32:55 +0200

> carrier/provider has some access list, I wonder what the problem is. 

Indeed.

If all providers ran open SIP proxies, SPEERMINT would hardly be needed.
(Some details on SIP message formats perhaps, but nothing more.)

As I see it, the real challenge for SPERRMINT is to find a peering
solution in a world where (at least the big) providers run heavily
firewalled SIP proxies.

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

---

From: "Patrick Melampy" <[email-masked]>
Date: Thu, 6 Apr 2006 07:52:28 -0400

Reinaldo -- you wrote

>media)?

I think that a communication with media packets is like a day without
sunshine... I think the media packets are what the service is all about.
Guarantees, reliability, trust, signaling systems, bi-lateral agreements,
service level agreements are all about delivery of media. Nobody would ever
pay B if B doesn't carry the communication request. If B only provided a
location service, then this business model is very close to what Nuestar is
doing with their public ENUM. People do pay for this, but this is not what
SPEERMINT is about.

>Can A send and receive packets from C? So, unless A and C want
>directly?

This is exactly why managing the media flows is so important to these
business models. The media must follow the signaling when a communication
request goes from A to B to C for B to have any value to A and C. If A and C
can interconnect with quality for free (A.K.A. the internet), why would A
and C use B? Well -- it is likely because they are unaware of each other --
or B has some special attributes (such as QoS, routing or aggregation) that
the internet doesn't have.

I also believe that A and C may be telephone companies where the telephone
traffic might originate from PSTN phones alongside IP originated calls.
These operators have real expenses associated with receiving and terminating
a communication request. A and C could not afford to connect to the internet
and offer termination services to just anybody. They would rather NOT do
this. This is the reason for the bi-lateral agreements. Since they can't
have infinity agreements, there is room for aggregating carriers (B in this
example). B aggregates signaling, media, and business agreements.

If we got rid of the PSTN completely, and all of the regulations in the
world, then we can stop worrying about these minor economic issues. I think
this is unlikely.