Re: connectEnd and SSL handshake

On Tue, 30 Nov 2010 02:54:49 +0100, Anderson Quach <aquach@microsoft.com>  
wrote:

> 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.

I agree that a gap in the timeline would be unwanted, and possibly  
confusing. Though I don't think extending one of the other phases to  
include that gap would be any more wanted or less confusing for Web  
developers, that gap is worhy of a phase of its own.

The socket setup is the closest we get to measuring the latency, which is  
possibly the most important characteristic of a connection. Without a good  
grip on the latency, it is very hard to divide the connection into the  
socket creation and handshake/authentication, so the combined value is  
then of little value, as well as any other measurements which depend on  
the latency. That the connection timing no longer is used the same way on  
SSL, might also be confusing to developers. Not to mention that the  
handshake/authentication timing itself is interesting, which also cannot  
be seen from timing information where it is joint with the socket setup.

> 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.

I understand the complexities of implementation. The definition of phases  
cannot be changed later, but we might add new phases. If we plan to add  
such phases later, we should at the very least plan for them now (to  
ensure the final wording can be non-confusing), we should even make them  
optional (MAY) now.

E.g. connectionStart->socketEnd->handshakeStart->connectionEnd, where  
socketEnd is defined as follows:
When the socket is fully established, before any communication across the  
socket is started (e.g. SSL handshake or SOCKS authentication). User  
agents which do not have easy access to this information MAY return the  
value of connectionEnd instead. Which value a user agent returns should be  
documented in the flag socketSeparateFromHandshake.

-- 
Sigbjørn Vik
Quality Assurance
Opera Software

Received on Tuesday, 30 November 2010 08:17:58 UTC