> 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.
I suppose I indeed overlooked your point, sorry.
The wasted time is not much for one user. Perhaps it is not much even for an operator.
One point I wish to make is that when the wasted time is multiplied by possibly
hundreds of millions of users worldwide - even daily perhaps - isn't it worth of
serius consideration in system/protocol desing?
I see that point as one reasoning to vote for cheaper IPv6 DNS discovery mechanism
than DHCPv6(-lite) with RTT cost and I wished to share the reasoning with the group.
I'd also like to see more discussion about user experience, as these kind of issues do
affect end users. Or am I out of scope here? I think that reasonable(?) extra effort
for network configuration can be justified if user time and cost can be saved.
Actually 3GPP has standardized a mechanism for providing IPv6 DNS addresses in GPRS
PDP context activation.
And then one comment from (host) stack implementor point of view. I'd like to do the
(host) stack implementation as independent as possible from the lower layers for
portability, testing, quality, and interworking reasons (with different underlying
network technologies) and thus I wish to have a cheap, general solution for DNS
discovery. For that "requirement" a specific 3GPP solution is not good enough.
Furthermore I do not think that DHCPv6(-lite) is good for that purpose either (even if
it would be implemented to stack for obtaining other possible configuration
parameters).
So please do not consider one stack implementation to be used only in one kind of
networks. Even if the implementation may be used in cellular phone, and thus in that
case can be provided with configuration information from cellular network, it does not
mean that the same implementation is used _only_ in a cellular network (and there are
many different cellular network technologies with different characteristics). It is a
bugger to implement support into the same stack for obtaining DNS addresses by 3GPP
methods in one case, DHCP in one, RA in one, preconfigured in some and so forth..
Regards,
Teemu
#----------------------------------------------------------------------
# To unsubscribe, send a message to <[EMAIL PROTECTED]>.
