Subject: Re: MGC-Initiated Control

From: Tom-PT Taylor <[email-masked]>
Date: Fri, 2 Jun 2000 17:12:37 -0400

First, let me apologize for never completing a response to your queries in
March.  My response sat half-finished on my machine until my hard drive
died, and then it seemed a bit late to say anything.

Agreed that I am proposing a change in that the MG would have to listen when
not in a control session.  It is up to the list to decide whether this is an
acceptable solution to a potential problem.

On your further questions:

(1) There may be network situations where network management is able to
contact the MGC but not the MG (e.g. when they have different owners.

(2) and (3) There is no intention of forcing the MG to support multiple
transports or multiple coding schemes.  Assuming that the MGC knows through
network management that the MG needs a controller and that it (the MGC)
should be the one, it could try all possibilities until it gets a response,
or it could have cached the necessary information from an earlier control
session, or it may know what it has to from network management.  This is an
implementation detail.

> -----Original Message-----
> From: Bharat Kaul [SMTP:[email-masked]]
> Sent: Friday, June 02, 2000 2:29 PM
> To:   [email-masked]
> Subject:      Re: MGC-Initiated Control
>
> I was under the impression till now that, in principle, it will always be
> an MG initiating a conversation with the MGC.
>
> In TCP world it implied MG establishes connection with the MGC and sent a
> ServiceChange command (and thereby negating the need to have a listening
> server in MG).....Right ?
>
> In UDP world, life was simpler but still MG initiates the conversation
> with the MGC by sending a ServiceChange.
>
> If my understanding is wrong, I would appreciate clarifications.
>
> Assuming my understanding is wrong, then with the approach suggested there
> are a couple of issues listed below
>
> 1. In principle, MGC are not supposed to knowing unmarried MG's. If so,
> then how does MGC sending the ServiceChange figure out that the MG is
> unmarried ? The only option seems network management. And then it can be
> argued that network management can also intervene on MG side and make MG
> initiate conversation with a new MGC.
>
> 2. Additionally, it enforces that MGC contacting the MG should now know
> the encoding schemes supported at the MG ..how does MGC figure that out ?
>
> 3. Also, do people on here expect MG's to be using both TCP and UDP
> simulataneously for communication to MGC. I would think that an MG will
> choose either one. If that is true, then how will the contacting MGC in
> suggested approach pick transport type.
>
> Thanks
> Bharat
>
>       -----Original Message-----
>       From: Rosen, Brian [mailto:[email-masked]]
>       Sent: Friday, June 02, 2000 8:48 AM
>       To: [email-masked]
>       Subject: Re: MGC-Initiated Control
>
>
>       I don't know what "authorized source" would be, unless it was one of
> the provisioned MGCs
>       it had already tried.
>
>       It does occur to me that you could add a reason which equated to
> "start looking again"
>       Then any MGC could trigger the MG to start again, if it was in the
> state you are positing.
>
>       Again, I don't really think this is very important, and I don't feel
> strongly negative about your
>       proposal.
>
>       In my connectivity lost scenario, I would have the MG wait and then
> start again after some delay,
>       and I would make the delay backoff exponentially.
>
>
>       Brian
>
>        -----Original Message-----
>       From: Tom-PT Taylor [mailto:[email-masked]]
>       Sent: Friday, June 02, 2000 10:58 AM
>       To: Rosen, Brian; [email-masked]
>       Subject: RE: MGC-Initiated Control
>
>
>
>               I agree with the "potential security problem" -- that's why
> I said it would have to be an authorized source.  In what you say below:
> how does the MG know that connectivity has been restored?  The
> ServiceChange command is one way of doing that.
>
>                       -----Original Message-----
>               From:   Rosen, Brian [SMTP:[email-masked]]
>               Sent:   Friday, June 02, 2000 10:48 AM
>               To:     Taylor, Tom-PT [NORSE:B901:EXCH];
> [email-masked]
>               Subject:        RE: MGC-Initiated Control
>
>                       It's a potential security problem, because any
> arbitrary MGC that
>               stumbles across an otherwise unmarried MG can take it over.
> In the
>               present model the MGC has to be someone you are provisioned
> to trust,
>               or someone one of the MGCs you trust told you to trust.
>
>                       Not a really big deal.  I think the circumstance is
> so rare as to be
>               not worth worrying about.  I did think about a circumstance
> where
>               the MG lost connectivity to all MGCs.  It went through its
> list in
>               vain.  The real correct response, when connectivity is
> restored, is
>               to restart the search, and not to have some MGC simply step
> up and
>               take it.
>
>                       Brian
>
>                       > -----Original Message-----
>               > From: Tom-PT Taylor [ <mailto:[email-masked]>]
>               > Sent: Friday, June 02, 2000 9:45 AM
>               > To: [email-masked]
>               > Subject: MGC-Initiated Control
>               >
>               >
>               > There are cases where an MG will not be able to initiate a
>
>               > control session
>               > (e.g. it has gone through its list of MGCs without
> success).
>               > Can we agree
>               > on principle that an MG that is not currently in a control
>
>               > session will
>               > respond to an MGC-sent ServiceChange command directing it
> to
>               > initiate a
>               > session at a given address?  If so, we could add this to
> the
>               > Implementor's
>               > Guide and our IETF equivalent.
>               >
>               > The exact text that would go into the Implementor's Guide
> would be as
>               > follows:
>               >
>               >         If an MG is not currently in a control association
>
>               > with an MGC and
>               > it receives a ServiceChange command from an authorized
> source with
>               > ServiceChangeMethod equal to Handoff, it will attempt to
>               > initiate a control
>               > association as directed by that command.  To make this
>               > possible, an MG not
>               > currently in a control session shall listen for incoming
>               > commands at the
>               > default transport address corresponding to its supported
> transport and
>               > encoding (e.g. UDP port 2944 for text-encoded UDP/ALF).
>               >
>               > Tom Taylor
>               > Phone and FAX: +1 613 736 0961
>               > E-mail: [email-masked]
>               >
>

---

From: Chuong Nguyen <[email-masked]>
Date: Sun, 4 Jun 2000 15:12:11 -0500

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

Tom-PT Taylor wrote:

>
>
> First, let me apologize for never completing a response to your
> queries in March.  My response sat half-finished on my machine until
> my hard drive died, and then it seemed a bit late to say anything.
>
> Agreed that I am proposing a change in that the MG would have to
> listen when not in a control session.  It is up to the list to decide
> whether this is an acceptable solution to a potential problem.
>
> (1) There may be network situations where network management is able
> to contact the MGC but not the MG (e.g. when they have different
> owners.
>
> (2) and (3) There is no intention of forcing the MG to support
> multiple transports or multiple coding schemes.  Assuming that the MGC
> knows through network management that the MG needs a controller and
> that it (the MGC) should be the one, it could try all possibilities
> until it gets a response, or it could have cached the necessary
> information from an earlier control session, or it may know what it
> has to from network management.  This is an implementation detail.
>
>      I was under the impression till now that, in principle, it will
>      always be an MG initiating a conversation with the MGC.
>
>
>      In TCP world it implied MG establishes connection with the MGC
>      and sent a ServiceChange command (and thereby negating the need
>      to have a listening server in MG).....Right ?
>
>
>      In UDP world, life was simpler but still MG initiates the
>      conversation with the MGC by sending a ServiceChange.
>
>      Assuming my understanding is wrong, then with the approach
>      suggested there are a couple of issues listed below
>
>      1. In principle, MGC are not supposed to knowing unmarried MG's.
>      If so, then how does MGC sending the ServiceChange figure out
>      that the MG is unmarried ? The only option seems network
>      management. And then it can be argued that network management can
>      also intervene on MG side and make MG initiate conversation with
>      a new MGC.
>
>
>      2. Additionally, it enforces that MGC contacting the MG should
>      now know the encoding schemes supported at the MG ..how does MGC
>      figure that out ?
>
>
>      3. Also, do people on here expect MG's to be using both TCP and
>      UDP simulataneously for communication to MGC. I would think that
>      an MG will choose either one. If that is true, then how will the
>      contacting MGC in suggested approach pick transport type.
>
>
>      Thanks
>      Bharat
>           I don't know what "authorized source" would be, unless it
>           was one of the provisioned MGCs
>           it had already tried.
>
>           It does occur to me that you could add a reason which
>           equated to "start looking again"
>           Then any MGC could trigger the MG to start again, if it was
>           in the state you are positing.
>
>           Again, I don't really think this is very important, and I
>           don't feel strongly negative about your
>           proposal.
>
>           In my connectivity lost scenario, I would have the MG wait
>           and then start again after some delay,
>                I agree with the "potential security problem" -- that's
>                why I said it would have to be an authorized source.
>                In what you say below: how does the MG know that
>                connectivity has been restored?  The ServiceChange
>                command is one way of doing that.
>
>                stumbles across an otherwise unmarried MG can take it
>                over.  In the
>                present model the MGC has to be someone you are
>                provisioned to trust,
>                        Not a really big deal.  I think the
>                circumstance is so rare as to be
>                not worth worrying about.  I did think about a
>                circumstance where
>                the MG lost connectivity to all MGCs.  It went through
>                its list in
>                to restart the search, and not to have some MGC simply
>                step up and
>                take it.
>
>                        Brian
>
>                > respond to an MGC-sent ServiceChange command
>                directing it to
>                > initiate a
>                > session at a given address?  If so, we could add this
>                to the
>                > Implementor's
>                > The exact text that would go into the Implementor's
>                Guide would be as
>                > follows:
>                >
>                > it receives a ServiceChange command from an
>                authorized source with
>                > default transport address corresponding to its
>                supported transport and
--
  Alcatel USA, Inc             Internet: [email-masked]
  1000 Coit Road Plano, Texas 75075           Phone:    (972) 519-4613
  **** The opinions expressed are not those of Alcatel USA, Inc ****

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Tue, 6 Jun 2000 01:19:26 -0500

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:

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