Subject: Re: [Speermint] draft-mahy-speermint-direct-peering-00.txt

From: "Patrick Melampy" <[email-masked]>
Date: Tue, 1 Aug 2006 17:30:11 -0400

Rohan - excellent work - thank you!

I wanted to understand and comment on your draft. Section 4.1.3 entitled
Carrier ENUM Lookup is really interesting, and I believe this concept can
really work. I wanted to understand the mechanism a little more. If the
"carrier-of-record" is returned, there may not be a guarantee that there
exists a useful adjacency. I also assume that there may be more than one
carrier-of-record for each domain (I'm thinking that a large multi-national
company like NEC might have NTT be a carrier of record in Japan, but AT&T as
a carrier of record in the USA). I believe that in the case of more than one
carrier-of-record, the source of the communication can just pick whichever
they think is best.

I think that carrier-enum could really work if each participating domain
built its own table/database. So carriers would advertise through some means
reachable domains. These would be placed into a local adjacent-carrier-enum
database, with the resultant always being the network that delivered the
advertisement. Thus every carrier-enum resolution would always resolve to a
NAPTR record that pointed to a single adjacent carrier. It would be possible
to get two adjacent carriers that can complete a communication. Breaking the
tie is out of scope currently, and is likely to be based on parameters of
the business relationship. This has the possibility to scale to any size
imaginable, and always be capable of resolving which next hop network can
complete a communication request. So now we have the DOMAIN of the next hop
network (as opposed to the final carrier-of-record).

However when we get to section 4.1.5 entitled SIP DNS resolution, I worry
that this is insufficient. First of all, I believe that network adjacencies
will be more managed than people think. I think that there will likely be
service guarantees, performance measurements, and contractual commitments. I
also believe that these types of requirements will be defined by specific
adjacencies. So if carrier A peers with Carrier B, A and B will likely have
complex agreements. These will likely include volume commitments, and
capacity guarantees. So I think that A and B will have some structure around
how each accesses the other. I think (based on what I see today) this will
include (for A sending to B)

1.)     Which proxies can A use on B's network

2.)     What rates of calling can A initiate at each of B's proxies (each
may be different)

3.)     What total call count is B willing to support

4.)     What total bandwidth is B willing to support for media

The reciprocal is true if calls go from B to A. 

I believe that there should be a new step inserted in the process. Once we
have the domain of the adjacent network to use, we should go through a step
of obtaining through some mechanism the list of proxies that are available
at the adjacent network for use. Once we locate the list of proxies, we
should pick the best one (distance/cost/load/etc), then use the DNS SRV
mechanism in 4.1.5 for getting transport methods and addresses.

I don't believe DNS/SRV responses can provide enough fine grained controls
over proxy selection to keep general chaos from breaking out. I just don't
think the carriers will use a system that can't be made very deterministic
and predictable. 

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