Subject: Re: TCP/IP ports

From: "Rosen, Brian" <[email-masked]>
Date: Thu, 23 Dec 1999 11:29:17 -0500

Are we running in circles?  You get a TCP port from the Service Change.  If
the
entity wants to use multiple ports, it would specify the port to use.  So
you contact
at a common point, it gives you a "private" port.  That is there now.  Do we
need
something else?

Brian

> -----Original Message-----
> From: Matt Holdrege [mailto:[email-masked]]
> Sent: Thursday, December 23, 1999 11:21 AM
> To: [email-masked]
> Subject: Re: TCP/IP ports
>
>
> 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.
>
>
> At 09:54 AM 12/23/99 -0500, Michael A. Ramalho wrote:
> >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: Nachum Frid <[email-masked]>
Date: Thu, 23 Dec 1999 20:29:58 +0200

For big gateways with hundreds of terminations, single TCP/IP link between
GW and GWC probably will introduce inaccessible delays specially for noisy
IP network. Using multiple TCP/IP links will enable to overcome these
delays. Packet losses and retransmissions in one TCP link will not effect
the other links. Links can be allocated for every context  or even for every
termination ID.   For each such TCP link two ports  need to be allocated,
one in a media Gateway and second in the Gateway controller. I can't see how
this can be achieved in Service Change command.

> [mailto:[email-masked]]On Behalf Of Rosen, Brian
> Sent: Thursday, December 23, 1999 6:29 PM