Re: IPCP option for SIP server

And of course, we should all remember that the only issue of official  
concern to this audience is, "Is a protocol change necessary?"  The  
answer has already been established: No.  DHCP is the perfect  
solution for this problem.

Karl

On Nov 23, 2005, at 9:07 AM, James Carlson wrote:
> 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