Well lets unpack this.
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(_at_)virtualized(_dot_)org>
wrote:
Phillip,
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.
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?
Regards,
-drc
--
Website: http://hallambaker.com/
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf