Subject: Re: MGC-Initiated Control

From: "Rosen, Brian" <[email-masked]>
Date: Tue, 6 Jun 2000 07:54:04 -0400

In the development of the protocol, and this particular issue,
all of the points you raised were brought up and discussed.
While there is clearly no single "right" answer, the consensus
opinion, weighing several issues, of which this was a big one,
we decided to have the MG initiate the process of creating
a control association.  If you go through the archives,
you will find several messages on the subject, and there was
a lot of discussion in design team meetings.

Having said that, we also decided that the mechanisms we had
were probably not sufficient to cover all the kinds of networks
users and vendors contemplated, and we expected this area to
undergo significant change.  For example, I believe that it
is not a good idea to provision either the MGs or the MGCs;
rather there should be a directory or discovery protocol.

At the moment, the protocol specifies MG initiated
control establishment.  It doesn't PROHIBIT anything,
but if you want interoperable devices, I suggest you implement
that mechanism, at least.

Brian

> -----Original Message-----
> From: Brian F. G. Bidulock [mailto:[email-masked]]
> Sent: Tuesday, June 06, 2000 2:19 AM
> To: [email-masked]
> Subject: Re: MGC-Initiated Control
>
>
> Chuong,
>
> I don't mean to single out your note, but to continue along
> this thread.
>
> I have seen a good number of implementations of control
> protocols where
> the client connects to the server in the fashion you and Bharat
> describe.  However, consider the practicality of this.  We are faced
> with the reality that there are MGC platforms which can
> sustain tens of
> millions of BHCC and support towards a million ports of MG
> devices.  It
> is clearly possible today that one MGC may serve thousands or even
> hundreds of thousands of discrete MG devices.  In this
> arrangement, MGCs
> are built for fault-tolerance and extreme reliability.  MGs, due to
> their multitude, require far less reliability.
>
> Please, consider the case of a system recovering from a
> network outage,
> where thousands and thousands of MG devices are all hunting through
> their (short) lists of MGCs.  Many devices of the same kind can easily
> collide in their attempt to open a transport connection to the MGC.
>
> Consider the case where the MGs come up first.  They will be
> hunting for
> an MGC which does not exist.  Several choices come to mind:
>
>   (1) continue hunting indefinitely (because the system MUST
> come up on
>       its own: manually resetting hundreds of thousands of MG
> devices is
>       not an option).
>
>   (2) after hunting for some time, fall back to a procedure which
>       permits an MGC to indicate when it is available.
>
> Just the hunting itself causes unnecessary network traffic and
> congestion during recovery.  Network outages of sufficient length also
> makes the hunting largely futile.
>
> When the MGC comes up first, it must still ascertain the
> status of each
> of the MG devices.  Without the ability to interrogate them (it just
> "waits" for them to connect), little information can be had about the
> health of the system at the "controller".  Also, if (2) is used at the
> MG, as questioned in another message on this thread, how does the MGC
> know (or know when) to initiate a connection to any given MG device?
> Perhaps after a timeout?  A timeout would delay the recovery
> of a system
> which is already in jeopardy.
>
> Contrast this with the opposite case: where it would be the
> responsibility of the MGC to connect to the MG, and the responsibility
> of the MG to "listen" for the MGC to connect (i.e.  the "controlled"
> device waits for the "controller").
>
> This would permit a recovering MGC or an MGC in a recovering
> network to
> coordinate with its peer MGCs and then establish the connections to
> thousands of MGs in an orderly and controlled fashion.
>
> As to whether the MG is "married" or not (i.e., whether it
> knows of the
> MGC before permitting it to connect) is a network management
> issue.  Who
> connects and who listens is clearly an initialization, switch-over and
> recovery issue.
>
> Consider also that the MG is really the server in this case anyway: it
> is providing specific gateway services to a general purpose controller
> client.  It just so happens that the servers are many and the clients
> are few.
>
> Also consider that using Berkeley TCP Sockets in the above scenario,
> having the MGC "listen" and "accept" requires double the
> number of file
> descriptors for sockets (thousands for the listening socket, thousands
> for the accepting socket), already taxing a model which doesn't scale
> well.  Having the MG listen means that it only requires a handful of
> control sockets (where it may need a plethora of RTP/RTCP sockets,
> thankfully UDP or IP, anyways).
>
> Reversing the connection approach altogether would not overly tax even
> the smallest of embedded MGs, whereas it permits the MGC and the
> resulting system to scale much larger and recover or switch-over in an
> orderly fashion.
>
> Also, I can't conceive of a case where one MG would have thousands of
> MGCs controlling it.  Can you?
>
> If one really wants loose coupling in the model (such as independent
> Mug's having the decision on which controller to connect to at a given
> point in time), it is far better to use a registration process rather
> than connections.  For example, when a host goes to establish a
> connection on the Internet, it performs a DNS query (using a UDP port)
> to discover the IP address of the server before connecting.
> When a host
> goes to access a file share, it checks with a naming service on a UDP
> port as well.  This permits the controller to throttle registrations,
> the result of which is to establish a connection to the requesting
> device.  Even mobile telephone network work this way.  It
> scales better.
>
> On Sun, 04 Jun 2000, Chuong Nguyen wrote:
>
> > Hi Tom
> >
> > I think Bharat brings up a good points.
> >
> > For TCP there were some discussions on the list way back that MG
> > always has to initiated the TCP connect to MGC before any
> > ServiceChange can be sent from MG to MGC.  Also that MGC is the one
> > that should initiate a TCP accept and MG never initiates a
> TCP accept.
> >
> > Your proposal of having MGC sends a ServiceChange to MG
> would require
> > MGC to initiate a TCP connect to the MG which means MG has
> to initiate
> > a TCP accept by default to listen for MGC trying to connect to MG.
> >
> > Can't we just leave everything as is and let MG through NM or other
> > schema to determine whose its controlling MGC has to be and it is up
> > to the MG to connect to MGC?  If all else fails, there is always the
> > human out there to intervene and make thing right.
> >
> > If you really think your proposal is needed, then some
> words should be
> > added to clarify TCP implementation before any
> ServiceChange is sent.
> >
> > This also complicate our design, our implementation is that MGC does
> > not need to know before registration whether MG is text or binary
> > encoding.  It is by virtual of which port the MG uses to registrate
> > w/MGC determines its encoding.
> >
> > Chuong
> >
> >
> [snip]
>
> --
> Brian F. G. Bidulock
> Director GeoGate SW Development
> Network Products, Inet Technologies Inc.
>

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Tue, 6 Jun 2000 11:29:22 -0500

Brian,

I have 1 MGC and 3000 MGs.  This is a real-world situation which we all
face in implementing PSTN gateways.  It is not a speculative architecture,
it is the predominate architecture: single MGC many MGs.  It would be
helpful if your answer could indicate why it it this way: discussion and
consensus are fine, but what are the technical reasons for taking the
current approach which outweigh the reality of its application?  What are
the known technical limitations of the current approach?  What is the
mechanism for change?

(Also, the WG archives are formidable: could you point to a thread?)

--
Brian F. G. Bidulock

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Wed, 7 Jun 2000 02:18:14 -0500

Matt,

On Tue, 06 Jun 2000, Matt Holdrege wrote:

> At 11:29 AM 6/6/00 -0500, Brian F. G. Bidulock wrote:
> >Brian,
> >
> >face in implementing PSTN gateways.
>
> Yes I think we all understand that.

Excellent!  I'm glad I got that point across.

(I really have 2 mirrored SG/MGC combo's and 100,000 MGs on ATM,
but I won't tell anyone if you don't.)

> However you are moving into an area of
> implementations.

You are correct!  Implementation should never be considered in the
design of a protocol.  Protocols are pure and clean things, whereas
implementations are convoluted and dirty.  We should not speak of them.

> Creative designers can overcome this problem with the
> existing protocol.

Yes, I agree: it is important that many restrictions be made so that
only truly creative designers can even contemplate implementation.

> Yes we could be even more creative with allowing either
> side to initiate, but that really hurts interoperability and creates new
> holes in the protocol.

Your logic rings true to me: flexibility ruins interoperability.
TCP is less interoperable because hosts act as both clients and servers.
TCP hosts should be restricted to act solely as a client or solely as a
servers to better ensure interoperability.  All UNIX boxes should either
"listen" all the time or "connect" all the time but never both.  We should
cut the socket interface in half to further interoperability and reduce the
holes at the transport level.  Otherwise, how would the application ever
know when to "listen" and when to "connect"??  A provisioned value???
While were at it, lets completely secure that peer-to-peer IP protocol away
from applications altogether and make client-server the order of the day.

> We have consciously made several restrictive choices
> with MEGACO to get the protocol off the ground.

The more restrictions the better!  Too bad we couldn't have restricted
out those noxious packages and scripts and things.  Extensibility at the
cost of interoperability is what that is.  If it wasn't for that stodgy
ITU process, we could have come to a consensus on MGCP over a year ago.

Making the numerous connect to the few is so obvious a choice--such an
excellent simplifying assumption: we must show protocols like SNMP the
the error of their ways.  All managed devices should be made to connect
to their managers!  They should do this from a provisioned v.....NO, a
Discovery_Process, and search out the managers to connect to!

SNMP should be made to work like NIS: that's what I say.

> This new request to change
> the protocol only hurts the chances of MEGACO ever making it to the market.

I agree: let's cast it in concrete now!  Let's tell the ITU we don't
need no stinkin' annex or addendum or whatever they call it.  It's good
enough how it was.  Every vendor is eager to stuff this protocol in a
product and, well, if a few of them don't like it--tough!  As MEGACO
hits the streets it will knock all other protocols off of their spec
sheets!  Then, they will have no choice but to interoperate--MEGACO
users are waiting.

;) ;) ;)

Matt, (seriously), I don't mean to make light of the efforts of the
MEGACO working group and I understand your frustrations; however, issues
of binding outside the scope of MEGACO has slowed, rather than
facilitated, its rapid introduction.

Some restrictions in the specification impose undue hardships on
practical implementations which surface as "implementation issues."
A change to MEGACO's function is not required, just a removal of
implementation specific bindings in the specification within scopes that
the protocol should not attempt to fully specify.

Who connects to who is a transport `implementation' issue.  How they
connect when they do is a transport protocol issue.  Surely MEGACO can
hit the market without precluding connectionless or peer-to-peer
transports sporting the same or similar semantics at the transport
interface.  MEGACO should not care whether it is runs over an IPX
network, or a native ATM network for that matter, just as long as both
sides interoperate (communicate) when they do.

Surely MEGACO can hit the market without restricting the system
implementation to active/standby.  This is the realm of network and
nodal reliability vs. redundancy and is never a one-suits-all situation.
MEGACO cannot hope to provide all of the messages, syntax and protocol
necessary to coordinate creative designers of load-shared, fault-tolerant
applications, mirrored hosts and redundant networks.

Have faith that the industry can be creative and apply best common
practices in these areas (using the interoperable tools that the IETF
and others have placed at their disposal) without having to be
restricted in how they do it by MEGACO.

Don't change: chop those implementation issues from the spec!  ;)

--
Brian F. G. Bidulock

---

From: Matt Holdrege <[email-masked]>
Date: Tue, 6 Jun 2000 21:12:47 -0700

>face in implementing PSTN gateways.

Yes I think we all understand that. However you are moving into an area of
implementations. Creative designers can overcome this problem with the
existing protocol. Yes we could be even more creative with allowing either
side to initiate, but that really hurts interoperability and creates new
holes in the protocol. We have consciously made several restrictive choices
with MEGACO to get the protocol off the ground. This new request to change
the protocol only hurts the chances of MEGACO ever making it to the market.