Re: IPCP option for SIP server

James,

       Your points are well taken and I have really enjoyed having a
       good technical discussion on this topic here. I realize DHCP
       can do the trick over PPP link to get the server address
       configuration parameters.

       Just to reiterate, there are cases where each PDSN may have a
       different outbound proxy associated with it. Thus as the mobile
       mobile moves between PDSNs within the same DNS domain or AAA
       domain , it may end up getting a new outbound proxy or P-CSCF
       (in IMS language) during each transition. The point I was
       trying to make was that timing associated with outbound proxy
       configuration should not be neglected and should be considered
       during any handover optimization. Of course there are many ways
       it can be done, such as make-before-break as you have
       indicated. I was hoping if it can as well be done during the
       PPP negotiation phase itself, but DHCP appears to be cleaner
       solution at the moment, albeit an extra pair of message
       exchange. 

Regards
Ashutosh


> Ashutosh Dutta writes:
> > James, I can think of some optimization issue such as follows:
> > 
> > By running DHCPclient on the mobile while the mobile is using CDMA2000
> > RAN, one  uses PPP to  obtain an IP  address and DHCPclient  to obtain
> > other server parameters  and one needs to run both  the daemons on the
> > client to get fully configured.
> 
> What "daemons?"  That's an implementation issue.
> 
> As for DHCP, we're talking about a single UDP packet exchange -- send,
> receive.  That's it; it's stateless.  One round trip time, and no
> "daemons" required.
> 
> > PPP has to happen and then DHCP. For a
> > rapidly moving client this may add to some optimization issue.
> 
> I think that's nonsense because it ignores the larger picture.
> 
> When you switch SIP servers, you lose whatever state you had with the
> previous server.  You likely need to redo computationally complex
> operations such as public key crypto to secure the new connection.
> That's probably the least of the worries.
> 
> However, this is IP.  IP doesn't care when links go up and down.
> There's no reason you can't switch PPP links and keep the *same* SIP
> server address over the transition.  Then, if you feel compelled to do
> so, issue a DHCPINFORM message when you have the time, and if the
> reply specifies a new SIP server address, switch.
> 
> You can do make-before-break and avoid any loss of service.
> 
> In addition to this, we're talking about a single round trip time.
> Unless that cell phone is just doing nothing at all, any activity it
> might do over IP dwarfs that one packet exchange.
> 
> Finally, if you're using a SIP server, the information you get back
> includes things such as host names and addresses of other systems to
> contact.  Again, the actual exchanges involved in even the lightest
> transaction there dwarf the time it takes to discover the SIP server
> address from a relatively local DHCP server.
> 
> So, I don't buy it.  I don't see how this is a worthwhile optimization
> in any case, and it seems quite obvious that it's not generally useful
> (nodes one or more hops away from the PPP link have no way to know
> what was negotiated) and hard to deploy.
> 
> > Thus if  the client is moving  between PDSNs this may  be bit overkill
> > but  may work  out  well if  the  same client  moves between  CDMA2000
> > network and WiFi for example.
> 
> The same issues exist there.  And, in fact, the implementation with
> DHCP alone is *much* simpler, because you don't have to deal with
> determining whether this new IPCP option (for the CDMA2000 link) or
> DHCP (on WiFi) is authoritative.  Just rely on the DHCP answer in any
> case.
> 
> -- 
> James Carlson, KISS Network                    <[email protected]>
> Sun Microsystems / 1 Network Drive         71.232W   Vox +1 781 442 2084
> MS UBUR02-212 / Burlington MA 01803-2757   42.496N   Fax +1 781 442 1677

Ashutosh 

_______________________________________________
Pppext mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/pppext