Re: [minutes] Web Performance WG Teleconference #118 2013-09-04

I'm excited to see folks have agreed to include the wire protocol. While
non-standard protocols like SPDY may not be included in the spec, is it
reasonable to write the spec in such a way to allow implementers to include
whatever string they want? Here are the use cases I'd like considered:
* As we work on HTTP/2, I'd like to be able to compare performance when
using different draft versions. We often do this in Chrome by running A/B
tests. This is useful for advising the HTTP/2 standardization process when
debating features.
* Similarly to the above, we'd like to experiment with new protocols (e.g.
QUIC) and compare them to raw HTTP over TCP.

That said, I also see value in only having standard tokens reported for the
wire protocol. I just wanted to point out that there are some use cases
we'd like to support if possible, so it'd be cool if you could consider
them :)

Cheers.


On Thu, Sep 5, 2013 at 2:09 AM, Jatinder Mann <jmann@microsoft.com> wrote:

>  *Meeting Summary:*****
>
>  ****
>
> **1.     ***Wire Protocol Information*****
>
> Seeing that progress is being made on HTTP2.0, the working group feels
> that Navigation Timing L2 and Resource Timing L2 should at least indicate
> the wire protocol information, e.g., "http/1.0", "http/1.1", "http/2.0". We
> need to determine whether other metrics around wire protocol should be
> exposed as well. We will setup another conference call to specifically
> discuss this point, inviting all interested members.****
>
> ** **
>
> **2.     ***User Timing - Closures*****
>
> The working group needs to consider whether we want to take a change to
> User Timing to address the issue raised here:
> http://lists.w3.org/Archives/Public/public-web-perf/2013Jun/0001.html. ***
> *
>
> ** **
>
> **3.     ***TPAC 2013 Agenda*****
>
> Based on the conference call discussion, the TPAC agenda has been amended
> to include time for HAR and Async Scrolling, and limit the public
> performance discussion to Thursday evening. ****
>
> ** **
>
> *Thursday, November 14, 2013*
>
> 09:00 AM - 09:30 AM:    Introductions****
>
> 09:30 AM - 10:00 AM:    Prerender Discussion****
>
> 10:00 AM - 11:00 AM:    Beacon Discussion****
>
> 11:00 AM - 12:00 PM:    Resource Priorities Discussion****
>
> 12:00 PM - 01:00 PM:    Lunch****
>
> 01:00 PM - 02:00 PM:    Element Visibility and Page Visibility L2
> Discussion****
>
> 02:00 PM - 02:30 PM:    High Resolution Time L2 Discussion****
>
> 02:30 PM - 04:00 PM:    HTML5 Working Group visit****
>
> 04:00 PM - 05:00 PM:    Break****
>
> 05:00 PM - 07:00 PM:    Performance Workshop (Open to non-members)****
>
> ** **
>
> *Friday, November 15, 2013*
>
> 09:00 AM - 10:30 AM:    Timing API Discussion****
>
> 10:30 AM - 11:30 AM:    Navigation and Resource Error Logging Discussion**
> **
>
> 11:30 AM - 12:00 PM:    JavaScript Injection Discussion****
>
> 12:00 PM - 01:00 PM:    Lunch****
>
> 01:00 PM - 02:00 PM:    Display Paint Notifications Discussion****
>
> 02:00 PM - 03:00 PM:    Efficient Script Yielding Discussion****
>
> 03:00 PM - 04:00 PM:    HAR and Async Scroll Discussion****
>
> 04:00 PM - 05:00 PM:    Discuss Potential New Specifications****
>
> ** **
>
> **4.     ***Next Conference Call Time Slot*****
>
> To accommodate members in Asia and New Zealand, the working group is
> proposing meeting on Wednesdays at 12PM PST, which will be 9PM in Europe,
> and 7AM in Asia and New Zealand. If there are no objections to this
> proposal, we will update the meeting time for the next conference call.***
> *
>
> ** **
>
>  ****
>
> *W3C Web Performance WG Teleconference #11**8 2013-09-04*****
>
> ** **
>
> ** **
>
> *IRC log:* http://www.w3.org/2013/09/04-webperf-irc ****
>
>  ****
>
> *Meeting Minutes:* http://www.w3.org/2013/09/04-webperf-minutes.html ****
>
>  ****
>
> *Attendees*****
>
> Jatinder Mann, Philippe Le Hegaret, Alois Reitbauer, Dan Austin, James
> Simonsen, Rob Dickenson, Ganesh Rao, Aaron Heady****
>
>  ****
>
> *Scribe *****
>
> Jatinder Mann****
>
>  ****
>
> *Agenda*****
>
> **1.     **Resource Timing****
>
> **2.     **User Timing****
>
> **3.     **TPAC Agenda****
>
> **4.     **Conference Call Time****
>
> **5.     **Tests****
>
>
>
> --------------------------------------------------------------------------------
> ****
>
> ** **
>
> *Minutes:*
>
> *Resource Timing***
>
> http://lists.w3.org/Archives/Public/public-web-perf/2013Sep/0002.html****
>
> *Jatinder:* Since we have SPDY implementations in all browsers, seems
> reasonable to add protocol information in Resource Timing L2.****
>
> <*plh*> enum ProtocolString { "http/1.0", "http/1.1", "http/2.0" }; ?****
>
> *Daniel:* There is value in adding protocol information. What are we
> going to call it? Just the version number or the entire string?****
>
> *Jatinder:* Do we want to share SPDY or just HTTP?****
>
> *Daniel:* We shouldn't share proprietary protocols in my opinion. We
> should stick with HTTP only.****
>
> *Plh:* In the long run, it should be HTTP anyway.****
>
> *Alois:* As developers, its reasonable to know exactly what the exact
> string is.****
>
> *Ganesh:* Is this another attribute like initiatorType?****
>
> *Jatinder:* Yes, it would be a new attribute like initiatorType, we
> should probably call it wireProtocol or protocol. It would be an enum.****
>
> http://lists.w3.org/Archives/Public/public-web-perf/2013Sep/0002.html****
>
> *Jatinder:* We should also add this for Navigation Timing L2?****
>
> *Daniel:* Yes.****
>
> *Plh:* Yes.****
>
> <*Alois*> Yes.****
>
> *Plh:* If I recall, HTTP2.0 requires SSL.****
>
> *Daniel:* If I recall, we should also add SSLConnectEnd and make
> SSLConnectStart not optional.****
>
> *Plh:* If I recall, we made SSLConnectStart optional because of IE.****
>
> *Jatinder:* I'm not sure why its optional. I can check if there is a
> technical reason in IE, but I don't think it should be optional, especially
> if SSL is required for HTTP2.0****
>
> *James:* Its not clear if SSLConnectEnd is any different from
> connectionStart. We should follow up and confirm.****
>
> *Alois:* We may want to add more metrics for protocol, especially details
> on whether it is chuck encoded.****
>
> *Jatinder:* I think we should Mark on the call next week and discuss.****
>
> *User Timing*
>
> http://lists.w3.org/Archives/Public/public-web-perf/2013Jun/0001.html****
>
> *James:* Seems like a nice way to solve this.****
>
> *Jatinder:* I haven't finished reading it. I'll take a look at it.****
>
> *Plh:* Are we going to break deployed code?****
>
> *Jatinder:* We should check. If there are, we should re-consider.****
>
> *James:* Agree.****
>
> *Jatinder:* On the topic of L2 specs, are we doing delta specs instead of
> a full re-definition? I prefer deltas, since it makes it very clear what is
> different.****
>
> *James:* I would prefer that as well.****
>
> *Plh:* There are two schools of thoughts. But whatever the editor decides.
> ****
>
> *TPAC Agenda*
>
> http://lists.w3.org/Archives/Public/public-web-perf/2013Sep/0004.html****
>
> *Plh:* We may want to be more specific with how much time we want to
> spend with HTML5.****
>
> *Jatinder:* Right now we only have prerender, but we will know better
> soon. I think we should be more specific.****
>
> *Plh:* We should also add time for HAR and Async Scroll.****
>
> *Jatinder:* I don't think we need a second Performance Workshop on
> Friday. We should spent that time on HAR and Async Scrolling, but also an
> open hour for possibly new specs that come out of Thursday's discussion.**
> **
>
> <*plh*> noon PT/3pm ET/9pm CET****
>
> *New Conference Call*
>
> *Jatinder:* To help our members in New Zealand and Asia join the calls,
> we should move the conference call time to 12PM PST, which is 9PM in
> Europe, and 7AM in New Zealand. Does that work for everyone?****
>
> *Alois:* Works for me.****
>
> *James:* For me as well.****
>
> *Jatinder:* Looks like it works for all. I'll send email on it.****
>
> *Tests*
>
> *Plh:* I am almost done moving all the test cases to the new repository.
> I'll send details next week.****
>
> *Jatinder:* I still need to review the Resource Timing test cases. Are
> there any known issues?****
>
> *Plh:* Some tests (x-origin tests) haven't been migrated correctly to the
> right server.****
>
> *James:* The initatorType test doesn't work as well currently.****
>
> *Jatinder:* I'll review the rest.****
>
> * *
>