Subject: Re: [drinks] Some comments on the use-cases draft

From: "Sumanth Channabasappa" <[email-masked]>
Date: Tue, 17 Mar 2009 16:09:16 -0600

Otmar, 

Thanks for your comments. I guess we - as in the design team - were
expecting more feedback prior to responding, or we got busy. Anyway, I
will start with some quick responses and let the design team pitch in
with additional thoughts. 

----
* This is a telco design. Basic bell-head thinking with only some
marginal
sprinkling of Internet ideas. This is a document which describes how one
might carry over the telco provisioning, interconnection and call
routing
approaches to the VoIP world.

All fine and good, but to be provocative: why is this an IETF WG
document
and not an ITU-T, OASIS or 3GPP paper? The role model, the actors and a
most use-cases are almost straight from the PSTN playbook.
[S] Can you provide specific use cases that you would have rather liked
to see (in addition to your thoughts later on in the email, which help
some)? 
As a note, I am not questioning your observation! The current use cases
are based on perceived industry needs (by the design team). It will be
nice to see how we can make it more relevant, if it is not.
----

* This is way too ambitious on one hand. Defining all this in a single
protocol and implementing the registry which actually does all these
things
is a herculean task.

Layering, folks. Layering.
[S] Ah! Keep in mind that this is a requirements document. We can
prioritize and specify protocol phases if the WG feels that this is too
much at once! :)

----
Divide the problem into discrete, clearly separated sub-problems (see
the
speermint LUF/LRF split for a good one) and the complexity can be
brought
under control.
[S] Good suggestion - although I am unsure of the LUF/LRF example :^)

----
* This is way too conservative on the other hand. There is little
dynamic
routing. There is no integration of enterprise VoIP routing with carrier
routing. There no possibility of ad-hoc peering.
[S] The use cases are not all encompassing, as you rightly indicate. We
should consider things we have not discussed yet, such as your
suggestions.

----
>   SED Record:   A SED Record contains much of the session
establishment
>      data or a 'redirect' to another registry where the session
>      establishment data can be discovered.  SED Records types
supported
>      are NAPTRs, CNAME, DNAME, and NS Records.

What about TLS parameters, Source IP addresses of SBEs, Codec
constraints,
SIP profiles, ...

This is far too DNS focussed.
[S] I agree. We need to consider parameters specified in Section 3.3,
RFC5486.

----
>   SED is typically created by the terminating SSP and consumed by the
>   originating SSP.

Careful here: in the case of multi-hop routing, the SED towards the next
hop are relevant, and these may have little to do with whatever the
terminating SSP has created. See 4.2.2. of the speermint terminology
draft.
[S] I concur; we need to clarify this point. 

----
>    For scalability reasons SED is rarely exchanged
>   directly between the intended parties.  Instead, it is exchanged via
>   intermediate systems - termed Registries within this document.  Such
>   registries receive SED via provisioning transactions from other
SSPs,
>   and then distribute the received data into Local Data Repositories.

This is true for anything dealing with TNs. Once these are mapped to
something amenable to aggregation, this argument falls completely down.

We have a serious mistake in the base assumptions here. If we do proper
layering, then the routing information does *not* need these
intermediate
registries. The registries are only needed for the TN ->
Destination-Group
mapping.

Yes, that's the way it has been done in the PSTN and thus it would be
easy
to integrate VoIP into the same provisioning processes.

That's one of the fundamental design question: do we design an
incremental
update to the way carriers have been operating, or do we design an
addition
to the IETF SIP world which enables scalable multihop routing based on
TNs?

These are two very different goals.
[S] Interesting! I will have to think about this some more. I will let
the WG pitch in on this!

----

>   o  Registries are the authoritative source for provisioned session
>      establishment data (SED) and related information.

Eeek.

SED includes what the next hop is. In a dynamic network, this can change
quickly as SBEs or links fail, congestion makes paths unavailable or
some
business decisions make a different path more attractive.

I cannot fathom that

* these real-time routing information is exchanged via the registry,

* carriers outsource the business decision part of the call routing
  algorithm to third parties.
[S] In the current paradigm (within the I-D), the registry will need to
be updated to reflect changes, which is then propagated to local data
repositories. The provisioned data should ideally be resilient to
hiccups (e.g., contain multiple routes to account for backups,
prioritization). Isn't the ability to dynamically provision data one of
the reasons why we want to work on this?

Perhaps I am misunderstanding the comment.

----

- S

---

From: Otmar Lendl <[email-masked]>
Date: Mon, 23 Mar 2009 22:14:48 +0100

Sumanth,

Just some quick notes, I hope you have a good session tomorrow. It's
unlikely that I can join via Jabber.

Sumanth Channabasappa wrote:
> expecting more feedback prior to responding, or we got busy. 

Let's hope where will be a discussion here.

> routing approaches to the VoIP world.
> 

Here are some scenarios:

* Enterprise PBX with multiple connections to carriers, trying to optimize
  outgoing calls.

* Any form of ad-hoc, not manually pre-configured peering.

* e.g.: All PBXs of an industry sector want to peer, and authenticate based
on TLS certs by some trade group.

More importantly, I have this nagging feeling that most of your use-cases
imply that there will be a central registry which will feed the data back
into local data repositories.

I don't see this as a given for the routing part.

> nice to see how we can make it more relevant, if it is not.

Well, given the people on the design team who are either used to utilize
such a setup or provide this registry, this is not surprising.

> things is a herculean task.
> 

You're requirements are based on a design decision (all data exchange is
via the same protocol and possibly all via a registry).

Take that away, e.g. "do the TN -> routing group mapping via a registry,
but do the routing peer2peer between connected SSPs", and you get instant
layering. And then it isn't "protocol phases", but two completely distinct
protocols.

> [S] I agree. We need to consider parameters specified in Section 3.3,

See Alex's draft and also draft-hancock-sip-interconnect-guidelines-00.

> the reasons why we want to work on this?

I think we're back to the fundamental outlook towards this problem.

One can look at the problem space from the telco point of view, where you
have a relatively static network. Each border element is hardcore
telco-grade equipment, inherently redundant and likely clustered as well.
You don't plan that such a border element is unavailable in toto often.

In the Internet world, this is a bit like HTTP and email: You usually don't
change the DNS for simple fallback scenarios: you might have a few A (or
MX) records, but the real redundancy is provides by load-balancers and
heavy duty server machinery. SIP with the NAPTR/SRV lookups uses the same
approach: on failure of the primary element, fall back to others.

Once you go to the Internet Routing layer, this changes. If a router (or
link) fails, the BGP session goes down and another path has to be selected.
There is no "hmm, let's try this other MAC address, maybe there is a
standby device." You don't do VRRP or any of these cluster-features in the
routing space. On failure, you just let the routing protocol select a new
path. Instantly. This is a bit like the RAID principle: you don't build a
single, super-reliable disk, but combine cheap disks with a bit
intelligence and you get good reliability.

Now, the question is, what's the better routing model for what we are
trying to achieve here?

The original SIP design is simple: directly connect to the destination
network via the common IP transport network. There is no multi-hop routing
problem on the SIP layer. Failures in the transmission layers are covered
by the IP routing protocols, so SIP never needed to care. SRV records
suffice to loadbalance/fallback within the destination network.

All fine and dandy. Except that this is not what happened in the real
world. There is no single common IP network for VoIP. There are a bunch of
interconnection networks and private peering links in addition to the
public Internet. VoIP routing is thus a multihop routing problem.

And for a multihop routing problem, the NAPTR/SRV fallback mechanisms are
NOT ENOUGH. Example network diagram:

A -- B -- C -- D
  \          /
   - E -- F

A has paths ABCD and AEFD to D. Now assume A is using the ABCD path.
INVITES are passed along, but suddenly C fails to be reachable by B.
B can try all the other SRV records of C it finds, but it just can't pass
on the call. A has to learn of this link failure and route to E instead.

Yes, it is possible to do this with a central registry: all players need
keep it up to date in real-time with respect to link/SBE/DBE failures. That
registry needs to have a complete map and state of all links between all
SSPs in order to play the routing oracle. (How C could tell the registry
that it just lost power to it's datacenter, and thus can't act as a transit
network any more is beyond me.) This is a monopoly position and a single
point of failure for the whole Voice Network.

Or, alternatively, you go for the BGP model and let B tell A "sorry, I
can't reach C and D any more". Directly from border-element to border-element.

You might say that such link failures are rare. Maybe they are if you think
only of real large carriers and their 5-nines equipment. That's not
necessarily all there is to VoIP. There are enough pure-VoIP startups, and
(at least here in Austria) a good number of local cable networks are
providing IP and VoIP services as well. Corporate PBXs are another example.

It's a question of where you put in your redundancy: fortify the nodes or
prepare for failed nodes with a really dynamic routing protocol.

I just can't see how you really can replace an agile routing protocol by a
central registry.

> Perhaps I am misunderstanding the comment.

I hope this clarifies my thinking a bit.

/ol
-- 
// Otmar Lendl <[email-masked]>, T: +43 1 5056416 - 33, F: - 933 //

---

From: "Cartwright, Kenneth" <[email-masked]>
Date: Tue, 24 Mar 2009 16:37:05 -0700

Sorry for the delayed response, am having issues with my laptop her in
San Fran.  The File Processor is a *very* small piece of software, so no
design document was necessary (i.e. the code is so small that the code
itself and the javadoc comments therein are best approach to documenting
it).  However, the Technical Requirements Document describes, in detail,
the behavior of the File Processor.

As far as the source control goes:

1) Unfortunately, the File Processor code lives within the NRD-PS
Project within our Subversion repository.  What we should have done was
introduce a new project, maybe called "NRD/NIR Input File Processor".
2) I believe what we should do is take the current File Processor code
base out of the NRD-PS project and create a new CM repository project.
3) Your additions and changes to the File Processor would then be made
in that repository.

Ken

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Otmar Lendl
Sent: Monday, March 23, 2009 5:15 PM
To: Sumanth Channabasappa
Cc: IETF DRINKS WG
Subject: Re: [drinks] Some comments on the use-cases draft

Sumanth,

Here are some scenarios:

* Enterprise PBX with multiple connections to carriers, trying to
optimize
  outgoing calls.

* e.g.: All PBXs of an industry sector want to peer, and authenticate
based
on TLS certs by some trade group.

More importantly, I have this nagging feeling that most of your
use-cases
imply that there will be a central registry which will feed the data
back
into local data repositories.

Take that away, e.g. "do the TN -> routing group mapping via a registry,
but do the routing peer2peer between connected SSPs", and you get
instant
layering. And then it isn't "protocol phases", but two completely
distinct
protocols.

One can look at the problem space from the telco point of view, where
you
have a relatively static network. Each border element is hardcore
telco-grade equipment, inherently redundant and likely clustered as
well.
You don't plan that such a border element is unavailable in toto often.

In the Internet world, this is a bit like HTTP and email: You usually
don't
change the DNS for simple fallback scenarios: you might have a few A (or
MX) records, but the real redundancy is provides by load-balancers and
heavy duty server machinery. SIP with the NAPTR/SRV lookups uses the
same
approach: on failure of the primary element, fall back to others.

Once you go to the Internet Routing layer, this changes. If a router (or
link) fails, the BGP session goes down and another path has to be
selected.
There is no "hmm, let's try this other MAC address, maybe there is a
standby device." You don't do VRRP or any of these cluster-features in
the
routing space. On failure, you just let the routing protocol select a
new
path. Instantly. This is a bit like the RAID principle: you don't build
a
single, super-reliable disk, but combine cheap disks with a bit
intelligence and you get good reliability.

The original SIP design is simple: directly connect to the destination
network via the common IP transport network. There is no multi-hop
routing
problem on the SIP layer. Failures in the transmission layers are
covered
by the IP routing protocols, so SIP never needed to care. SRV records
suffice to loadbalance/fallback within the destination network.

All fine and dandy. Except that this is not what happened in the real
world. There is no single common IP network for VoIP. There are a bunch
of
interconnection networks and private peering links in addition to the
public Internet. VoIP routing is thus a multihop routing problem.

And for a multihop routing problem, the NAPTR/SRV fallback mechanisms
are
NOT ENOUGH. Example network diagram:

A -- B -- C -- D
  \          /
   - E -- F

A has paths ABCD and AEFD to D. Now assume A is using the ABCD path.
INVITES are passed along, but suddenly C fails to be reachable by B.
B can try all the other SRV records of C it finds, but it just can't
pass
on the call. A has to learn of this link failure and route to E instead.

Yes, it is possible to do this with a central registry: all players need
keep it up to date in real-time with respect to link/SBE/DBE failures.
That
registry needs to have a complete map and state of all links between all
SSPs in order to play the routing oracle. (How C could tell the registry
that it just lost power to it's datacenter, and thus can't act as a
transit
network any more is beyond me.) This is a monopoly position and a single
point of failure for the whole Voice Network.

Or, alternatively, you go for the BGP model and let B tell A "sorry, I
can't reach C and D any more". Directly from border-element to
border-element.

You might say that such link failures are rare. Maybe they are if you
think
only of real large carriers and their 5-nines equipment. That's not
necessarily all there is to VoIP. There are enough pure-VoIP startups,
and
(at least here in Austria) a good number of local cable networks are
providing IP and VoIP services as well. Corporate PBXs are another
example.

It's a question of where you put in your redundancy: fortify the nodes
or
prepare for failed nodes with a really dynamic routing protocol.

I just can't see how you really can replace an agile routing protocol by
a
central registry.

/ol
-- 
// Otmar Lendl <[email-masked]>, T: +43 1 5056416 - 33, F: - 933 //
_______________________________________________
drinks mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/drinks

---

From: "Cartwright, Kenneth" <[email-masked]>
Date: Tue, 24 Mar 2009 16:51:53 -0700

Sorry about this email.  My laptop and Outlook instance is having
issues.  Needless to say, this email does not relate to drinks and can
be ignored.

Ken 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Cartwright, Kenneth
Sent: Tuesday, March 24, 2009 7:37 PM
To: Otmar Lendl; Sumanth Channabasappa
Cc: IETF DRINKS WG
Subject: Re: [drinks] Some comments on the use-cases draft

Ken

-----Original Message-----

Sumanth,

Here are some scenarios:

A -- B -- C -- D
  \          /
   - E -- F

/ol