W3C home > Mailing lists > Public > public-web-perf@w3.org > July 2014

Re: Proposing changes to Navigation Error Logging

From: Ilya Grigorik <igrigorik@google.com>
Date: Mon, 28 Jul 2014 11:19:24 -0700
Message-ID: <CADXXVKqPWeKqr9BK14Z_J7c6BmmkQtiRyQPzvEmn-dxfzP9wfw@mail.gmail.com>
To: ttuttle <ttuttle@chromium.org>
Cc: "Aaron Heady (BING AVAILABILITY)" <aheady@microsoft.com>, "public-web-perf@w3.org" <public-web-perf@w3.org>
On Fri, Jul 25, 2014 at 11:21 AM, ttuttle <ttuttle@chromium.org> wrote:

> 3. I'd like to allow the user-agent to retry the uploads if they fail. If
>> the issue is a transient network issue (i.e. a route is flapping), it's a
>> waste to throw out the error report just because the network was still
>> glitched the first time the upload was attempted.
>> Aaron: This reads like a denial of service attack. We did discuss it
>> originally, but how do you control the retries when an origin has a short
>> lived but widespread spike in errors, especially when the origin for the
>> error is also the origin/logging endpoint for these navigation error calls.
>> A few seconds after it recovers it gets hit with a global surge in
>> telemetry request, knocking if offline, more errors…... Also goes back to
>> #1, any error that is stable enough to repro is going to be reported by a
>> large number of users. I expect this system to be lossy telemetry wise.
>> Optimized to protect the origin, not the error telemetry. And if you wait
>> for the next successful page load, then you can get the errors from the
>> queue.
> Hmm, I see your point. I'll see if we can do without retries, or postpone
> them until the next time we would've made a new upload anyway.

Mirroring the language in Beacon, can we defer this decision to the UA?
"The User Agent SHOULD make a best effort attempt to eventually transmit
the data."

It seems reasonable to allow the UA to both delay and attempt to retransmit.

Received on Monday, 28 July 2014 18:20:32 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:04:39 UTC