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
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.