W3C home > Mailing lists > Public > public-web-perf@w3.org > November 2010

RE: connectEnd and SSL handshake

From: Anderson Quach <aquach@microsoft.com>
Date: Tue, 30 Nov 2010 01:54:49 +0000
To: Sigbjørn Vik <sigbjorn@opera.com>, "public-web-perf@w3.org" <public-web-perf@w3.org>
Message-ID: <1E1FF4102DEA7A40AF9CC342044ECE5D2E302917@TK5EX14MBXW603.wingroup.windeploy.ntdev.microsoft.com>
In terms of locking down on the specification, stabilizing it's key we focus on stabilizing the interface's behavior. Nic and I's recommendation is to have a definition of connectEnd to be inclusive time taken for of the SSL handshake and SOCKS authentication. 

Being inclusive of this time prevents large gaps between connectEnd and requestStart in the cases where there may be additional time spent performing SSL handshakes and SOCKS authentication in the timeline. Thus there would be a consistently defined timeline.

As IE is abstracted from the inner workings of the network layer,  it would be non-trivial to get the timing information for the SSL handshake and SOCKS authentication.  This phase can always be added at a later time if deemed important.

The recommended text goes as follows:
connectEnd must include the time interval to establish the transport connection. It can include other time interval such as SSL handshake and SOCKS authentication.

Anderson Quach
IE Program Manager

-----Original Message-----
From: public-web-perf-request@w3.org [mailto:public-web-perf-request@w3.org] On Behalf Of Sigbjørn Vik
Sent: Monday, November 29, 2010 1:58 AM
To: public-web-perf@w3.org
Subject: Re: connectEnd and SSL handshake

On Wed, 24 Nov 2010 22:02:07 +0100, Christian Biesinger <cbiesinger@gmail.com> wrote:

> Hi all,
>
> while implementing some of the networking support for webtiming in 
> Firefox, I noticed this requirement:
>
>> connectEnd must include the time interval to establish the transport 
>> connection. It must not include other time interval such as SSL 
>> handshake and SOCKS authentication.
>
> This is fairly hard to implement in Firefox because due to how the 
> abstractions work, SSL handshake is considered part of connect().
>
> Do other UAs have an easier time implementing this attribute as 
> specified? Should the spec be changed?

Quote from a relevant developer:
"It shouldn't really be that difficult, but it would be a little easier to simply time the whole connection."

Since we are on the subject anyhow, do we want to provide timing information for the handshake itself? This could be quite useful information, and information which really cannot be gleaned from anywhere else. There have been big studies going as to see how much performance is lost when enabling SSL, this timing information would be of great value in such cases. If we need to put in timers between connectionEnd and handshakeStart in any case, it also shouldn't be much extra work to explicitly add handshake timers.

--
Sigbjørn Vik
Quality Assurance
Opera Software
Received on Tuesday, 30 November 2010 01:56:10 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 21 December 2010 18:13:56 GMT