Subject: Re: Supplying only a port on a ServiceChangeAddress

From: Christian Groves <[email-masked]>
Date: Mon, 4 Sep 2000 10:38:59 +1100

G'Day Brian and Flemming,

I saw that the difference between when you use ServiceChangeAddress and
ServiceChangeMid was that the ServiceChangeAddress was used when talking
to an already contacted physical MGC. The ServiceChangeMid was used to
contact a physically seperate MGC. So I don't see the need of
disallowing anything but the port in IP as the MGC may have a range of
addresses.

Cheers, Christian

"Rosen, Brian" wrote:
>
> I thought you might say that, I've been thinking about it
> since I sent the message.
>
> Posing the question slightly differently, if the ServiceChangeAddress
> can do what ServiceChangeMid can do, so why have two mechanisms?
> The only difference would be the MGs actions.  If you used
> ServiceChangeAddress,
> the MG would not send a new ServiceChange command to the new address.
> If you used ServiceChangeMid, it would.  The end result would be the same.
>
> We can:
>         Explicitly disallow ServiceChangeAddress from being used to
>                 change anything but IP Port when used with IP
>         Get rid of one of the two of them
>
> I favor the former, as that is easiest, is most consistent with
> history, and makes the most sense to me.  I'll note that what
> we call ServiceChangeAddress used to be "port".  It got
> changed when we realized "port" wouldn't make sense if it was
> not an IP transport.
>
> Brian
>
> > -----Original Message-----
> > From: Flemming Andreasen [mailto:[email-masked]]
> > Sent: Tuesday, August 29, 2000 7:37 PM
> > To: Rosen, Brian
> > Cc: [email-masked]
> > Subject: Re: Supplying only a port on a ServiceChangeAddress
> >
> >
> >
> >
> > "Rosen, Brian" wrote:
> >
> > > I think the issue is that you can have the same MGC have multiple
> > > IP addresses.  You accept the association, but change the address.
> > > Say, a pool of servers appearing to be one MGC.
> >
> > I'm not sure I fully understand what an association is then.
> > What's the
> > difference/relationship between the association address and the
> > ServiceChangeMgcId (which may itself contain an address or indirectly
> > refer to a number of addresses through DNS) ?
> >
> > -- Flemming
> >
> >
> > >
> > >
> > > Brian
> > >
> > > > -----Original Message-----
> > > > From: Flemming Andreasen [mailto:[email-masked]]
> > > > Sent: Tuesday, August 29, 2000 6:38 PM
> > > > To: Rosen, Brian
> > > > Cc: [email-masked]
> > > > Subject: Re: Supplying only a port on a ServiceChangeAddress
> > > >
> > > >
> > > >
> > > >
> > > > "Rosen, Brian" wrote:
> > > >
> > > > > Suppose all you want to specify in a ServiceChangeAddress
> > > > is a port number
> > > > > that is, the IP address doesn't change, but the port does.
> > > > >
> > > > > The ABNF sez:
> > > > > serviceChangeAddress = ServiceChangeAddressToken EQUAL VALUE
> > > > >
> > > > > This is because it could be IP, ATM, FR, MPLS....
> > > > >
> > > > > The example shows just a port number.
> > > >
> > > > Actually, I thought that's all that would be allowed in the
> > > > case of IP. If
> > > > not, how can it be within the "context of the association
> > > > currently being
> > > > negotiated", and how would it then relate to ServiceChangeMgcId ?
> > > >
> > > > -- Flemming
> > > >
> > > > >
> > > > >
> > > > > Should that be legal?  Should you have to specify the IP address
> > > > > as x.x.x.x:p?
> > > > >
> > > > > Brian
> > > >
> > > > --
> > > > Flemming Andreasen
> > > > Cisco Systems
> > > >
> > > >
> >
> > --
> > Flemming Andreasen
> > Cisco Systems
> >
> >

---

From: "Rosen, Brian" <[email-masked]>
Date: Tue, 5 Sep 2000 14:57:30 -0400

The question I'm still left with is how you would actually
achieve less overhead, given that the MG has to take the
transport connection down, and the MGC has to watch that happen.

I suspect that there is MORE work for the MGC to do that,
rather than just tell the MG to create a new association.
Remember that there is virtually no state that could be saved
from the first ServiceChange, so that starting over is
pretty low cost.

The real cost is the MG sending another ServiceChange and the
MG replying -- that's dirt cheap.  The cost of keeping the
association, but changing the transport connection, seems
more work to me. I'll admit that with UDP, that cost is
close to zero also -- it's TCP (and SCTP) that has real cost.

Brian
-----Original Message-----
From: Tom-PT Taylor [mailto:[email-masked]]
Sent: Tuesday, September 05, 2000 2:38 PM
To: [email-masked]
Subject: Re: Supplying only a port on a ServiceChangeAddress

As I noted in one or two previous messages, ServiceChangeMgcId has higher
overhead than ServiceChangeAddress in that it implies a new control session.
That is, the MG has to send a ServiceChange to the new address before it can
send anything else.
> From: Flemming Andreasen [mailto:[email-masked]]
> Sent: Tuesday, September 05, 2000 11:29 AM
> To: [email-masked]
> Let's take a step back here and ask ourselves what we are
> trying to achieve:
>
> 1. We have a need to identify the entity we wish to communicate with
> 2. We have a need to communicate with that entity.
>
> This is a classical naming issue that doesn't need to become overly
> complicated. In order to get from the name in 1 to the
> address (or route) in
> 2, you need to perform name resolution in the cases where the
> name itself is
> not an address. For domain names, this name resolution is
> achieved by DNS,
> for IP-addresses, it should normally be a NOP. By having both
> ServiceChangeMGGId and ServiceChangeAddress, you are
> effectively providing
> an alternate name resolution mechanism which overrides DNS
> and allows one
> IP-address to map to another. We should not be doing that,
> and I also note
> that this was probably not the authors' intent, since
> ServiceChangeAddress
> and ServiceChangeMGCId are not both allowed in a single command.
>
> That still leaves open the question of exactly what
> ServiceChangeAddress
> then is, and I believe Brian answered that earlier with his
> two proposals.
> In a perfect world, I would prefer getting rid of
> ServiceChangeAddress, but
> we may be beyond that. Does it make sense to allow just a
> port number then ?
> Considering that we already allow for port in mId, port is
> part of the name
> and for the same reasons as we shouldn't map one IP-address
> to another, we
> shouldn't map one port to another either IMO. If the MGC (or
> MG) wants the
> other party to talk to it on another port, it simply sends
> back another
> ServiceChangeMGCId with that port number in it.
>
> -- Flemming
>
>
>
> "Rosen, Brian" wrote:
>
> > It depends on what you want to have happen.
> >
> > If you want the MG, on receipt of a reply with a
> ServiceChangeAddress,
> > to tear down it's current transport connection, create a new one,
> > and stand by for messages from the MGC, then I suppose you would be
> > correct.
> >
> > If it was TCP (and I guess SCTP), this is pretty weird, because the
> > MG established a full duplex connection, but the next message is
> > almost certainly from the MGC.  The MGC is going to have to
> watch for
> > this carefully, and not send messages until the new channel is up.
> >
> > Or, the MGC can just use ServiceChangeMid.  The MG will respond by
> > tearing down the transport, establishing a new one, and sending
> > a new ServiceChange.  The MGC "fires and forgets" -- the new
> > ServiceChange, at the "new" address, looks like a complete
> new start.
> >
> > Brian
> >
> > From: Christian Groves
> > To: [email-masked]
> > Sent: 9/3/00 7:38 PM
> > > If you used ServiceChangeMid, it would.  The end result
> would be the
> > same.
> > >
> > > We can:
> > > > > > negotiated", and how would it then relate to
> ServiceChangeMgcId
> > ?
> > > > > >
> > > > > > -- Flemming
> > > > > >
> > > > > > >
> > > > > > >

---

From: Tom-PT Taylor <[email-masked]>
Date: Tue, 5 Sep 2000 15:07:43 -0400

You accept the principle that ServiceChangeMgcId implies a new control
session.  All else is implementation :-)

Mind, as I see it, ServiceChangeMgcId implies the same burden at the
transport level as ServiceChangeAddress, PLUS the application-level
ServiceChange transaction.

> From: Rosen, Brian [mailto:[email-masked]]
> Sent: Tuesday, September 05, 2000 2:58 PM
> To: Taylor, Tom-PT [NORSE:B901:EXCH];
> [email-masked]
> Subject: RE: Supplying only a port on a ServiceChangeAddress
>
>
> > > > > > > > Should that be legal?  Should you have to
> specify the IP
> > > address
> > > > > > > > as x.x.x.x:p?
> > > > > > > >
> > > > > > > > Brian
> > > > > > >
> > > > > > > --
> > > > > > > Flemming Andreasen
> > > > > > > Cisco Systems
> > > > > > >
> > > > > > >
> > > > >
> > > > > --
> > > > > Flemming Andreasen
> > > > > Cisco Systems
> > > > >
> > > > >
> >
> > --
> > Flemming Andreasen
> > Cisco Systems
> >
>

---

From: "Rosen, Brian" <[email-masked]>
Date: Tue, 5 Sep 2000 15:14:27 -0400

>You accept the principle that ServiceChangeMgcId implies a new
>control session.  All else is implementation :-)
Sure, I'm arguing that establishing a new control session is
low cost, and maintaining the current one is more expensive at
the MGC, and it doesn't matter much either way for the MG.

>Mind, as I see it, ServiceChangeMgcId implies the same burden
>at the transport level as ServiceChangeAddress, PLUS the
>application-level ServiceChange transaction.
No matter what, the MG has to tear down the transport connection
It's what the MGC has to do.

If it tries to maintain the current association, it has to keep
track of the change in transport connections, holding off any
messages until the MG has the new transport up, and then,
without the MG sending something, it sends a message (probably
Audit) to the MG on the new transport.

I think it's much easier to punt the current control association
and have both start over again.

Brian

---

From: Tom-PT Taylor <[email-masked]>
Date: Tue, 5 Sep 2000 15:15:45 -0400

I think we agree that MId is just an identifier of a peer in a control
session.  I still ask myself why we defined it to be an address rather than
an arbitrary string.  I suspect we changed intentions since it first showed
up.

> Sent: Tuesday, September 05, 2000 3:12 PM
> Bharat Kaul wrote:
> > Hi Flemming, Brian and List,
> >
> >   ServiceChangeMGCId should be kept for contacting a new
> MGC or rather
> > establishing new control Session.
> >
> > ServiceChangeAddress is for redirection within a MGC e.g.
> MG contacts MGC at
> > a default port and based on some policy MGC wants to assign
> MG to a specific
> > port, it should send ServiceChangeAddress specifying the
> port.These two
> > semantics seem clear and fair enough.
>
> I quite frankly don't understand the need for having port as
> an identifier and
> then being able to specify another port to override it, while
> keeping the
> identifier port the same.
>
>
> >
> >
> > Port in MID should be just a tool to identify an entity
> uniquely, with one
> > requirement that MID for a control session is consistent between two
> > entities.
>
> In that case it should be called something different than a
> port, or at least be
> treated as something different.
>
> -- Flemming
>
>
> >
> >
> > - Bharat
> >
> > Sent: Tuesday, September 05, 2000 8:29 AM
> > 2, you need to perform name resolution in the cases where
> the name itself is
> > shouldn't map one port to another either IMO. If the MGC
> (or MG) wants the
> > > almost certainly from the MGC.  The MGC is going to have
> to watch for
> > > ServiceChange, at the "new" address, looks like a
> complete new start.
> > >
> > > Brian
> > >

---

From: Bharat Kaul <[email-masked]>
Date: Tue, 5 Sep 2000 12:31:44 -0700

It could be arbitrary string and then we have to come up with algorithms to
keep those strings unique. domain_name/IPAddress [port] provides a way to do
that. So, we can treat MID just as an identifier of the source entity and
not attach with transport connection details.

The reasoning seems to be to keep MID and (ServiceChangeAddress or
ServiceChangeMgcId) as same or rather not have two separate things. But I
think these two might actually gives us the flexibility. On MGC side, MID
could be a global identifier for that MGC whereas it uses either
(ServiceChangeAddress or ServiceChangeMgcId) as a means to redirect. It
enables MID for that MGC to remain constant across all MGs and not per MG.

On MG side, for virtual MG implementations, ServiceChangeAddress is a
convenient way of request a MGC to communicate at a specific port with the
MG. Although same can be achieved with ServiceChangeMgcId (we will have to
name it as something else then).

However, I agree with Brian that using ServiceChangeMgcId instead of address
is more convenient for TCP and SCTP and has no impact on UDP.
ServiceChangeAddress does have extra complications to be managed.

While we are at sorting transport issues, I would like to have one issue
clarified. Does MGC ever initiate TCP/SCTP connections ? So far the
reasoning and conclusions on the mailing list gave me the impression that MG
always initiates connections and MGC never does.
I have always heard "it would be pretty unusual/unlikely to specify
ServiceChangeAddress by an MG for a TCP transport". I agree with and would
like the implementors guide to rule out this option.

Clarifying this would put to rest what can be specified in
ServiceChangeAddress or ServiceChangeMgcId with what transport.

- Bharat

---

From: Tom-PT Taylor <[email-masked]>
Date: Tue, 5 Sep 2000 14:30:44 -0500

Actually, we should bear in mind that there are actually two different
control streams operating within any session: MGC-initiated requests and the
responses to them, and MG-initiated requests and the responses to them.  The
MG has to send its responses back to the address from which the MGC sent its
requests.  ServiceChangeAddress only affects where the MG/MGC sends its
requests.  Theoretically either end can change its point of origin for the
requests it sends at any time without the need for a ServiceChange -- the
latter only controls where those requests get sent to.  It's going to take
interoperability agreements or profiles to curb this.

> From: Rosen, Brian [mailto:[email-masked]]
> Sent: Tuesday, September 05, 2000 3:14 PM

---

From: Tom-PT Taylor <[email-masked]>
Date: Wed, 6 Sep 2000 12:59:47 -0500

OK, I'd say we have consensus on the following:

(1) As oft repeated, the mId designates a peer in a control session.  It
does not change even if the addresses used in the session change.  Different
port addresses could be used to designate different virtual MGs, but this is
a local implementation issue.

(2) ServiceChangeAddress can be used to change the address to which the peer
sends requests within the existing control session.  The ABNF syntax of
ServiceChangeAddress is VALUE, which permits designation of a port only
within a quoted string.  The difference between this and the ASN.1 syntax is
what started this whole thread, but is irrelevant because the functionality
is still available.  There is the legitimate question of whether the
ServiceChangeAddress functionality is needed.  I'm not sure I have consensus
to deprecate use of ServiceChangeAddress.

(3) ServiceChangeMGgcId is used to redirect the control session.  The ABNF
type of ServiceChangeMgcId is MId, which presumably is why MId is so
carefully developed as an address.

There is an open issue regarding TCP.  That is, is everyone prepared to
accept the restriction Bharat wants to place on TCP, to the effect that the
MG is never a listener?

> Sent: Wednesday, September 06, 2000 10:39 AM
> To: Rosen, Brian; Taylor, Tom-PT [NORSE:B901:EXCH]; Bharat Kaul
> So do we have any consensus resolution on this issue ?
>
> -- Flemming
>
> "Rosen, Brian" wrote:
>
> > Yeah, the mId started life as the thing in the header that let an
> > MGC know which entity it was talking to.  It's always been an
> > address though - desirable as an FQDN and acceptable to be a hard
> > address.
> >
> > The intention of ServiceChangeMid was to be the referral
> address for an
> > association that was not acceptable to the MGC.
> ServiceChangeAddress used
> > to be port, and it was just for changing port numbers, not
> addresses.  We
> > went downhill (IMO) from there.
> >
> > I'm with Flemming, one thing is all we need, but we are
> stuck with 2 for
> > now.
> >
> > Brian
> >
> > > Sent: Tuesday, September 05, 2000 3:16 PM
> > > > > > > > ServiceChangeMgcId (which may itself contain an
> address or
> > > > > > indirectly

---

From: "Rosen, Brian" <[email-masked]>
Date: Wed, 6 Sep 2000 14:16:19 -0400

One more thing:
>The ABNF syntax of ServiceChangeAddress is VALUE, which permits
>designation of a port only within a quoted string.  The
>difference between this and the ASN.1 syntax is what started this
>whole thread, but is irrelevant because the functionality is
>still available.

Value allows 1*(SafeChar), which would permit a port number (no
punctuation).  One system did exactly that at the Interop event.  Either we
have to allow that, or explicitly disallow it.

Brian

---

From: Bharat Kaul <[email-masked]>
Date: Wed, 6 Sep 2000 15:33:50 -0700

I also agree with what seems to be the evolving consensus.

However, we might to have evaluate the choice of IP Address being present as
part of ServiceChangeAddress more carefully before disallowing it.

The case in point being an entity wanting to redirect the conversation on a
particular interface and a port or current interface and a particular port.
For first case, we need to allow presence of IP Address. For second case, we
are fine with port. So effectively, it boils down to using
ServiceChangeMgcId.
It might be  a requirement that MG  receiving the parameter  knows exactly
that it has been asked to communicate on other interface with the same MGC
and hasn't been redirected to a altogether new MGC otherwise the MG might
interpret them as two separate entities which is not a correct picture.

Any comments on  this ?

- Bharat

-----Original Message-----
From: Rosen, Brian [mailto:[email-masked]]
Sent: Wednesday, September 06, 2000 11:12 AM
To: 'Tom-PT Taylor'; 'Flemming Andreasen'; Bharat Kaul
Cc: [email-masked]
Subject: RE: Supplying only a port on a ServiceChangeAddress

I'm assuming here that you mean mId, the thing that goes in every message,
and that there is no arbitrary changing of it - changes get signalled in
ServiceChange.  mId serves to identify which association this message refers
to.  Given those caveats, I agree.

I'd like to see if we could develop a consensus, but I can live with it.

I'm still concerned about the difficulty of changing address, or port, with
TCP transport.  We need at least a note of caution in the Implementers
Guide.

Yes!

Yes!

Brian

> From: Flemming Andreasen [ mailto:[email-masked]
<mailto:[email-masked]> ]
> > > From: Tom-PT Taylor [ mailto:[email-masked]
<mailto:[email-masked]> ]
> > > > From: Flemming Andreasen [ mailto:[email-masked]
<mailto:[email-masked]> ]
> > > > > From: Flemming Andreasen [ mailto:[email-masked]
<mailto:[email-masked]> ]
> > > > > > > > From: Flemming Andreasen [ mailto:[email-masked]
<mailto:[email-masked]> ]
> > > > > > > > > > From: Flemming Andreasen [ mailto:[email-masked]
<mailto:[email-masked]> ]

---

From: Bharat Kaul <[email-masked]>
Date: Wed, 6 Sep 2000 17:14:02 -0700

I am thinking about issues involved, if any. It is food for thought :)

-----Original Message-----
From: Tom-PT Taylor [mailto:[email-masked]]
Sent: Wednesday, September 06, 2000 4:04 PM
To: 'Bharat Kaul'; 'Rosen, Brian'; 'Flemming Andreasen'
Cc: [email-masked]
Subject: RE: Supplying only a port on a ServiceChangeAddress

Does it really matter whether the MG knows that it is talking to the same or
a new entity?

-----Original Message-----
From: Bharat Kaul [mailto:[email-masked]]
Sent: Wednesday, September 06, 2000 6:34 PM
To: 'Rosen, Brian'; Taylor, Tom-PT [NORSE:B901:EXCH]; 'Flemming Andreasen';
Bharat Kaul

Any comments on  this ?

- Bharat

-----Original Message-----
From: Rosen, Brian [mailto:[email-masked]]
Sent: Wednesday, September 06, 2000 11:12 AM
To: 'Tom-PT Taylor'; 'Flemming Andreasen'; Bharat Kaul
Cc: [email-masked]
Subject: RE: Supplying only a port on a ServiceChangeAddress

Yes!

Yes!

Brian

---

From: "Rosen, Brian" <[email-masked]>
Date: Thu, 7 Sep 2000 09:12:31 -0400

NO!!!! The MG doesn't care at all.

-----Original Message-----
From: Bharat Kaul [mailto:[email-masked]]
Sent: Wednesday, September 06, 2000 6:34 PM
To: 'Rosen, Brian'; Taylor, Tom-PT [NORSE:B901:EXCH]; 'Flemming Andreasen';
Bharat Kaul

Any comments on  this ?

- Bharat

-----Original Message-----
From: Rosen, Brian [mailto:[email-masked]]
Sent: Wednesday, September 06, 2000 11:12 AM
To: 'Tom-PT Taylor'; 'Flemming Andreasen'; Bharat Kaul
Cc: [email-masked]
Subject: RE: Supplying only a port on a ServiceChangeAddress

Yes!

Yes!

Brian

---

From: Tom-PT Taylor <[email-masked]>
Date: Thu, 7 Sep 2000 10:49:00 -0400

Brian, you've got directions reversed, I think.  If the MG sends a
ServiceChangeAddress, then the MGC is being told to send its requests to
that address.  The MGC is the one that has to establish the transport
connection (if required), because the MGC is the one that knows what source
address it wants to use.  Beyond this, the MGC knows that the MG is ready
because it has established its new connection or (for UDP) simply because
the MG wouldn't have asked for the change if it wasn't ready to handle it.

Now consider the case where the MGC has sent the MG a ServiceChangeAddress.
Here it is telling the MG where to send new requests.  The MG is responsible
for setting up the transport connection, and knows when it can start sending
as a result.

You never have a situation where one end has to wait for the other to set up
a transport connection before it can send messages.

-----Original Message-----
From: Rosen, Brian [mailto:[email-masked]]
Sent: Thursday, September 07, 2000 9:11 AM
To: 'Bharat Kaul'; Taylor, Tom-PT [NORSE:B901:EXCH]; 'Flemming Andreasen'
Cc: [email-masked]
Subject: RE: Supplying only a port on a ServiceChangeAddress

I'm still stuck on how you expect this to work if you don't abandon the
current
control association and start a new one.  Whether you change addresses,
or even if you change ports, the MGC has to wait until the new transport is
established, and then send the first message on the transport established by
the MG.  This is unlike any mechanism I know of.  In all cases that I've
seen,
the first message on a new port/address comes from the entity establishing
the transport.

For UDP it's not all that hard EXCEPT that you have no idea when to send a
message - how do you know that the MG is listening on the port?  You asked
him
to change, and you get no packets telling you  he did it.

For TCP it's at least possible if you get into the TCP machinery, because
you can
see the TCP connection state on the new port being established.  However,
the
MGC has to watch this, and after it's established, then send it's first
message,
again before it gets any messages from the MG.

The other way, using ServiceChangeMgcId, you reply with the new port,
clear your state, and sit back.  You will get a new ServiceChange on the
correct
port.  Much easier.

Brian

-----Original Message-----
From: Bharat Kaul [mailto:[email-masked]]
Sent: Wednesday, September 06, 2000 6:34 PM
To: Rosen, Brian; 'Tom-PT Taylor'; 'Flemming Andreasen'; Bharat Kaul
Cc: [email-masked]
Subject: RE: Supplying only a port on a ServiceChangeAddress

Any comments on  this ?

- Bharat

-----Original Message-----
From: Rosen, Brian [mailto:[email-masked]]
Sent: Wednesday, September 06, 2000 11:12 AM
To: 'Tom-PT Taylor'; 'Flemming Andreasen'; Bharat Kaul
Cc: [email-masked]
Subject: RE: Supplying only a port on a ServiceChangeAddress

Yes!

Yes!

Brian

---

From: "Rosen, Brian" <[email-masked]>
Date: Thu, 7 Sep 2000 13:47:57 -0400

No, no, no.  The MGC never EVER sets up a transport connection.  The MG
always does this.  Remember: the MG does not have a TCP server, only a
client.
So it's always the MG that sets up the TCP connection.  With TCP you get
a full duplex channel, right?

I understand that with UDP, there is no "connection", so this isn't really
much
of an issue except for the timing weirdness.  It did occur to me that I did
make
an incorrect assumption on UDP - the MG could be listening on the new port
before it sent the ServiceChangeAddress, so the MGC can go ahead and send
the next command without any further ado.

There are two variables and four resulting circumstances where this can
occur.
I think 1.5 of them work.

The variables are who sends ServiceChange command, and who sends
ServiceChangeAddress.

When the MG sends ServiceChange command, and it sends ServiceChangeAddress,
you have a nonsense situation.  It's saying "send the reply to this command
at the
address I sent it from, send further commands to a new address".  The
problem
exists, because the MGC replies to the command at the old address, but then
has to wait until the MG creates the new transport to send the next command.

When the MG sends the ServiceChange command, but the MGC sets
ServiceChangeAddress, this is a "normal" case of something like a pooled
MGC,
or multiple network interfaces.  The same situation exists; the MGC has to
wait until
the MG sets up the new transport before sending the next command.

When the MGC sends the ServiceChange, and it sets the ServiceChangeAddress,
this is the normal handoff.  Here, things work, because the MG replies to
the old
address, tears down the transport and then SENDS A NEW SERVICECHANGE
command.  This is the way I want all of the cases to work, but it's the way
it
is already defined for this case.

The last case is truly warped.  The MGC sends a ServiceChange, and the MG
replies with a new address.  Sort of "well, while we are changing things,
why
don't we change my address".  If the ServiceChange the MG sent is handoff,
(which implies the MGC also set ServiceChangeAddress), everything is fine.
The MG replies to the old address, and then sets up the transport and sends
a
new ServiceChange command.  If the MGC just did something else, then we are
back in the state where the MGC has to wait for the new transport to be set
up
by the MG before it can send a new command.

Brian

-----Original Message-----
From: Rosen, Brian [mailto:[email-masked]]
Sent: Thursday, September 07, 2000 9:11 AM
To: 'Bharat Kaul'; Taylor, Tom-PT [NORSE:B901:EXCH]; 'Flemming Andreasen'
Cc: [email-masked]
Subject: RE: Supplying only a port on a ServiceChangeAddress

Brian

-----Original Message-----
From: Bharat Kaul [mailto:[email-masked]]
Sent: Wednesday, September 06, 2000 6:34 PM
To: Rosen, Brian; 'Tom-PT Taylor'; 'Flemming Andreasen'; Bharat Kaul
Cc: [email-masked]
Subject: RE: Supplying only a port on a ServiceChangeAddress

Any comments on  this ?

- Bharat

-----Original Message-----
From: Rosen, Brian [mailto:[email-masked]]
Sent: Wednesday, September 06, 2000 11:12 AM
To: 'Tom-PT Taylor'; 'Flemming Andreasen'; Bharat Kaul
Cc: [email-masked]
Subject: RE: Supplying only a port on a ServiceChangeAddress

Yes!

Yes!

Brian

---

From: "Rosen, Brian" <[email-masked]>
Date: Thu, 7 Sep 2000 16:22:55 -0400

We agreed that the MG need not have a TCP server, only a client.  If that is
true, then an MGC can never set up a transport connection.

Brian

-----Original Message-----
From: Tom-PT Taylor [mailto:[email-masked]]
Sent: Thursday, September 07, 2000 3:36 PM
To: Rosen, Brian; 'Bharat Kaul'; 'Flemming Andreasen'
Cc: [email-masked]
Subject: RE: Supplying only a port on a ServiceChangeAddress

I'm sorry, Brian, nothing in the current spec. requires that the MG always
be the entity that sets up the transport connection -- only that it indicate
its preferred transport by being the first to initiate a control
association.  I've indicated at least a couple of ways in which the MGC
could be the initiator -- if directed by the MG (through inclusion of the
ServiceChangeAddress parameter) or if it decides to change its source
address  The MG can prevent the first case by not ever passing a
ServiceChangeAddress.  I expect it would be fairly easy to get a consensus
that the MGC cannot arbitrarily shift its source for commands, but must
instead issue a ServiceChange with ServiceChangeAddress or
ServiceChangeMgcId so that the MG ends up controlling the shift.

 -----Original Message-----
From: Rosen, Brian [mailto:[email-masked]]
Sent: Thursday, September 07, 2000 1:48 PM
To: Taylor, Tom-PT [NORSE:B901:EXCH]; 'Bharat Kaul'; 'Flemming Andreasen'
Cc: [email-masked]
Subject: RE: Supplying only a port on a ServiceChangeAddress

Brian

---

From: Matt Holdrege <[email-masked]>
Date: Thu, 7 Sep 2000 13:30:57 -0700

Never say never. It's preferred due to the low-end clients, but MGC
implementations can certainly contact MG's that do support incoming
connections.

Yes I know this can make things more complicated as a standard, but there
are real world reasons for initiating from an MGC so it will happen
regardless.

I don't think this is an issue when using SCTP in any case, right?

At 04:22 PM 9/7/00 -0400, Rosen, Brian wrote:
>>I'm sorry, Brian, nothing in the current spec. requires that the MG
>>always be the entity that sets up the transport connection -- only that
>>it indicate its preferred transport by being the first to initiate a
>>control association.  I've indicated at least a couple of ways in which
>>the MGC could be the initiator -- if directed by the MG (through
>>inclusion of the ServiceChangeAddress parameter) or if it decides to
>>change its source address  The MG can prevent the first case by not ever
>>passing a ServiceChangeAddress.  I expect it would be fairly easy to get
>>a consensus that the MGC cannot arbitrarily shift its source for
>>commands, but must instead issue a ServiceChange with
>>ServiceChangeAddress or ServiceChangeMgcId so that the MG ends up
>>controlling the shift.
>>
>>>I understand that with UDP, there is no "connection", so this isn't
>>>really much
>>>of an issue except for the timing weirdness.  It did occur to me that I
>>>did make
>>>you have a nonsense situation.  It's saying "send the reply to this
>>>command at the
>>>ServiceChangeAddress, this is a "normal" case of something like a pooled MGC,
>>>or multiple network interfaces.  The same situation exists; the MGC has
>>>to wait until
>>>this is the normal handoff.  Here, things work, because the MG replies
>>>to the old
>>>command.  This is the way I want all of the cases to work, but it's the
>>>way it
>>>replies with a new address.  Sort of "well, while we are changing
>>>things, why
>>>The MG replies to the old address, and then sets up the transport and
>>>sends a
>>>back in the state where the MGC has to wait for the new transport to be
>>>set up

---

From: "Rosen, Brian" <[email-masked]>
Date: Thu, 7 Sep 2000 16:44:25 -0400

Why?

There is very low overhead in re-establishing a control relationship instead
of changing an address.  If you need to,
you can even save the state in the MGC and not have to audit.
If you always, uniformly, without exception, change addresses
by forcing a ServiceChange exchange:
        The MG is simpler
        The MGC is not adversely affected
        The text is simpler

This is a Good Thing (tm).

I'm not suggesting that we not allow an MGC to initiate
a change of address.  I'm suggesting that when it does, the
uniform response of the MG is to break the connection, create a new one, and
send ServiceChange to the new address.

You aren't suggesting that we allow the MGC to INITIATE a control session
are you?  The text does not support that.

With SCTP, you don't have a client server issue, but you do have a full
duplex connection.  If one end changes the path (is that really what I want
to say?), as opposed to changing one or more transport addresses, then I
think you want to classify that as a change of control association and force
the MG to send ServiceChange.

Brian

> From: Matt Holdrege [mailto:[email-masked]]
> Sent: Thursday, September 07, 2000 4:31 PM
> To: Rosen, Brian

---

From: Tom-PT Taylor <[email-masked]>
Date: Thu, 7 Sep 2000 16:50:22 -0400

Everyone who responded agreed.  I'm waiting for a view from the MGC side of
things.

-----Original Message-----
From: Rosen, Brian [mailto:[email-masked]]
Sent: Thursday, September 07, 2000 4:23 PM
To: Taylor, Tom-PT [NORSE:B901:EXCH]; 'Bharat Kaul'; 'Flemming Andreasen'
Cc: [email-masked]
Subject: RE: Supplying only a port on a ServiceChangeAddress

Brian

 -----Original Message-----
From: Rosen, Brian [mailto:[email-masked]]
Sent: Thursday, September 07, 2000 1:48 PM
To: Taylor, Tom-PT [NORSE:B901:EXCH]; 'Bharat Kaul'; 'Flemming Andreasen'
Cc: [email-masked]
Subject: RE: Supplying only a port on a ServiceChangeAddress

Brian

---

From: Tom-PT Taylor <[email-masked]>
Date: Thu, 7 Sep 2000 15:36:07 -0400

-----Original Message-----
From: Rosen, Brian [mailto:[email-masked]]
Sent: Thursday, September 07, 2000 1:48 PM
To: Taylor, Tom-PT [NORSE:B901:EXCH]; 'Bharat Kaul'; 'Flemming Andreasen'
Cc: [email-masked]
Subject: RE: Supplying only a port on a ServiceChangeAddress

Brian

---

From: Tom-PT Taylor <[email-masked]>
Date: Wed, 13 Sep 2000 18:42:58 -0400

That seems reasonable.

> Sent: Wednesday, September 13, 2000 9:53 AM
> Flemming and I favor (a).
>
> Given the state of things, what I would like to propose is:
> 1) The implementation guide state that use of
> ServiceChangeAddress is not
> encouraged
> 2) State in the implementation guide that MGCs must be able
> to cope with
> ServiceChangeAddress with either a full address or just a port number.
>
> Brian
>
> > Sent: Wednesday, September 06, 2000 3:40 PM
> > OK, we have three choices:
> > (a) deprecate use of ServiceChangeAddress in favour of
> > ServiceChangeMgcId
> > (and assume it is never used by the MG)
> > (b) allow specification of port only, with the parser able to
> > distinguish
> > from other forms because of the lack of punctuation (seems feasible)
> > (c) require that the full address be specified.
> >
> > (b) is basically the current situation, with a note in the
> > Implementor's
> > Guide to warn that the contents may consist of a bare port
> number and
> > specifying that in that case the IP address to be used is the
> > same as the
> > address to which the receiver of the ServiceChangeAddress
> is currently
> > sending its requests.
> >
> > > Sent: Wednesday, September 06, 2000 2:16 PM
> > > To: Taylor, Tom-PT [NORSE:B901:EXCH]; 'Flemming Andreasen';
> > > Bharat Kaul