Subject: RE: [Speermint] Reachability

From: "Stastny Richard" <[email-masked]>
Date: Thu, 6 Apr 2006 09:05:18 +0200

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

---

From: "Hadriel Kaplan" <[email-masked]>
Date: Thu, 6 Apr 2006 15:02:21 -0400

Hi Richard,
Comments inline... (this list is getting busy! :)

> 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

I believe Yiu was being sarcastic - the idea is exactly that we don't want
to use the PSTN if we don't have to.  :)

Having said that, it seems ludicrous to me that we don't want to allow for
reaching 99.9% of the planet Earth's communication devices, simply because
part of the path may have a TDM transport without 40 bytes of wrapping above
it and not cross routers from a few vendors the entire way.  Don't ya think?
;)  
If you want to create a change, providing maximal basic reach with
advanced/free ip-only-reach will win more converts than forcing
pstn-celibacy. 

> 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.

That is not how I read his paper: although it was the conclusion, the
conclusion was based on premises which actually tend to make one think doing
QoS for VoIP may have value.  But I am not concerned with what his views
are.
We can have a lengthy discussion of why it has value if you wish, but I'm
not sure it will help because my guess is we will not come to agreement.  

The interesting thing is, paid VoIP service may actually be the revenue and
demand driver which gets it over the adoption hump.  There is no question it
will not happen overnight, and neither will Speermint adoption, nor VoIP.
But those are based on market forces, and a standards body rarely can
predict such things.

What an open standards body should do is provide several options which can
be chosen based on one's needs/wants, and let the market decide the rest.
If you're right, we will have wasted some time.  If you're wrong, we will
have squandered an opportunity.  I am willing to dedicate time to it, and
you may ignore it as you wish.

To the point of whether it is "controllable": it is, and it is done today.  

> We should not waste our time with unimplementable issues.
 
I'm not sure how one can say that, when the possible solutions to it have
not even been discussed (nor even really the problem).  I thought the whole
idea here is determine the requirements, then figure out how they can be
met, and if they can't then determine if it is a further study/work-area.
Is that not part of the charter?

-Hadriel