Re: IPCP option for SIP server
James Carlson <[email protected]>
| Newsgroups | gmane.ietf.pppext |
|---|---|
| Message-ID | <[email protected]> |
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 _______________________________________________ Pppext mailing list [email protected] https://www1.ietf.org/mailman/listinfo/pppext