If we care about 50ms response then we probably expect the operator of the service to be interested in making sure that information that can assist is delivered to the DNS resolver.
At the moment the DNS service does not provide hints like 'this host best if calling from France' but there is no real reason that we could not distribute the information through DNS is we care about the 50ms thing.
So we can address the uncertainty in the server end of things. That leaves the client path to the server as the source of uncertainty.
Either past experience is going to be a good guide to future actions or it isn't. If there is no consistency in response times to different hosts then it is probably best to simply give up on the 50ms goal or do what is necessary to improve the service. Otherwise the client can use its past history to optimize its use of the server info.
Since most of the applications I use take a heck of a lot more than 50ms to start up, I am not sure why a 50ms connection time would be important. I can certainly see latency or jitter being an issue for online games. But connection startup seems a stretch.
I tend to think that the original requirement was bogus. But if it is genuine I think we would need a more comprehensive approach than working out whether to try IPv4 first or second or in parallel.
On Fri, Jun 25, 2010 at 1:54 PM, David Conrad <drc@xxxxxxxxxxxxxxx> wrote:
Phillip,
How would a DNS-based signaling mechanism work when DNS servers do not necessarily know anything about the state of connectivity to the server they provide name service for?
On Jun 25, 2010, at 10:06 AM, Phillip Hallam-Baker wrote:
> Am I the only person that thinks that if shaving 50ms off HTTP latency is a worthwhile goal it would be more appropriate to look at a DNS based signaling mechanism that is going to support that goal (and also do the right thing for IPv4/6) rather than look at various ways to coax the desired behavior from the legacy infrastructure.
Regards,
-drc
--
Website: http://hallambaker.com/
_______________________________________________ Ietf mailing list Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf