Subject: Re: [Fwd: FW: Application for port-number]

From: Tom-PT Taylor <[email-masked]>
Date: Wed, 19 Jan 2000 07:53:59 -0500

> -----Original Message-----
> From: Pekka Pessi [SMTP:[email-masked]]
> Sent: Wednesday, January 19, 2000 5:16 AM
> To:   Taylor, Tom-PT [CAR:B904:EXCH]
> Cc:   [email-masked]
> Subject:      Re: [Fwd: FW: Application for port-number]
>
> Tom-PT Taylor <[email-masked]> writes:
> >To start with, there's a difference between TCP and UDP.  In TCP, once
> >someone has connected to a TCP, no one else can.
>
>       I don't understand.
        [[TomT]]
        Sorry -- wasn't thinking.  This is a wrong statement.  The reason
the MGC might want to move the MG away from the contact port is more a
matter of process relationships at the implementation level.
>
> >Hence the MGC has to tell
> >the MG to back off and use another.  When the MG does that, the MG end of
> >the connection is fixed, just as it was the first time, so there's no
> point
> >in the MG passing a contact address to the MGC.
>
>       Agreed.
>
> >With UDP, the MGC has the option of providing an alternate port or not,
> >depending on implementation: the option is there for everyone to use the
> >same port.  Moreover, the MGC has to know where to send the reply to the
> MG,
> >since it's not pre-determined, so the MG-supplied address and port do
> have
> >an use.
>
>       I agree with Brian. MGC can send all further messages back to the
>       same IP address/port that was used to send the service change
>       request. There is absolutely no need to specify a port number in
>       ServiceChange.
        [[TomT]]
        OK.

>       I propose that we zap the following text:
>
> >The ServiceChange command contains a ServiceChangeAddress parameter.  If
> TCP
> >is used, the MG need not include this parameter, since it is implicit in
> the
> >TCP connection set up between the MG and the MGC.  The MGC will typically
> include this parameter in order to tell the MG to move to a new port.
>
>       Replace it with text as follows.
>
> The ServiceChange command or response may contain a ServiceChangeAddress
> parameter.  The MGC can include this parameter in order to tell the MG to
> move to another MGC.
>
>       Also, the last paragraph should be zapped:
>
> >If UDP/ALF is used, the ServiceChange Command from the MG must contain
> the
> >ServiceChangeAddress parameter, so that the MGC knows where to send its
> >messages.  The MGC may include this parameter in its response, if it
> wishes
> >to change the address and/or port to which the MG sends messages during
> the
> >life of the association."
>
>                                       Pekka
>
> >> -----Original Message-----
> >> From: Rosen, Brian [SMTP:[email-masked]]
> >> Sent: Friday, January 14, 2000 3:02 PM
> >> To:   'Chuong Nguyen'
> >> Cc:   Taylor, Tom-PT [CAR:B904:EXCH]
> >> Subject:      RE: [Fwd: FW: Application for port-number]
>
> >> I had a long winded answer here, then went and talked to some of my
> >> people, and now I
> >> think I am thoroughly confused.
>
> >> So I'm going to ask the "question first principals" question - why do
> we
> >> need any of this?
>
> >> There is exactly one control association between an MG and an MGC.  The
> MG
> >> is the client,
> >> and it initiates the association.  Therefore this circumstance is
> exactly
> >> analogous to
> >> the control channel of FTP, or of TELNET, etc.  The MG sends its source
> >> address and
> >> desired port in the TCP SYN, addressed to the MGC at the well known
> port.
> >> The MGC
> >> replies with its source address and the well known port, and the MG's
> >> address and its
> >> desired port.  Rules state that flows are differentiated by the 4-tuple
> >> (Source Address,
> >> Source Port, Destination Address, Destination Port), so why do we need
> a
> >> port number
> >> in the protocol?   Same effect with UDP, right?
>
> >> And, as I understand it, putting port numbers in protocol messages
> screws
> >> up NAT and
> >> firewalls.
>
> >> Even if there were reasons why it looked like you needed multiple
> >> associations (the Virtual MG for example), the MG must use separate
> port
> >> numbers, and the tuple remains unique.  The MGC
> >> never initiates the connection, so there isn't a problem there.
>
> >> So, why are we doing this?