Subject: Re: TCP/IP ports

From: "Michael A. Ramalho" <[email-masked]>
Date: Thu, 23 Dec 1999 09:54:30 -0500

Tom, et.al.,

Isn't this a network design issue?

The fact that a loss on a TCP connection causes problems
is not new. If you desire to get around some of the bad properties
by using multiple TCP connections .... then you have to
keep track of potential mis-orderings associated with a given
context (due to them being output on a different TCP sockets
and a burp on one of the sockets).

I do not think the solution to this is to put more "stuff" in the
base protocol.

If you want to do something like this, a stubb can be made
between megaco and the TCP sockets that "simply" puts
packets that need to be ordered (from a given context) on
the same TCP socket.

I say "simply" because nothing is in practice; you need to keep
track of things (such as detailed packet ordering histories) for
troublesome cases socket failover cases.

Cases like socket failover de-rail simple heuristics like assigning
a given context to a given ports (as below). TCP sockets take a
while to notice they are down and then take a while more to come
back up .... better to re-map the message to another existing
socket ... but then you have to keep track of potential
misordering! Life isn't simple.

If a network designer desires to implement the TRANSPORT
that way ... they can mandate the stubb ... thus defining the
transport.

(Or they can wait for sigtran/SCTP to be finished ... which, I am
told, is going rather well).

Don't we want to finalize the base protocol?

Michael Ramalho

At 08:38 AM 12/23/99 -0500, Tom-PT Taylor wrote:
>Hmm.  Perhaps we could add multi-port operation, with the behaviour that if
>a transaction is sent on that port, the reply must come back on that port.
>Let's think about whether we could define this as a package or whether it
>should be part of the base protocol.
>
>> -----Original Message-----
>> From: Nachum Frid [SMTP:[email-masked]]
>> Sent: Thursday, December 23, 1999 4:05 AM
>> To:   [email-masked]
>> Subject:      Re: TCP/IP ports
>>
>> Using  multiple TCP sockets for MEGACO protocol will decrease latency for
>> the control messages. In TCP/IP retransmission of single message will
>> delay the whole control link  if only single socket is used.
>>
>>       -----Original Message-----
>>       From: Media Gateway Control (megaco)
>> [mailto:[email-masked]]On Behalf Of Tom-PT Taylor
>>       Sent: Wednesday, December 22, 1999 7:42 PM
>>       To: [email-masked]
>>       Subject: Re: TCP/IP ports
>>
>>
>>
>>       The port is determined in the ServiceChange negotiation -- it will
>> be almost impossible to change on a per-call basis.
>>
>>       I have an idea for how to allocate multiple ports on a static basis,
>> allowing for graceful failover: define alternative addresses as a ROOT
>> property.  But this still doesn't provide a dynamic port negotiation
>> capability.  I'm not sure why you would want it.
>>
>>               -----Original Message-----
>>       From:   Nachum Frid [SMTP:[email-masked]]
>>       Sent:   Wednesday, December 22, 1999 12:15 PM
>>       To:     [email-masked]
>>       Subject:        TCP/IP ports
>>
>>
>>
>>                       The Megaco trasport can implement  either UDP or
>> TCP.   When using TCP  a single port is going to be used for transport of
>> transactions? ,  or may be its better  to use  multiple ports that will be
>> dynamically allocated for every new Context ?
>>
>>
>>
>

Michael A. Ramalho, Ph.D.
Cisco Systems
1802 Rue de la Port
Wall Township, NJ 07719-3784
Office email: [email-masked]
Personal email: [email-masked]
Office: +1.732.449.5762
Cell: +1.732.809.0188
Pager: +1.800.365.4578

---

From: Matt Holdrege <[email-masked]>
Date: Thu, 23 Dec 1999 08:21:03 -0800

Michael, I don't think this is a resiliency issue but a performance issue.
Think of it the same way as http. A web server may have thousands of TCP
associations with browsers, but they each have their own port. If they all
used the same port, the WWW wouldn't have been able to scale to where it is
today.

Keep in mind Tom's point about preservation of ports. That's a must.

And it seems obvious to me that this should be in the base protocol. As I
recall, scalability is a basic requirement of MEGACO.