Subject: RE: DNS discovery

From: <[email-masked]>
Date: Thu, 13 Nov 2003 17:48:50 +0200

>     teemu> I'd like to point out that any additional (round trip)
>     teemu> delay in configuration phase, especially in wireless
>     teemu> (cellular) environments, is _not_ user friendly. Please
>     teemu> consider those 200.000.000+ million cellular users opening
>     teemu> a network link for browsing etc. purposes who have to wait
>     teemu> every time for yet another round trip .....
> 
> While I agree that minimising delays and RTTs is always desirable,
> your argument is a bit of a non-sequitur. There's usually a delay of
> 10-15 seconds after a mobile phone is powered on or roams from its
> home provider before it has finished the authentication dance and
> joined some mobile operator's network. Given that context, an extra
> RTT to find a DNS server is no big deal in the overall scheme of
> things. In fact I suspect that the name server location overhead could
> readily be assimilated into the "authenticate this handset" overhead.
> Hey, perhaps getting a valid DNS server address could *be* 
> that handset
> authentication. 

Well, I'm not expert of all wireless networking technologies as I'm been working mainly with GSM (much less with CDMA/TDMA/PDC/WLAN etc.). Therefore I'm not sure if your argument is true in some networking technology. 

In current GSM phones no IP address allocation or any such configuration is done when powering on the phone and registering to a network, or when roaming to another operator's cellular network. 

IP address allocation (and other IP-related configuration like DNS discovery:-) is done when GSM cellular phone creates a connection to IP network - via GPRS PDP context opening or CSD dial-up. It is possible to have a cellular phone in GPRS always-online state, where this configuration is of course done only once and overhead is small as you described.

However, often (depending on use-case again) connections from (GSM) cellular phones are opened only when needed in order to save power, operator resources, money etc. Therefore a connection is opened every time a user wishes to browse, send MMS/email, use Java for networking and so worth and closed when that need ends.

So IP connections are opened many times more often than a GSM cellular phone registers to actual cellular network infrastructure (depending of course what user actually does..). Thus this RTT has to be waited every time such activity takes place and not only in powerup and when registering to a network.

I do not know often average cellular phone user would get this RTT penalty in real life, but I think that avoiding this RTT would be a good design anyhow.

What comes to DHCPv6 vs. RA, would it be possible for the hosts just to look if RA has any DNS options and use them if available, otherwise use DHCPv6(-lite) / alternative methods? That way those network administrators who wish to use RA could enable it to the routers and others could leave it out.

By the way, is there any documentation that discusses preference between preconfigured, DHCPv6 configured, RA configured, IPCP configured (and possible future IPv6CP configured), and well-known addresses?-)

Regards,

      Teemu

#----------------------------------------------------------------------
# To unsubscribe, send a message to <[email-masked]>.

---

From: "Eric A. Hall" <[email-masked]>
Date: Thu, 13 Nov 2003 10:17:12 -0600

[email-masked] wrote:

> I do not know often average cellular phone user would get this RTT
> penalty in real life, but I think that avoiding this RTT would be a
> good design anyhow.

I'm not sure how we got onto this point. It seems to me that the phone
networks are classic examples of managed networks, and as such they'd be
best off using some sort of preferred technology rather than the default.

This also seems to be a good time to make the point that the market has
clearly spoken on this subject: it wants multiple configuration management
options, each of which address specific needs/requirements.

-- 
Eric A. Hall                                        http://www.ehsco.com/
Internet Core Protocols          http://www.oreilly.com/catalog/coreprot/

---

From: Jim Reid <[email-masked]>
Date: Thu, 13 Nov 2003 16:20:17 +0000

>>>>> "teemu" ==   <[email-masked]> writes:

    teemu> So IP connections are opened many times more often than a
    teemu> GSM cellular phone registers to actual cellular network
    teemu> infrastructure (depending of course what user actually
    teemu> does..). Thus this RTT has to be waited every time such
    teemu> activity takes place and not only in powerup and when
    teemu> registering to a network.

    teemu> I do not know often average cellular phone user would get
    teemu> this RTT penalty in real life, but I think that avoiding
    teemu> this RTT would be a good design anyhow.

I already said that avoiding unnecessary RTTs is a Good Thing. However
I think you overlooked the point I was making. Presumably at the point
when a phone opens a connection to some web proxy or joins a network
or whatever there will be some sort of authentication and verification
taking place. For instance to assure the operator that the customer is
authorised to use the service. Locating a suitable DNS server could be
part of that authentication dance and the RTT for the "find me a name
server" request would be lost in the noise of the telco infrastructure
deciding what to do about the connection request, who/what to invoice
and log, etc, etc.
#----------------------------------------------------------------------
# To unsubscribe, send a message to <[email-masked]>.

---

From: Tim Chown <[email-masked]>
Date: Thu, 13 Nov 2003 18:45:35 +0000

> What comes to DHCPv6 vs. RA, would it be possible for the hosts just to look if RA has any DNS options and use them if available, otherwise use DHCPv6(-lite) / alternative methods? That way those n…

So would the M/O bits in the RA then be ignored?  Or would we assume the
presence of the options in the RA would go hand-in-hand with both bits 
being zero anyway?

Is the proposal for RA method to always include DNS options in all RAs 
(would be excessive, but for renumbering or DNS option changes some
indication is required from the "server" side), or for the solicitation to 
indicate that the client supports the RA options and thus request them if 
available?
 
Tim