add "networkDuration" to Resource Timing

SHORT: I propose we add the "networkDuration" property to 
PerformanceEntry 
<http://www.w3.org/TR/performance-timeline/#performanceentry> objects.

LONG: A few weeks ago I discovered that "duration" includes blocking 
time, so "duration" is greater than the actual network time needed to 
download the resource. Since then I've been at Velocity and WebPerfDays 
where many people have shown their Resource Timing code. Everyone I 
spoke to (~5 different teams) assumed that "duration" was just the 
network time. When I explain that it also includes blocking they were 
surprised, admitted they hadn't known that, and agreed it is NOT the 
metric they were trying to capture.

I propose we add a new property to Resource Timing that reflects the 
time to actually load the resource excluding blocking time. I'm flexible 
about the name but for purposes of this discussion let's call it 
"networkDuration". The important piece of this proposal is that 
"networkDuration" should be available for all resources, similar to 
"duration". In other words, it should be available for same origin as 
well as cross origin resources as part of the PerformanceEntry 
<http://www.w3.org/TR/performance-timeline/#performanceentry> interface.

Same origin resources can calculate "networkDuration" as follows (assume 
"r" is a PerformanceResourceTiming 
<cid:part3.05050506.08080504@souders.org> object):

     dns = r.domainLookupEnd - r.domainLookupStart;
     tcp = r.connectEnd - r.connectStart;        // includes ssl negotiation
     waiting = r.responseStart - r.requestStart; // aka "TTFB"
     content = r.responseEnd - r.responseStart;
     networkDuration = dns + tcp + waiting + content;

I've discussed this with a few people and the only concern I've heard is 
with regard to privacy along the lines of "if we exclude blocking we've 
added the ability to distinguish cache reads from network fetches". This 
isn't an issue for two reasons:

 1. Even with the exclusion of blocking time, it's still possible for
    "networkDuration" to have a non-zero value for resources read from
    cache due to disk access time, etc. Therefore, excluding blocking
    time does not necessarily provide a clear means of determining
    resources read from cache.
 2. This concern assumes that adding "networkDuration" lessens privacy
    because removing blocking time provides additional information that
    is not available today. However, it's possible to exclude blocking
    time today by loading a cross-origin resource after window.onload,
    when there is no blocking contention.

Therefore, individuals who have JavaScript access to a page and can 
measure duration also have enough access to load resources after 
window.onload and can thus determine the duration excluding blocking 
time. Adding "networkDuration" does not give these individuals 
additional information beyond what is measurable today.

What "networkDuration" provides is additional information for the normal 
case of resources that are loaded as part of the main page when blocking 
contention may occur. This will give current web developers the metric 
they want for cross-origin resources, and will provide it more simply 
for same origin resources.

-Steve